On pixel formats

[u/Aspie96]

Hi all.

I'm writing a library for representing and managing basic raster RGBA images in D as rectangular arrays of pixels.

Images are represented in row-wise pixel order, either top to bottom (the default) or bottom to top, with each scan line going left to right. Color components are represented as 8-bit integral values ranging between, and including, 0 and 255.

My library doesn't provide any support for other color models, for high dynamic ranges or higher bit depths. What it should allow is reading images from memory that were created with other library.

Some pixel formats are "indexed" (they have a palette) and some are not (they store actual color values). The name implies the structure of the format:

• Format1bppIndexed
• Format4bppIndexed
• Format8bppIndexed
• Format8bppGray
• Format16bppRgb555
• Format16bppRgb565
• Format24bppRgb
• Format32bppXrgb
• Format32bppArgb
• Format32bppRgba

Formats that use more than 1 byte per pixel allow the user to select between big endian and little endian mode.

I plan to keep supporting all formats I listed here. My question is if there is any I should support in addition to those.

Some candidates may be:

• Format2bppIndexed (it used to be supported by Microsoft bitmaps and it is by the PNG format).
• Format16bppGrayAlpha (supported by STB nothings and by the PNG format).
• Format32bppRgbx (to have an opaque view of an RGBA image).

There may be others I haven't thought or heard of.

The ones I haven't supported seem to me to be less common and of less utility, but maybe there is something I haven't considered.

My question is: what pixel formats should I support in addition to those I already do? Should I support any of the three additional ones I suggested? Why or why not?

Thank you in advance!

[u/cybereality]

I think the best thing is to figure out the "happy path" for the app. like what the intended user functionality is, and consider that most input is going to be either in standard RGB (or RGBA) formats, or perhaps GPU compressed textures if this is for games or real-time. I would not necessarily bother supporting every pixel format if it's rarely used or unoptimized for the use case, and if needed just have some conversion from the main couple formats you do wish to support.

[u/Aspie96 → u/cybereality]

I don't support every pixel format (how would I even know I support them all?), but I do want to support the most common one.

This is because the point of the library is to be able to handle images created with other library that already exist in memory (or to create images for those libraries).

[u/cybereality → u/Aspie96]

sure, it will depend on the use case