I'd like to see this in xpra.
Does anybody have an idea if QOI+lz4 would improve compression ratio further?
QOI: Lossless Image Compression in O(n) Time
111–120 of 303 posts
Re: QOI: Lossless Image Compression in O(n) Time
#112Out of curiosity, I modified the benchmark program to simply toss the pixel data into lz4/lz4hc for comparison (patch file: https://paste.debian.net/1220663/ ). I'm actually quite impressed how the resulting size is a little bit smaller than lz4hc (actually not even that far away from libpng), while the encoding speed is quite close to lz4, despite seemingly not having as many hacks and tweaks under the hood to get t…
What about qoi followed by lz4?
Re: QOI: Lossless Image Compression in O(n) Time
#113QOI_DIFF24 { u8 tag : 4; // b1110 u8 dr : 5; // 5-bit red channel difference: -15..16 u8 dg : 5; // 5-bit green channel difference: -15..16 u8 db : 5; // 5-bit blue channel difference: -15..16 u8 da : 5; // 5-bit alpha channel difference: -15..16 } It bothers me more than it should that the 5-bit signed differences aren't -16..15 matching two's complement but -15..16 instead.
I should probably fix that. Is there a clever way to unpack a 5bit signed int other than treating it as unsigned and subtracting 16?
You'll have to shift the values around anyway, so:
int intermediate = byte_or_word int value = intermediate >> bits_per_int - 5;
Instead of masking rely on arithmetic shift right to keep the sign bit.
Re: QOI: Lossless Image Compression in O(n) Time
#114I immediately thought of a use-case for (a modified version of) this: raw compression in cameras.
Currently Sony has two options. Uncompressed raw that is huge, or lossy compressed raw that is half the size. They probably chose those options because throughput when shooting quickly matters a lot, so something like PNG would slow down shooting too much.
I imagine a blazingly fast halfway decent compression algorithm would be great. It might even speedup shooting by needing to write fewer bytes. But in general people taking star pictures will love having compression without it being lossy.
For reference an uncompressed raw file for 44MP is about 90MB. That starts filling up drive space rather fast.
Re: QOI: Lossless Image Compression in O(n) Time
#115I know you don't like "design by committee" and overly complex formats. Also, the compression algorithm itself is somewhat independent of the "container format" that it's used with. However, if I may make a suggestion: If you do end up rolling your own container format for any reason, always include a way to store the colour space of the image! Treating RGB images as arrays of bytes without further tags is like treat…
I've never understood the need for color profiles on images themselves. On monitors and displays, sure, those vary, but why allow people to specify a color profile on an image, thus making images no longer a ground truth for pixel value? It seems like the main use case is dealing with images that already have color profiles. What is the point?
Re: QOI: Lossless Image Compression in O(n) Time
#116I know you don't like "design by committee" and overly complex formats. Also, the compression algorithm itself is somewhat independent of the "container format" that it's used with. However, if I may make a suggestion: If you do end up rolling your own container format for any reason, always include a way to store the colour space of the image! Treating RGB images as arrays of bytes without further tags is like treat…
I work in a VFX adjacent space, so I have some pretty strong feelings about what data should be stored in the colorspace tags. The colorspace data should be an arbitrary string. I would also like to have "usage intent" tag for whether this is color or non-color data. You would think that the colorspace would tell you, but people do silly things like save specular maps as sRGB. For completeness I would want the following fields:
- colorspace - arbitrary string, the colorspace of the color data on disk.
- rgb_primaries - arbitrary string, indicates the physical meaning of the linear RGB values.
- transfer_function - arbitrary string, indicates the function to use to linearise the values from disk into the RGB primaries.
- intent - one of display, texture, data, or an arbitrary string. Display images get tone-mapped, textures do not, data only gets linearised, even if it has rgb_primaries attached, other values only have internal meaning to the concrete art pipeline.
For the first three, rgb_primaries and transfer_function take precedence over colorspace. The reason I want them is because people do mix and match. You could say that you can put the same data in some string format in the colorspace tag, but then everyone will invent their own slightly different way of specifying it and interoperability will suffer. Best to just force the values to be unstructured.
A lot of arbitrary strings, but that's how it is - there is really no standard list of colorspace names. These four fields can cover pretty much everything I have seen people do.
Though currently a lot of people just tag the filename with a colorspace suffix and call it a day. OpenColorIO even has a function to directly get a colorspace from a filename.
Re: QOI: Lossless Image Compression in O(n) Time
#117I know you don't like "design by committee" and overly complex formats. Also, the compression algorithm itself is somewhat independent of the "container format" that it's used with. However, if I may make a suggestion: If you do end up rolling your own container format for any reason, always include a way to store the colour space of the image! Treating RGB images as arrays of bytes without further tags is like treat…
I've never understood the need for color profiles on images themselves. On monitors and displays, sure, those vary, but why allow people to specify a color profile on an image, thus making images no longer a ground truth for pixel value? It seems like the main use case is dealing with images that already have color profiles. What is the point?
A color space and color profile are not the same. The point is knowing what a byte represents in a byte array. Is it red, hu, saturation, alpha, brightness etc?
Re: QOI: Lossless Image Compression in O(n) Time
#118This is as cool as it gets. I have a honest question about the source code, a lot of time since I coded anything meaningful in C, but I remember the header files did not have that much code on it, while here I see most of the code is in the header file. Why is this the case? Inline compilation? What are the advantages?
a lot of people seem allergic to using the linker these days.
As a result you have to inline all their code, which is usually ridden with warnings so you can't compile anymore with sane options like -Werror.
It's not like using an actual library is really hard in the age of cmake and meson.
Re: QOI: Lossless Image Compression in O(n) Time
#119Are there compression algorithms that take longer than O(n)? My impression is that even two-pass encoding is O(n) with a large constant factor in front of it, but I’ve never actually thought this much about it.
Re: QOI: Lossless Image Compression in O(n) Time
#120This algo would work well for computer generated synthetic images, not as well for scanned images.
Which is why the author is positioning it as an alternative to PNG, not JPEG.