Re-ranging (mapping) values in C/C++

[Solidus]

Alright, so because that doesn't describe much, I'll give y'all some information.

I'm working on an FPGA display controller (as that seems to be a popular thing to do with them ) and I'm tailoring the setup for an old, 1990's era laptop screen, the laptop being a Texas Instruments 4000-series (if you didn't know TI once made laptops, you're not missing much!)

Thing is, it takes 9-bit color (512 colors), so 3 bits for red, green, and blue.

Problem is, no modern file format for images uses 9-bit data (in bitmaps, it's either 8 or 10), so how would I take an image that is 10-bit color (1024 possible combinations) and map it to 512 combinations?

I know the Arduino language (modified Processing/C) features a map function that would accomplish this, but I am looking to do it in industry-standard C or C++, maybe even C#, so that way I can easily have a Windows GUI where I load the file, deconstruct it pixel-by-pixel, and send it over a COM port to the FPGA that will load the data to RAM and then display it.

Any ideas?

 

[KrisBlueNZ]

Reducing colour resolution is easy - you just throw away the bottom bit(s) until you get the number of bits you want.

For example, if you are converting from 16-bit colour where the value is split into a 5-bit red intensity value, a 5-bit blue intensity value, and a 6-bit green intensity value, and you're converting it to 3+3+3-bit, you need to throw away (ignore) the bottom two bits of the red and blue values, and the bottom three bits of the green value.

If you're talking about palette-mapped images, then you need to convert the colour number values to RGB values before you reduce their resolution. File formats like 256-colour GIF include the palette at the start. You would need to reduce the resolution of each R, G and B value in the palette, and store that information somewhere so you can translate colour values instantly into R, G and B values with reduced resolution.

This is also how you would have to handle palette-based video systems like EGA and VGA. Modern hardware doesn't use palettes; these days it's 16-bit or 32-bit with R, G and B values bit-allocated within each value.

 

[Solidus]

Okay - that makes sense - bits are arranged from most to least significant, so chopping the lower bits just cuts detail.

One of the reasons I like C# is it features a number of non-standard, integrated parameters that allow the system to better handle various forms of data - one of those is the System.Imaging class.

I've already written a basic command-line tool that takes an image and deconstructs it into basic color information - this is handled all within the class, so the program does it regardless of filetype provided that type is supported by the system. It so far outputs every pixel in the form of (R,G,B) values ranging from 0 to 255 for each, so if I were to use that, I would simply need to add a serial interface for Tx/Rx, and rearrange the order in which the program processes the image to make it easier on the FPGA processor and hardware.

So far what I'm trying to work out is to have the FPGA processor receive the data over serial and then push it to RAM, where a hand-written VGA controller would take it out of RAM and push it to the display - that way, I avoid having to slow down transmission rate and other elements as well as synchronizing the whole of the FPGA.