-
These are my current results from trying to implement the scaler on the FPGA. I found an old HDMI-USB converter, so the images should be quite accurate. Also visible is an artefact (specially in the green trace) from the type of deinterlacing used (weave), resulting from capturing two half frames separated in time. These are not noticeable on a lcd or monitor (at least not for this kind of content). Currently calculating the pixel output is rather simple without complex math:
Scale_0.png - On output pixels after a skipped pixel, logicaly or previous and current input pixel
Scale_1.png - On output pixels after a skipped pixel, take average from previous and current input pixel
Scale_2.png - On output pixels after a skipped pixel, choose the pixel from previous and current input pixel according to intesity (suggested by Nominal Animal)
Scale_2.png - for all pixels use the average from previous and current input pixel
For more improvements more complex math is required.
-
Here first results on using a 5-Tap FIR filter in the scaling. Coefficients where choosen by trial and error and probably not optimal yet.
-
Here first results on using a 5-Tap FIR filter in the scaling. Coefficients where choosen by trial and error and probably not optimal yet.
Very addictive is it not.
It does look nice, but some of the text lines seem to become a bit thin. With the first try of simple down sample and mixing with the previous pixel the text was a bit fat. No idea if playing with the coefficients can improve this.
The horizontal grid lines do look good though. Probably the best so far. Scale_3.png from your previous post comes close second. -
Very addictive is it not.
Yes very addictive this image scaling topic, on my side I'm still under addiction of RTD2660 and not decided what FPGA go but then double addition
-
I personally would opt for an over-resolution LCD and then just have black bars (wasted pixels) on the edges.
Gotta love that perfect, ultra-fast, 1:1 scaling. -
I've got a static HTML (no network connection needed, just open the file in your browser locally) file that one can use to experiment with colors and scaling coefficients, but dog namd it is difficult to get browsers to display the generated image in pixel-perfect form!
I myself happen to have a window.devicePixelRatio = 30/23 = 1.3043478260869565 by default, which means that in CSS and HTML, 1px as a length unit is actually a bit over 1.3 display pixels. Furthermore, not all browsers even export window.devicePixelRatio; Safari and derivatives on iOS do not update it when the user changes the zoom factor (which directly affects it). The most annoying is the CSS transform: matrix(xx, xy, yx, yy, tx, ty) property that I use for displaying the Canvas element containing the generated image, especially when the user zooms in and pans around to see the exact pixel details, because of how it interacts with the canvas dimensions in pixels, and the visible canvas size in CSS "px" units.
Simply put, when Javascript draws a 1024×480 canvas, your browser scales it larger or smaller without telling you, even if you specify its size in HTML/CSS as "width:1024px; height:480px;".
I'm starting to really hate browser developers. First, all that "UTF-8 cannot be the default charset, because we labeled every other charset as legacy, and among us decided that only legacy charsets can be set as default; so, our hands are tied, sorry" nonsense. Now, with no way to accurately specify device pixels instead of the imaginary "px" units they actually use (that really have no relation to actual display device pixels at all), because of the old idiotic "this page is best viewed in W×H resolution" stuff and web developers using "px" units instead of em/ex/% to specify visible layout length units.
I've got one more trick I'll try before giving up (trying to get browsers to display Canvas data in pixel-perfect form, without scaling errors). If you look this stuff up online, you'll find many that say "this is impossible", because it kinda is, kinda isn't. I can display the Canvas unscaled in pixel perfect form in all browsers (Chrome 18+, Edge 12+, Firefox 18+, Opera 11.1+, Safari 3+, WebView 4.4+), but zooming in and panning is problematic.
(In case you wonder, even though Javascript is interpreted/JITed within the browser, it is blazingly fast. Recomputing a new scaled frame takes only a tiny fraction of a second, even on a small ARM SBC; on desktop and laptop machines, it is basically instantaneous: no human-detectable delay at all.)
Attached are the four full frames (both fields) I got from the data @avst provided (great work, by the way!
), using #000000 for background, #0000FF for trace A, #00CC00 for trace B, #00CCFF for trace A + trace B overlapping, #808080 for grid/text, #8080FF for trace A + grid/text overlapping, #80FF80 for trace B + grid/text overlapping, #80FFFF for trace A + trace B + grid/text overlapping, #FF0000 for marker, #CC00CC for marker + trace A overlapping, #CC9900 for marker + trace B overlapping, #CC99CC for marker + trace A + trace B overlapping, #FF8080 for marker + grid/text overlapping, #FF80FF for marker + trace A + grid/text overlapping, #E5CC80 for marker + trace B + grid/text overlapping, and #FFFFFF for marker + trace A + trace B + grid/text overlapping. Not all of these exist in the images, but that's the palette I used to retain all overlapping information; it is not the best choice visually. I do believe having an easy way to experiment with both the colors and the scaling algorithm in a simple static HTML page would be optimal, as it would let others (perhaps with more visual sense/acuity/taste?) to suggest enhancements, without requiring any hardware or development environment, just a browser.
-
.....
And that is why I used a 1024*600 LCD panel to do my tests with. Only used 480 of the lines and left the rest on black, to getting the proper pixel representation. When I switched tho HDMI output the displays I tried it on did their own scaling to match the display resolutions, giving a false representation of the image.
For my initial work I created bitmaps on the computer and checked them in pinta where you can zoom in and count the pixels to check the results.
On irritations with browsers and the internet, the fact that they decide what language to use based on your IP address is a big one for me. I'm Dutch, live in France and my computer system is set to English. For me the setting of the language on my computer would be a far better variable to decide what results to return to me. When I try to look up something on a big companies website and use the .nl or .com extension, I don't want to be referred to the .fr version, just because my IP address comes from France.
-
...
i have the color lookup implemented as you described, so you can assign a color to each ossible combination. In my previous post i sticked to the same color scheme, so the images can be compared better regarding scaling. There still seems to be a bug im my code i have to look at later. -
Got it working on Firefox and Chrome derivatives, I believe: advantest-scaling.html is the single file you need, and is in Public Domain (CC0 1.0 Universal), so feel free to do what you wish with it.
I discovered that Lanczos doesn't work well for downscaling (i.e. scaling 1024×480 to 640×480), but it works excellent for upscaling 1024×480 to 1024×768. I definitely prefer the 1024×768 upscaled (Lanczos a=2) among all the alternatives I've seen!
Note that the Lanczos a=2 computes each pixel using four source pixels, and is perfect for deinterlacing 1024×240+1024×240 to 1024×768. (For deinterlacing, the scan lines are divided into 48 groups, each group converted identically. Each input group consists of 16 scan lines, advancing by 10 scan lines between groups. For each output pixel, you need 12 multiplications, 6 additions, and 6 subtractions, plus clamping the results to your color component range.)
I can easily modify a version for 1024×600 vertical scaling. That one expands each group of four scan lines to five, so the actual coefficients differ but otherwise it is very similar to this.
The scaled 1024×768, taken as a screenshot from this:
-
advantest-1024x600.html is the version scaling to 1024×600. It seems that 5 bits are needed for the scaling coefficients (and thus 6+colorcomponentbits bits for the multiplication results) for the text and vertical lines to be smooth. However, there are then just nine unique fractional coefficient magnitudes (0, 0.03125=1/32, 0.0625=2/32, 0.09375=3/32, 0.31250=10/32, 0.5=16/32, 0.65625=21/32, 0.8125=26/32, and 1), and each multiplication can be calculated using at most three additions of right-shifted color component values –– for example, c*21/32 = (c >> 5) + (c >> 2) + (c >> 1).
The scaled 1024×600 image using those 5-bit scaling coefficients (screenshot from this HTML file):
Assuming the grid is supposed to have square cells, then the appropriate scaled size with square pixels would be 1024×672. 1024×768 and 640×480 would have 14% distortion (1×1.14 cells), whereas 1024×600 would have just 13% distortion (1.13×1 cells).
Note: BuyDisplay/EastRising sells a 7" 1024x600 IPS panel (165mm × 100mm; 154mm × 86mm active display area) with a RGB+Hsync+Vsync+DE interface for under $20. Sipeed Tang Nano 9k and 20k need one resistor to be replaced to drive the backlight properly, plus a 40-pin 0.5mm pitch to 50-pin 0.5mm pitch adapter. BuyDisplay/EastRising provides the datasheet for the display, and sells directly, at eBay, and at AliExpress. I really like their IPS display modules; I haven't used this one, though, only the smaller ones (mainly 2.4" and 2.8").
-
I added linear scaling (button at the very bottom) for both advantest-scaling.html and advantest-1024x600.html. ("Linear" coefficients are calculated by treating input and output pixels as rectangles, directly from their overlaps.)
It looks like scaling to 1024×600 via
v0 = V0
v1 = (V0 + 3*V1)/4
v2 = (V1 + V2)/2
v3 = (3*V2 + V3)/4
v4 = V3
yields quite nice results; perhaps even better than Lanczos:
I'm not sure I can even tell the difference between scaling to 1024×768 via
v0 = V0
v1 = 0.6*V0 + 0.4*V1
v2 = V1
v3 = 0.2*V1 + 0.8*V2
v4 = 0.8*V2 + 0.2*V3
v5 = V3
v6 = 0.4*V3 + 0.6*V4
v7 = V4
vs. using Lanczos a=2 or a=3, without zooming in the image.
Because of the visual results, I would suggest trying to use a 1024×600 panel instead of a 640×480 one. The coefficients are trivial, and can be implemented via addition/subtraction with two extra bits of accumulator per color component.
-
I am amazed by the quality of the results obtained! I have made a conversion of my R3361 to a 6.5" LCD with a decent display and using a Chinese board. The use of an FPGA is very promising!
I am looking forward to seeing a real-time result shown by Tantatron
-
I added linear scaling (button at the very bottom) for both advantest-scaling.html and advantest-1024x600.html. ("Linear" coefficients are calculated by treating input and output pixels as rectangles, directly from their overlaps.)
It looks like scaling to 1024×600 via
v0 = V0
v1 = (V0 + 3*V1)/4
v2 = (V1 + V2)/2
v3 = (3*V2 + V3)/4
v4 = V3
yields quite nice results; perhaps even better than Lanczos:
I'm not sure I can even tell the difference between scaling to 1024×768 via
v0 = V0
v1 = 0.6*V0 + 0.4*V1
v2 = V1
v3 = 0.2*V1 + 0.8*V2
v4 = 0.8*V2 + 0.2*V3
v5 = V3
v6 = 0.4*V3 + 0.6*V4
v7 = V4
vs. using Lanczos a=2 or a=3, without zooming in the image.
Because of the visual results, I would suggest trying to use a 1024×600 panel instead of a 640×480 one. The coefficients are trivial, and can be implemented via addition/subtraction with two extra bits of accumulator per color component.I am amazed by the quality of the results obtained! I have made a conversion of my R3361 to a 6.5" LCD with a decent display and using a Chinese board. The use of an FPGA is very promising!
I am looking forward to seeing a real-time result shown by Tantatron
Hello both Nominal Animal and Silicium81 (Patrick) where initially, Patrick and myself are member of amazing yahoo group dedicated to Advantest.
Just small note, I might detail and explain more later but it is important to remember the full story.
Askild form Norvegia made a very smart hacking (HW and SW to colorize these 2 serie of Advantest (one with 5.6" and one with 6.5" cathodic tube display). There has always been the mystery of not conventional video stream format by Advantest engineering back end of 80's but now we understand what is behind thanks to the guidance of avst with 20 years of experience on scaler technology. So I've learned so much here and in private how to properly modify the RTD2660 scaler pipeline. Important to thank again the russian member KerJoe who offered part of the RTD2660 learning.
Anyway to make a story short, the norvegian engineer kit is based on a framebuffer rescaling RGBs Arcade board followed by RTD2280 VGA board to LCD drive. The framebuffer board was able to deinterlace then rescale with VGA output (1024x768) then the RTD2280 rescaled to 640x480. The all idea of my project was to first learn how to program RTD2660 (initial global topic of the Original Poster DC1MC) then see how to fuse or remove both separate boards into a single one.
Now comes the FPGA topic which I'm very interested as well for this project and others in my own pipeline, for the moment lack of time plus other issues implies I've so far only done RTD2660 with arduino.
However the last result from Nominal Animal seems visually one of the best video output, of course it would need to be confirmed with real time - real signal from the Advantest.
As I've reported and live tested in the past, I do not see a big difference or gain between no RGBs framebuffer deinterlace of RTD2660 then direct drive of 640x480 versus using the 2 stage boards (RGBs to 1024x768 then VGA to 640x480).
I guess more to come, this thread is just amazing in shared knowledge
Important: remember at the end, the LCD has to fit mechanically inside the Advantest spectrum analyzer. With R3x61 like Silicium81 or my units, only 5.6" or mabe 5.7" can fit inside the chassis as a retrofit kit. Silicium81 decided along with another member to use 6.5" and build an external bezel, assembly and frame but I'm not going that path. As a vintage test equipment lover, I tend to keep the external visual aspect so everything is inside. However with R3x65/R3x71 then 6.5" fits real good inside because the CRT was 6.5" but again CRT is smaller in R3x61 (5.6 to 5.7"). Another thing, it is not easy to find 5.6" or 5.7" with higher resolution than 640x480 plus if using such resolution like 1024x600, it will have less brightness or constrast due to higher density pixel. It is a really a complex tradeoff of old test equipment with aspect ratio 4:3 and small CRT's when going after LCD retrofit.
P.S. I'm quoting part of message from Xu Wang (Simmconn Labs) who has done lot of FPA retrofit, extract taken from HP group
Let me clarify the resolution support. The NewScope-8 kit supports VGA (640x480), XGA (1024x768) and WXGA (1280x800) resolutions. In most cases, the actual number of pixels used to draw the image is slightly less than the above numbers, in order to leave margins around the edge of the viewing window. With the same back light intensity, lower resolution gives you a brighter trace because the pixels are bigger. The high resolution panel on the other hand gives a finer picture with more details at the cost of brightness.
.... snip ....
Considerable time was spent on looking for modern LCD panels that physically fit in the form factors designed some 30 years ago. The outside dimensions, the active display area, the aspect ratio and the resolution have to match. It's been especially hard in this case. The 70004A bezel is slightly smaller than the original CRT's display area, and the opening is tightly defined by the surrounding push buttons. The popular 8" XGA panels just don't fit well. 7" XGA panels, on the other hand, are quite rare. Perhaps they came in a time when that kind of pixel density just became economical to make, yet the consumer i nterest had shifted to larger and/or 16:9 screens.
I was amazed how HP managed to pack so many pixels on the tiny CRT screen of the 70205A. I haven't look into a suitable LCD panel for that unit, perhaps those recycled from the recalled Samsung Galaxy Note 7 would be a nice candidate.
.... snip ....
I talked with Xu Wang, of Simmconn, and basically, he will sell the Newscope-8, with XGA display, only if you order qty 5+. The display is an industrial model, and costs him almost as much as the total price he charges for the VGA model Newscope-8 ($499).
He said that it was very rare that he even got an order for the more expensive XGA model.
I mentioned the cheap 7" XGA LCD's that are all over the place for $80, and he said the problem is they are wide format, will not readily fit the bezel for the 85662A display unit, and are too dim. The WXGA models are also too wide, and too dim. He chose not to ramp up production on them for that reason.
So, he only stocks the VGA (640x480) resolution LCD's.
So again if we go back on Advantest R3x61 R3x65 and R3x71 then display are smaller in order to fit and replace the CRT -
(Apologies for barging into this thread, by the way.)
However the last result from Nominal Animal seems visually one of the best video output, of course it would need to be confirmed with real time - real signal from the Advantest.
Absolutely. If I haven't made it clear before, I intended the simulation (HTML tool pages) as a tool for investigating what kind of settings one should try on an FPGA implementation. I use simulation to limit the number of different implementations I need to try, with actual real-world testable results what one compares against/to. Simulations nice, but real world rules.remember at the end, the LCD has to fit mechanically inside the Advantest spectrum analyzer.
Do you have the measurements of the largest rectangle that can fit inside, and what the display opening or active area is?
The BuyDisplay 7" 1024×600 IPS is 165×100×4mm, 154×86mm active area.
There are also 5" (121×76×3mm, 108×65mm active area) and 4.3" (106×67×3mm, 95×54mm active area) ones with smaller, 800×480 resolution. The actual data I have indicates only 972×476 area contains visible information, and the simulated image scaling 1000×480 to 800×480 using Lanczos a=2,indicates it might be a possibility. I don't like how the vertical portions of the signal traces lose intensity at 800×480, but it shows that Lanczos filtering for the Grid/Text (and Marker) bit planes definitely works well for the 800×480 case, just like Linear filtering works well for the 1024×600 case. A separate scaler/filter for traces at 800×480 might be a solution.Another thing, it is not easy to find 5.6" or 5.7" with higher resolution than 640x480 plus if using such resolution like 1024x600, it will have less brightness or constrast due to higher density pixel.
Usually it is the other way around, especially for the traces: downscaling reduces the intensity of small details, whereas upscaling keeps those relatively intact.
You see, scaling algorithms do not understand what is important and what is not in an image. When scaling down in size, multiple input pixels contribute to a single output pixel, and unless you do shenanigans, this means that narrow/small details –– like the traces here –– will necessarily lose some of their intensity, because they always have a background pixel nearby contributing to the output pixel.
I have not experimented with a scaling algorithm that ignores the background contribution, because such an implementation requires a division per pixel, and it is a relatively slow operation on an FPGA. This is because the contributions from non-background pixels varies, and their weights must be normalized to 1. Basically, the generic interpolation kernel is \$\sum_i C_i w_i / \sum_i w_i\$, where \$w_i\$ are the weights, and \$C_i\$ are the color components being interpolated. In the standard FIR- and kernel filters \$\sum_i w_i = 1\$, which eliminates the division. If one ignores some pixels, like say the contribution from the background pixels, then that sum will vary. In practice, 6-8 bits is plenty for the sum of weights, a practical possibility would be to have a 64/128/256-entry look-up table with 12-18 bit values each, yielding the corresponding \$1/(\sum_i w_i)\$ fixed-point multiplier.
-
A separate scaler/filter for traces at 800×480 might be a solution.
Which is easily done in the FPGA solution with the separate planes coming in to it. With the ability to process them in parallel it does not slow things down. All that is needed are sufficient resources in the FPGA, and so far it is only using less than 10% off the logic.
-
Just to confirm my suspicions, I checked what it would look like if one scaled from 1000×480 to 800×480, using weights
$$\begin{array}{c|ccccc}
x \mod 4 & w_0 & w_1 & w_2 & w_3 & w_4 \\
\hline
0 & 4 & 1 & ~ & ~ & ~ \\
1 & ~ & 3 & 2 & ~ & ~ \\
2 & ~ & ~ & 2 & 3 & ~ \\
3 & ~ & ~ & ~ & 1 & 4 \\
\end{array}$$
so that the sum weights varies from 0 to 5, and black pixels (no trace, grid/text, or marker) do not contribute. The corresponding five scaling factors (reciprocal multipliers to scale the sum weight to 1) are \$0\$, \$1\$, \$1/2 = 0.5\$, \$1/3 = 0.333\dots\$, \$1/4 = 0.25\$, and \$1/5 = 0.2\$. That is, each output pixel involves four sums: one of the weights corresponding to non-black pixels, and one each of the red, green, and blue component multiplied by the corresponding weight. Then, the reciprocal multiplier is looked up from a 6-entry Look-Up Table, and the red, green, and blue sums multiplied by that (followed by shifting right to get rid of the fractional part). Decide for yourself if you consider the results useful, but I think I like it:
Edited to add: Doubling the above integer coefficients, but using half weight for background pixels (noting that then the components are all 0 so it's just adding half the source pixel weight to the weight sum), means the weight sum varies between 0 and 10 (so 11-entry Look-Up Table needed for the scaling factors), but I really like the results:
You can also use advantest-800x480-black.html to examine the actual pixel results, adjust the colors, and the background color weight.
-
More shenanigans: advantest-hscale now allows arbitrary horizontal resolution, has two default palettes, can limit output to 6-24 bit color, allows adjusting the weight of individual colors, and has a Save button for saving the generated image (as PNG).
Assuming the 5.5" maximum size refers to a 4:3 display, it should be about 112mm × 84mm in size. The 5" 800×480 ER_TFT050-6 has 108×65mm active area in a 121×76mm panel. It also yields almost square grid.
I worked out a nifty way to horizontally interpolate from 1000×480 to 800×480 using a Web palette (216 possible colors, I used #000000, #0000FF, #00FF00, #00FFFF, #999999, #9999FF, #99FF99, #99FFFF, #FF0000, #CC00CC, #CC9900, #CC99CC, #FF9999, #FF99FF, #FFFF99, #FFFFFF), converting five source pixels p0..p5 to four output pixels, with background having one quarter the weight of other colors:Code: [Select]inR[16] = { 0, 0, 0, 0, 3, 3, 3, 3, 5, 4, 4, 4, 5, 5, 5, 5 }; // Palette, red componentsThe 156 (6×26) or 256 (8×32) outC look-up table is the trick here: it basically represents the division operation. I didn't bother to compute a direct expression for its values, I brute-forced them using a C program. Because the color components are within 0..5 and the linear scaling weights sum to 5, such a small look-up table suffices. Indeed, all the variables here are at most 5 bit unsigned integers. The above is repeated 200 times for each scan line, so there are a lot of look-ups.
InG[16] = { 0, 0, 5, 5, 3, 3, 5, 5, 0, 0, 3, 3, 3, 3, 5, 5 }; // Palette, green components
InB[16] = { 0, 5, 0, 5, 3, 5, 3, 5, 0, 4, 0, 4, 3, 5, 3, 5 }; // Palette, blue components
outC[6][26] = { // _ are unused; this is for 12-bit/R4G4B4 output; 156 to 256 entries, four-bit value in each entry.
{ 0, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _ },
{ 0, 2, 3, 4, 6, 8, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _ },
{ 0, _, 2, _, 4, _, 7, _, 9, _, 11, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _ },
{ 0, _, _, 3, _, _, 5, _, _, 8, _, _, 10, _, _, 13, _, _, _, _, _, _, _, _, _, _ },
{ 0, _, _, _, 3, _, _, _, 6, _, _, _, 8, _, _, _, 11, _, _, _, 14, _, _, _, _, _ },
{ 0, 1, 1, 2, 2, 3, 4, 4, 5, 5, 6, 7, 7, 8, 8, 9, 10, 10, 11, 11, 12, 13, 13, 14, 14, 15 },
};
// Look up the color components corresponding to the five input pixels
r0 = inR[p0], g0 = inG[p0], b0 = inB[p0]
r1 = inR[p1], g1 = inG[p1], b1 = inB[p1]
r2 = inR[p2], g2 = inG[p2], b2 = inB[p2]
r3 = inR[p3], g3 = inG[p3], b3 = inB[p3]
r4 = inR[p4], g4 = inG[p4], b4 = inB[p4]
// These bits are clear if the corresponding input pixel is a background pixel, set if non-background
f0 = !!p0, f1 = !!p1, f2 = !!p2, f3 = !!p3, f4 = !!p4
// Left index is always 0..5 inclusive, and right index 0..25 inclusive.
out0.r = outC[ 4*f0 + f1 ][ 4*r0 + r1 ]
out0.g = outC[ 4*f0 + f1 ][ 4*g0 + g1 ]
out0.b = outC[ 4*f0 + f1 ][ 4*b0 + b1 ]
out1.r = outC[ 3*f1 + 2*f2 ][ 3*r1 + 2*r2 ]
out1.g = outC[ 3*f1 + 2*f2 ][ 3*g1 + 2*g2 ]
out1.b = outC[ 3*f1 + 2*f2 ][ 3*b1 + 2*b2 ]
out2.r = outC[ 2*f2 + 3*f3 ][ 2*r2 + 3*r3 ]
out2.g = outC[ 2*f2 + 3*f3 ][ 2*g2 + 3*g3 ]
out2.b = outC[ 2*f2 + 3*f3 ][ 2*b2 + 3*b3 ]
out3.r = outC[ f3 + 4*f4 ][ r3 + 4*r4 ]
out3.g = outC[ f3 + 4*f4 ][ g3 + 4*g4 ]
out3.b = outC[ f3 + 4*f4 ][ b3 + 4*b4 ]
Horizontal scaling does have the benefit that each scan line is processed linearly, without requiring any access to framebuffer outside the current scan line. The above assumes that the framebuffer data (p0..p4) are the 4-bit samples, with bit 0 trace A, bit 1 trace B, bit 2 grid/text, and bit 3 marker. The palette can be modified at any time, the code does not do any other assumptions except that background is black, and color components are in range 0..5, inclusive.
If anyone is interested in this, feel free to ping/PM/email me; I'd be happy to elaborate. (I feel like I'm hogging the thread; apologies!
)
The result of the above code, generated from C very similar to the above pseudocode, is attached.
-
I did some more tinkering with my scaling and changed the colormap to the one used by Nominal Animal for better comparison. Scaling is by a simple filter, with colors driven into saturation for stronger contrast. Second image uses brighter white for grid/text.
-
I added linear scaling (button at the very bottom) for both advantest-scaling.html and advantest-1024x600.html. ("Linear" coefficients are calculated by treating input and output pixels as rectangles, directly from their overlaps.)
It looks like scaling to 1024×600 via
v0 = V0
v1 = (V0 + 3*V1)/4
v2 = (V1 + V2)/2
v3 = (3*V2 + V3)/4
v4 = V3
yields quite nice results; perhaps even better than Lanczos:
I'm not sure I can even tell the difference between scaling to 1024×768 via
v0 = V0
v1 = 0.6*V0 + 0.4*V1
v2 = V1
v3 = 0.2*V1 + 0.8*V2
v4 = 0.8*V2 + 0.2*V3
v5 = V3
v6 = 0.4*V3 + 0.6*V4
v7 = V4
vs. using Lanczos a=2 or a=3, without zooming in the image.
Because of the visual results, I would suggest trying to use a 1024×600 panel instead of a 640×480 one. The coefficients are trivial, and can be implemented via addition/subtraction with two extra bits of accumulator per color component.
Looks amazing! -
I made a tool page, overlap-scaling.html, to calculate a linear scaling from any source size to result size, both up and down.
Fill in the source and result size ranges, and the maximum length (how many different output calculations you accept), and click on "Find ratios".
When you click on a ratio button, it calculates the integer coefficients, shows a box illustration of the scaling, and also the formulas for calculating the outputs from the inputs.
Below that, you'll then find a box for background weight (1/1 to 1/N), upper limit for the source values –– this is 5 for the Web Palette colors, and generally one less than the number of values each color component can take in your palettes ––, and upper limit for the result values. 63 implies 6-bit output, for example 18-bit RGB output. For 15-bit RGB output, use 31; for 12-bit RGB output, use 15.
If you then click on the Lookup button, it brute force calculates the lookup table that avoids the division when the calculation does not have a constant divisor (because "background" has only fractional weight now). If no such lookup table is possible, it doesn't show anything.
Note that because RGB colors are computed the exact same way, just with different palette lookup, it only shows one. The V[] lookup represents the RGB color component lookup, so for RGB output, you repeat the calculations three times, using one V[ for red, another for green, and third for blue; each having 16 entries. These are the palette color components, scaled to the input range (0-5 for Web palette).
This scaling method is the same as in advantest-hscale.html, producing quite good results. In there, use ×1 for black background, and ×N for all others. For Web palette, use only color components 00, 33, 66, 99, CC, and FF; this gives you a selection of 216 colors to pick from. -
Which is easily done in the FPGA solution with the separate planes coming in to it. With the ability to process them in parallel it does not slow things down. All that is needed are sufficient resources in the FPGA, and so far it is only using less than 10% off the logic.
Interesting!
What a nice solution! I have Tang Nano 9K and an Tang Nano 1K.
It might be possible to implement this on the 1K directly to the LCD, Your design has 3 multipliers probably for the filter, those are not present on the 1K the rest should probably fit.
chip GW1NZ-LV1 FPGA
LUT4 1152
Register 864
Block SRAM (bits) 72K
Shadow SRAM (bits) 4K
User Flash (bits) 64K
PLLs 1
User Flash 64 Kbit
DSP NO
IO Bank 2
Max I/O 25
-
I was wondering how the Advantest R3265/R3271 is generating its picture.
Looking at Advantest_R3265A_R3271A_Spectrum_Analyzer_Vol_II_Service_Manual P181:" alt="" class="bbc_img" />
So far I can tell the dot clock is 20 Mhz there are 4 pixel planes SIC0-SIC3 I assume these pixel planes corespond to: Trace A, Trace B, background1 and text1
-
Hello @hve
Maybe you did not have time to read all the posts in this thread, lot of them but in a few words. Wether R3261/R3361 or R3265/R3271/R3365/R3371 the video generator works the same, namely as you said (4 planes, 20 MHz) but these are interlaced. Practically these spectrum analyzer models are monochrome so they actual analog OR or fuse the 4 signals which is why we can colorize the planes via RGBs process. However the real problem is to implement the de-interlacer inside FPGA x or y then see the result live run. The signals are easy to hack, the problem is FPGA (which model, time to code, cost) then make a unified board (signal conditioning, FPGA and LCD drive wether TTL or LVDS).
I'm still not sure what I'll do next in this project, in the mean time I've preferred to use as proof of concept the RTD2660 scaler board hacked with an arduino DUE as shown below on my YouTube channel
-
EDIT: Sorry during my previous post I was interrupted apparently it got posted incomplete.
My R6265 does not have composite output and or a VGA output so I was wondering how these adapter boards interface with the Advantest analyzer...
Looking at the Advantest_R3265A_R3271A_Spectrum_Analyzer_Vol_II_Service_Manual.pdf- The device uses an AM95C60-20CK quad pixel dataflow manager (datasheets are online October 1988)
- Dot clock is 20MHz
- The image is generated using 4 pixel planes SIC[0-3], I assume this is for: Trace A, Trace B, background1 and text1 See P181:
If we feed the Dot_CLK VSYNC HSYNC and the SIC0-3 data signals directly via a 5 to 3.3v level shifter into the FPGA could we then relatively easy map this to an LVDS attached LCD?
EDIT: Regarding the interlace problem the graphic processor also indicates if the frame is even or odd. We could also feed this information into the FPGA..
I can see see some sort of VGA cable as input, but I was wondering which signals where tapped from the Avantest mainboard for the output.
EDIT: I assume now you are directly tapping the CRT connector (HSYNC VSYNC VIDEO)
- The device uses an AM95C60-20CK quad pixel dataflow manager (datasheets are online October 1988)
-
Hi Tantratron,
Btw thank you for your answer. I am quite fond of the Tang Nano Series these are relatively low cost.
Tang Nano 9K should be more than capable I guess. I have seen some results from @pcprogrammer they are awesome.
If we tap the NMOS signals directly there's only the 5v to 3.3v level shifting to worry about, so BOM could be
- Tang Nano
- Level shifter board
- LCD
and maybe some 3D printing to make a suitable frame for the LCD