Importing, Exporting, and Blitting Compressed indexed pixel formats?

[Shadowblitz16]

Can we get support for compressed indexed images with a pixel bit depth less then 8?

I need to store a very large number of 8x8 tiles and doing so with color data is not possible due to how it would bloat the file I am saving it to.

I would love to be able to blit Compressed indexed bitmaps directly to a Rgba surface, this way I don't have to expand the tile data in memory when drawing it.

[JimBobSquarePants]

It seems to that you have a packaging problem, not a drawing problem. If file size and avoiding expanded working sets are the goals, use an indexed format that already packs bits:

• PNG with a palette at 1/2/4 bpp in a spritesheet. You get DEFLATE compression, tiny files, and bit-packed scanlines.
• GIF can also store 1–8 bpp indices with LZW, but PNG usually compresses better.
• WebP-lossless sometimes wins due to its palette transform, but PNG is the predictable baseline.

ImageSharp’s drawing/processing model requires TPixel : IPixel<TPixel> round-trips to Rgba32/Vector4, so there is no path to blit compressed indexed data directly onto an RGBA surface without converting indices at write time. Pick an indexed on-disk format, keep tiles in a spritesheet, and decode to RGBA when rendering.

[Shadowblitz16]

The game I am making is an editor and it packs all the game assets into a single binary file.

External assets are not an option because I am trying to emulate how old school consoles did graphics without actually writing a emulator.

I also like the idea of all my sounds, graphics, and objects stored in a continuous array.

Also that's what I want is to convert the indexed pixels when blitting them. Just not needing to uncompress the indexed bitmaps all at once.

Could something like a IImage<TIndex> where TIndex : IIndex be made where the IIndex interface supports multiple pixels?

Then there could be support added to blit between IPixel and IIndex Images?

[antonfirsov]

@JimBobSquarePants's recommendation is to do all your drawing on uncompressed images, then compress the result in some way, for which the easiest method would be to use existing formats indexed formats, however you can also create your own encoding/decoding method. This may lead to a little bit bigger memory footprint since you need the working Image<TPixel> source/destination instances, but in the end of the day, such a method would be more CPU efficient.

External assets are not an option [...]
I also like the idea of all my sounds, graphics, and objects stored in a continuous array.

Codecs can work with a memory stream, no need to save stuff into external assets.

It's unlikely ImageSharp would implement support for indexed Image in the foreseeable future, since it's a very complex architectural-level problem.