RGB565 Android splash screen format

[ejohnson0547]

This plugin will read and write to the RGB565 or RAW565 format. This format is used by the Android platform for the initial boot screen of the device.

It will also allow you to open a BMP, PNG, JPG or other image, then save it as a RGB565 file.

RGB565 is simply the raw pixel data of a bitmap file. It does not contain any header information and does not contain the dimensions of the image. The only thing that is known is the total number of pixels. When opening a .rgb565 file, the user must specify the height and width of the image.

Most of the Android devices today have a 320 x 480 screen. So the rgb565 file for that device will have 153600 pixels. The size of the file in bytes will be twice the number of pixels or 307200 bytes.

I have defaulted the height and width to these values when opening a file.

When saving a file, your image must already be set to the dimensions you want. (i.e. 320 x 480)

Here is the plugin:

Rgb565.zip

To install this plugin, simply copy the RGB565.dll file to the folder: "C:\Program Files\Paint.Net\FileTypes"

or wherever you have Paint.Net installed.

Enjoy!

[pyrochild]

Now I have to get an Android phone.

[jsg]

Can you help me out with how this plugin actually functions, in terms of actually converting between 24-bit data and the 16-bit format?

I took a sample image and saved it in rgb565 format. The size of the file seems correct for 16 bits per pixel. However, there's no obvious change in the image -- perhaps not that surprising at a high level. When I zoom in, I can see some very minor changes -- but there really appear to be very few pixels changed.

But here's the strange thing. When I reload the stored rgb565 file, and use the color sample tool to check the pixel color values, I see values that don't seem to make sense for 565 data. i.e., I'm expecting to see that all the red and blue values are multiples of 8 (least significant 3 bits removed) and that the green values are all multiples of 4 (least significant 2 bits removed). But I see no indication that any bits have been removed.

What am I missing here? Is some algorithm being used to stuff the least-significant bits so that they aren't just zeroes? (If so, what is the method, and doesn't that defeat the purpose of being able to see what the image will look like on a 16-bit display?)

Thanks for any insight you can provide.

Jonathan

[ejohnson0547]

You have to remember the 565 format is very strange. Going from 24 bit to 565 is simple, but the reverse is not.

Take white for instance in hex its FFFFFF.

Converting it to 565 format you get FFFF.

Looking at the bits you get RRRRRGGGGGGBBBBB. You can't simply insert 0's to get RRRRR000GGGGGG00BBBBB000.

That would be F8FCF8.

You would lose all the whites. Some call this the naive conversion.

There are two better ways.

If you can think of R5 as the 5 bits of red and R8 as the full 8 bit red

R8 = R5 * 255 / 31

Or

R8 = (R5 << 3) | (R5 >> 2)

For Green it would be:

G8 = G6 * 255 / 63

Or

G8 = (G6 << 2) | (G6 >> 4)

The second formula seems to be the one this is using. It simply replicates the higher bits into the undefined lower bits.

My code is simply calling the standard C# functions to load a bitmap in the RGB565 format.

bitmap = new Bitmap(width, height, 2 * width,

System.Drawing.Imaging.PixelFormat.Format16bppRgb565,

scan0);

[jsg]

Thanks, Eric. After posting, I went back through some pixel samples and reached the conclusion that the MSBs were getting replicated into the LSB slots. (I was originally symied in looking for such a pattern by getting confused as I switched between R and B (with 3 bits eliminated and restored) vs. green (with 2 such bits).)

I appreciate your point regarding white, though I'd bet that one would have to look very carefully in order to see such -- the eye naturally adjusts it's "white balance" based on what it's looking at, so I'd guess that, in almost all cases, when looking at a 16-bit only display, for most images, it would perceive as white those pixels that were originally white, even if they actually had a very slight green cast due to the extra bit.

Anyway, does anybody know whether it is typical -- or even standard -- for 16-bit displays to render data in this fashion. That is, effectively inflating the data back to 24-bit, and using this kind of LSB stuffing algorithm, prior to rendering?

That is, doing this may be a smart way for an app to convert a 16-bit picture to 24-bit, for use on 24-bit systems. But does it reflect what actual results are likely to be when rendering the 16-bit picture on a 16-bit display?

[bsinclair]

quick question, will this be able to save BMP, 16-but, RGB565 format? This is the default image format for Windows Mobile.

Thanks.

[guix]

Hello, any chance that you share the source code? I would like to write a custom export format but I need some example plugin. Thanks!

[Ego Eram Reputo]

There is a Visual Studio FileType template here: http://forums.getpaint.net/index.php?/topic/7984-filetype-plugin-template-v20/

[guix]

There is a Visual Studio FileType template here: http://forums.getpaint.net/index.php?/topic/7984-filetype-plugin-template-v20/

 

Have you tried it? Because it doesn't even compile. It's almost 6 years old.

 

 

After hours of searching I finally found a source code of another export plugin, it compiled and worked. But it didn't help a lot since what I want to do is totally different, which is why I would like the source code of this particular plugin since it is almost exactly what I want to do: export an array of RGB565, but with an additional byte for each pixel, that is the pixel's transparency.

Edited October 19, 2013 by guix

[Ego Eram Reputo]

Have you tried it? Because it doesn't even compile. It's almost 6 years old.

 

It's a tool.  How powerful it becomes depends on the hand that wields it. 

 

Did you update the references to the later Paint.NET dll's?

[guix]

It's a tool.  How powerful it becomes depends on the hand that wields it. 

 

Did you update the references to the later Paint.NET dll's?

I solved the errors and made it compile, but being new to C# and never used bitmap etc functions, I'm lost at what to do next... I will ask few questions in the development forum.

Edited October 22, 2013 by guix

[Ego Eram Reputo]

That you got it to compile mean you've already learned a lot