Indexed32 IPixel type?

[Shadowblitz16]

How would you guys implement a Indexed32:IPixel<Indexed32> type?

I thought about maybe defining it as a uint Index and a ImmutableArray<IPixel> but there is two problems.

1. array types can't be in unmanaged structs
2. even if they could IPixel doesn't pass the palette information when converting from and to types.

[JimBobSquarePants]

What's the use case for this type?

Palette information in ImageSharp is metadata, essentially providing information about the original encoded palette and providing a palette for quantizing to during encoding if desired.

Each ImageFrame<TPixel> buffer contains the fully decoded pixel information as a given TPixel type. These types have rules which required them to be convertible utilizing Vector4 as the conversion space and they have to be fast at doing so.

When you decode a Gif or other image format with a palette the decoder will decode from the compressed buffer of indices into the final TPixel format.

[Shadowblitz16]

What's the use case for this type?

Well I was using it for direct conversion between true color and indexed bitmaps for avalonia ui.

Palette information in ImageSharp is metadata, essentially providing information about the original encoded palette and providing a palette for quantizing to during encoding if desired.

I was trying to directly load and save it from file AND a custom binary file.

Each ImageFrame<TPixel> buffer contains the fully decoded pixel information as a given TPixel type. These types have rules which required them to be convertible utilizing Vector4 as the conversion space and they have to be fast at doing so.

Can't they just do a lookup when converting?

return Palette[Index];

When you decode a Gif or other image format with a palette the decoder will decode from the compressed buffer of indices into the final TPixel format.

Idk what this means

[JimBobSquarePants]

Well I was using it for direct conversion between true color and indexed bitmaps for avalonia ui.

ImageSharp can already convert between true color and indexed bitmaps, it's simply a matter of providing the correct encoding options.

return Palette[Index];

A lookup against a palette in this manner wouldn't work. Many operations are destructive, and you would almost immediately end up with pixels in your buffer that cannot be represented by the inbound palette. For example, consider resizing an image. The pixel values for an image are the result of weighted sampling of the surrounding pixels within a given radius. You would have to quantize the image after every operation in order to match your inbound palette.

Idk what this means

A GIF image uses a palette (or color table) which contains a fixed set of colors. Each color in the palette is given an index. When the GIF image is stored, the actual image data is compressed using LZW encoding, but what it essentially contains are indices pointing to colors in the palette.

During decoding, ImageSharp decompresses the LZW data. This gives a sequence of indices. Each index corresponds to a specific color in the palette. For each index, ImageSharp looks up the corresponding color in the palette and adds the color in the requested TPixel format to the pixel buffer of each frame. This allows for direct rendering of the image without additional work.