TRUECOLOR vs RGB8 about libspng

[randy408]

Shouldn't color_type be of type enum spng_color_type rather than uint8_t ?

The fields have the same size as the described by the file format, but I'll probably change that for the next breaking version.

it's pretty confusing to have two different types enum spng_color_type and enum spng_format that have names with identical meaning

When decoding you're converting from ihdr to an spng_format, or from an spng_format to an ihdr when encoding. Formats are different, it's color type, channel order, bit depth and endianness in one enum except for SPNG_FMT_PNG, SPNG_FMT_RAW which only specify endianness and the rest is derived from ihdr.

[GhostCore07]

The fields have the same size as the described by the file format

Correct. The issue is that you can assign a spng_format to uint8_t color_type due to enum implicitly cast to int. It's much better if the static checker to throw an error in this case.

When decoding you're converting from ihdr to an spng_format, or from an spng_format to an ihdr when encoding.

Thanks for the clarification. I understand the rational for having different types between encoding and decoding steps.

I will try to clarify the point I was trying to make with truecolor.

https://en.wikipedia.org/wiki/Color_depth#True_color_(24-bit)

True color (24-bit), the use of 24 bits to store color information
24 bits almost always use 8 bits each of R, G, and B

Therefore,
"TRUECOLOR" and "RGB8" have the exact same semantic meaning and it's confusing to try and understand why the API uses different words for the same thing.

In my opinion something like:
SPNG_COLOR_TYPE_RGBA8
SPNG_FMT_RGBA8

Makes it expressly clear that we are talking about a color type and a fmt type. Perhaps I will just make this a typedef for myself if you are not interested in changing the API.

[randy408]

The standard uses the term "truecolor", at the time it made sense to use the exact same words.

I wouldn't add something like SPNG_COLOR_TYPE_RGBA8 because the standard expresses color type and bit depth in separate fields. Some PNG libraries also have *_COLOR_TYPE_RGBA but bit depth is still a separate value.

Makes it expressly clear that we are talking about a color type and a fmt type.

But they already start with SPNG_COLOR_TYPE and SPNG_FMT 🤔

[GhostCore07]

Doesn't seem too far of a reach to have a COLOR_TYPE that combines the "truecolour"-ness and the 8 or 16 bit-ness in a single flag. That's just an observation. I see now that would be innovating on the standard a little bit. From a practical standpoint I was surprised to not see it is all. Take it for what it's worth.