You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to be able to load a paletted image format (png, bmp, gif, etc) and retain the palette and palette index values as separate elements of the image.
My specific use case for this functionality is loading paletted images and re-packing them for use as data declarations in assembly code.
Imagine an image that's 4 pixels wide and 1 pixel tall, with indexes 1,1,3,2. After processing, the image would turn into assembly code like this (note: % indicates a binary literal in this assembly language)
db %01011110
This is more generally applicable to any application working with paletted data that would like to load a paletted image ans manipulate it directly, instead of getting an RGBA image and having to re-quantize all the values. For example, an application that wants to check if two images have compatible palettes.
Draft
A new variant can be added to the DynamicImage enum, ImagePaletteRgb8 is a suggestion for the variant name.
The image data itself would be a 2d buffer of u8 values, and the palette would be a Vec<Rgb<u8>> holding the color value for each index.
Even images with less than 8 bits per pixel use a full u8 per pixel when the data is decoded into memory. The realities of rust make working with sub-byte data excessively annoying. If an image has a sufficiently small palette the data could be packed down into fewer bits per pixel when encoding the data to a particular format.
Supporting a separate variant that's Rgba is probably not necessary. Similarity, supporting palettes of more than 256 colors is probably not necessary. They can be added in the future if the need arises.
The text was updated successfully, but these errors were encountered:
I think this would be a better fit for the low-level ImageDecoder interface. That trait could gain additional methods to extract the palette and to request that read_image return the raw palette indexes, rather than the pixel values themselves.
Trying to make DynamicImage support paletted data would mean we'd have to implement rotation, scaling, and such for paletted images. And would be another variant that potentially all users would have to worry about, rather than being transparently handled like it is now.
That would be acceptable. I don't need to apply image transformations, so more simple support for format detection and decoding to a provided buffer would be sufficient.
I would like to be able to load a paletted image format (png, bmp, gif, etc) and retain the palette and palette index values as separate elements of the image.
My specific use case for this functionality is loading paletted images and re-packing them for use as data declarations in assembly code.
Imagine an image that's 4 pixels wide and 1 pixel tall, with indexes 1,1,3,2. After processing, the image would turn into assembly code like this (note:
%
indicates a binary literal in this assembly language)This is more generally applicable to any application working with paletted data that would like to load a paletted image ans manipulate it directly, instead of getting an RGBA image and having to re-quantize all the values. For example, an application that wants to check if two images have compatible palettes.
Draft
A new variant can be added to the
DynamicImage
enum,ImagePaletteRgb8
is a suggestion for the variant name.u8
values, and the palette would be aVec<Rgb<u8>>
holding the color value for each index.u8
per pixel when the data is decoded into memory. The realities of rust make working with sub-byte data excessively annoying. If an image has a sufficiently small palette the data could be packed down into fewer bits per pixel when encoding the data to a particular format.Rgba
is probably not necessary. Similarity, supporting palettes of more than 256 colors is probably not necessary. They can be added in the future if the need arises.The text was updated successfully, but these errors were encountered: