VGA DAC calculator
charli va
We've already discussed it in the thread about the multimedia shield designed by Jesús, but I'm bringing it up now to avoid cluttering this thread.
The calculator allows you to test different resistor values in VGA DAC models so you can see the generated color palettes and check if they fall within the voltage ranges allowed by the VGA standard.
Currently, it includes two DACs: a simple 2-bit/channel one (like the one currently used in the Alhambra's AP-VGA or the one in the shield) and a 4-bit/channel one provided by Jesús and designed for his SIMRETRO board.
With this, for example, you can see why a DAC might display muted colors. It could also be useful for finding specific palettes; for instance, if you want to create a system that generates images with a Game Boy color aesthetic, you could experiment with resistor values until you find a color palette you like.
If I see that this is useful, I want to do the reverse: give it a color palette and have it provide the resistor configuration that most closely matches that palette.
Good night!
Jo mo
charli va
Your scripts are interesting and useful; the fact that they're made with AI is beside the point. If they've helped you and you've gotten results that have allowed you to move forward, then keep at it.
I actually uploaded the calculator because it came up in the thread about the new board, and I thought it would be interesting to share it. It's more of an experiment, a seed or an idea for a possible toolset for working with palettes than something concise. For example, I often wonder what colors I could use for this with the 2-bit palette, and here we can already find out, with the DAC configuration, which colors are available and what their values are.
Your scripts make me think it might be interesting to be able to pass an image to a given DAC and have it return a quantized version as faithfully as possible to your palette. Because if you don't take the DAC into account, the dithering is blind to what you can actually represent... I don't know, I'll keep thinking about it. In any case, cool topics.
Thanks a lot, Joaquim!
--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/75ddaf07-cf45-4b56-9bf9-98ee46810f8en%40googlegroups.com.
Jesus Arias
charli va
--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Jo mo
Good night guys.
charli va
Hey Joaquim! Speaking of hamsters, I’ve jumped on your wheel — I found a potential use for the calculator beyond just checking the color palette.
Your dithering exercise is great, but for low-resource situations (computational limits, memory, FPGA pins, etc.), it doesn’t really help us much.
What I mean is, for example, with your image — if I quantize it to 64 colors like you did, even without using dithering it already looks pretty decent:
We can zoom in and look at the pixelation details caused by the quantization, but as we can see, it’s quite “readable” or easy to visualize.
In short, we look for the most frequent colors and then find the closest match, like you did with k-means or similar algorithms, narrowing it down to a palette of just 64 colors, resulting in something like this:
That would be great if we could actually choose those colors to draw, for example, on the VGA with the Alhambra. But the reality is that on the Alhambra we only have these colors (obtained with the calculator and the resistor configuration from Jesús’s board):
If we loaded the image into the FPGA and displayed it, we’d see this (the same image as above, quantized to 64 colors):
Zooming in, we can see the colors it actually uses, since our real display palette has nothing to do with the original image:
I’m sure anyone who’s played with VGA on the Alhambra at 2 bits per pixel and tried to render an image has run into something like this.
If we implemented a similarity-based color remapping system—working in Lab color space and doing thousands of floating-point operations—we could make the image look this good on the Alhambra with our palette. That could be pretty interesting, but on these small FPGAs it only really makes sense to do it offline and use images already prepped for our palette:
In the close-up, we can see that the algorithm blends colors to create similar visual impressions when viewed from a distance:
The problem is that doing this in real time is not feasible on our small FPGAs, but—as I said—it’s very appealing if what you need is to show a few fixed images or sprites that you can precompute beforehand.
With that in mind, it occurred to me that we could use a couple of algorithms very close to the three-color printing process, and they’d be implementable on our FPGA in real time. I kept running some proof-of-concept tests and, starting from your original image (the raw one, with no conversions), rendered on the VGA with our palette it would look like this (Bayer 8×8):
…and here’s another one—slightly lower quality, but it should use far fewer resources (2×2 superpixels):
At some point I’ll implement this on the FPGA—it seems interesting and useful, and it lines up with a few ideas I’ve had. But if anyone wants to take a crack at it in the meantime… ;) If you’re interested in the code, let me know and I’ll share it. I threw it together quickly just to test the concept and it’s not presentable right now, but if there’s interest I’ll clean it up properly.
As for the calculator, it might be nice to export palettes to CSV or some other script-friendly format (I exported from the browser console, and it made me think a handy “button” would be useful), and maybe even include some of these algorithms to convert images based on the palettes. What do you think?
Thanks a lot, Joaquim! With everyone’s input, really cool things come out.
Good night!
Jesus Arias
charli va
The last two algorithms that i post (8x8 Bayes and 2x2 SuperPixels) are extremely efficient in terms of resources and calculations, i only use in software but they are very hardware friendly.
I think it will be a very interesting exercise to do with your new shield, comparing the pros and cons of each.
Jo mo
1- on my script, we have a quantization to a palette of 16 colors (not 64)
2- About this image you posted "quantized to the 64 colors for Alhambra" i think your simple replacement of the two 64 palettes is weird. there is a big palette usage problem here, due to a rotation 180 degrees between the 2 palettes, your images looks like a negative one!? (eg; the almost black spaces which are between the stones appears almost white in your converted image)
Imodified my RGB444 script to generated the mini-palette of 16 colors chosen in the RGB222 palette (future Jesus Alhambra hat friendly ;-)) see joined script
All this is a question of trade off between quality of image and FPGA resources usage (Bram but also logic cells if we do some graphic treatment on the images like image/sprite rotation for example)!
