lokathor/imagine

Barebones image opening library.

Hi, I work on Rust stuff.

imagine's Issues

Remove miniz_oxide dependency

At least for when decoding, a zlib decoder should be a small enough module to not pull in an extra dependency at all.

We might keep the optional use of miniz_oxide for encoding images with good compression rates.

format: JPG / JPEG

https://en.wikipedia.org/wiki/JPEG

format: JPEG XL

• https://jpeg.org/jpegxl/

[bmp] Converting bitmasked data into RGBA8 should use SIMD

BMP allows for data to be encoded in a "bitmasked" form where bitmasks define the location of channel data within a u16 or u32.
This leads to each channel (R/G/B/A) being treated separately through several math ops.
Since we have 4 channels all doing identical operations, this lends itself very naturally to using SIMD.

Of course, since BMP is not a popular format, the percentage of use cases that would see a benefit from this gain is perhaps quite small. Still, when there's time it wouldn't hurt.

Preferably this would be done once portable-simd is stabilized, because it's not worth keeping the crate nightly-only for.

tag things that require features in their rustdoc

The Cargo.toml and lib.rs is already set up for this, we just need to mark individual elements with a doc(cfg()):

Example:

#[cfg_attr(docs_rs, doc(cfg(feature = "alloc")))]

And replace on whatever feature name. This can (I think) go on modules, types, free functions, etc.

Maybe we just need to mark modules and the rest of obvious enough? I guess we don't want to get too spammy with it.

format: WEBP

• https://en.wikipedia.org/wiki/WebP

[png] The chrm and gama chunks should have a constant with their srgb equivalent value

It should be more obvious the relation between gamma / chromacity chunks and the srgb chunk (which implies a particular gamma / chromacity value).

[png] Allocating "automatic" parser for PNG files

We probably want a few possible top level functions here:

• Get he "direct" data. This involves many option values, and probably different enums because of different pixel formats, and so on. Or maybe you get a Vec and that's good enough because you just cast the slice when you need it? In that case what to do we do about 16-bit channels? Turn them to native-endian maybe and the cast will just work out?
• Get the RGB8, "somehow". In this case, we upscale lower channel/depth things. If there's an alpha channel, perhaps we blend the image over top of an imagined background and then give the RGB of the composite?
• Get the RGBA8, upscale stuff, whatever it takes.

---

Output data is probably:

• width
• height
• pixels
• colorspace info (usually srgb, but not always)
• ??? do we need more?

Decoders should return iterators

It seems best that the decoders simply return iterators that produce (x, y, P) triples, rather than accept a callback.

[bmp] Header reading/writing functions should probably use references rather than owned arrays

We're passing some pretty hefty sized arrays. If an inline fails to happen, we'll be moving a lot of data across the function bound for no big reason.

Then again, how often do you open a bitmap? And assuming that you're doing a heap allocation too for the pixel buffer, maybe it's not a big deal.

Still, probably something to do.

format: GIF

• https://en.wikipedia.org/wiki/GIF
• https://www.w3.org/Graphics/GIF/spec-gif89a.txt

format: JPG2000

• https://en.wikipedia.org/wiki/JPEG_2000

format: TIFF / TIF

• https://en.wikipedia.org/wiki/TIFF

bmp: restore

We just need to restore bmp support from the 0.0.8 version

format: QOI

• https://github.com/phoboslab/qoi

Not yet fixed, though they're close to having a version 1 defined. Since a goal of the project is that the decoders/encoders are easy to write (at the expense of most other things) then this should be easy to do.

format: PCX

https://en.wikipedia.org/wiki/PCX

this is probably simple enough to add, because the WP page lists BMP as "more sophisticated" than PCX.

[png] IHDR chunk parsing should check the CRC

Other chunks it's probably fine to maybe have a bad CRC, but with the header we want to have a little extra confidence before we proceed all the way through the file.

format: APNG

• https://en.wikipedia.org/wiki/APNG

netpbm: restore

bring the netpbm support back from the old 0.0.8 stuff

format: EXIF

• https://en.wikipedia.org/wiki/Exif

qoi format support

format: PPM / PGM / PBM / PNM

https://en.wikipedia.org/wiki/Netpbm

pixel format: argb8888

The renderer api from SDL2 expects ARGB ordered pixels.

handle palette and transparency chunks

also possibly other chunks?

png: background color

the background color chunk is a very easy one to support

format: XPM / XBM

• https://en.wikipedia.org/wiki/X_PixMap
• https://en.wikipedia.org/wiki/X_BitMap

Clean up the pixel formats module.

We ended up not needing the 16-bit BE formats, or the pixel packed formats, they should probably go?

And we should provide standard conversions between the formats.

format: BMP

format: ICO

• https://en.wikipedia.org/wiki/ICO_(file_format)

png: transparency

lots of optional chunks we don't need, but transparency would be very good to support

format: XWD

• https://en.wikipedia.org/wiki/Xwd

benchmarks

Probably we should have some benchmarks, ya know.

`Image::vertical_flip` method

Auto-decoder size limit

We should place upper limits on how large of a file will be automatically decoded.

Apparently 16,384 is a common upper limit on textures, so a simple 17k limit seems fine I guess?

format: PICT

• https://en.wikipedia.org/wiki/PICT

[png] "Up" filter should use SIMD calculation

It's a small optimization in the scheme of things, but once portable simd is stabilized we should convert the "Up" filtering and unfiltering to use u8xN values.

In this case, we'd want to cancel the normal iteration we'd do using the "PB iterator" (which is byte at a time), just do all the math as wide as possible, and then re-iterate the line for output as if it was a None filtered line the whole time. This will give the correct output while also being significantly faster to compute. The math itself will happen 16x (or more) faster, though having to iterate the row twice will reduce the overall gains.

(Unfortunately, all the other PNG filters are not very SIMD friendly)

make bmp parsing be simd

now that netpbm pulls in wide, we might as well also use wide in the bmp parser.