JPEG XL

Looks like they use Akamai's image service

So could very well be that they did just that

I dunno what Akamai uses as avif encoder and settings but likely they did some basic testing to pick some settings that produced somewhat lower bpp than what they produced for webp, and called it a day

https://twitter.com/richgel999/status/1470696769470271493

🤔 Even the WebP team <https://github.com/phoboslab/qoi/issues/48>

>The width and height should be clamped to reasonable values. Currently a QOI image could be 2^33 pixels: is it supported by the current implementation? We would advise storing each dimension on 14 bits with an offset of 1, making the width and height within [1..16384] each, avoiding the useless values ‘0’. The maximum number of pixels would be 268 435 456, which still fits in a plain int when multiplied by 4 channels. This is safer. lol at this point im kinda sick of webp-ish ways of limiting things tbh

also downvoted :v)

The webp way makes sense from the perspective of a short term content delivery format, much less so for a longer term storage format.

I think the security implications are around denial of service. For example if you decode user supplied images, and someone provides an image that compresses really well, but decompresses to multiple gigapixels (such as a single solid colour), it is very likely your program would run out of memory and crash.

IIRC it was intended as a proof of concept format, but a lot of people are running with it.

It's because they don't know about formats like JXL <:kekw:808717074305122316>

Also, they want super simple formats to implement.

It is perfect as a hobbyist project, as it is simple enough to writer a decoder in a weekend.

Their uploads are really limited.

I know I've submitted jxl images as jxl.txt before to get them to upload.

People just love single header libraries.

Anyyyway, <@!853026420792360980> how is the ffmpeg libjxl stuff going?

Has anyone reviewed your patches or whatnot?

Well, let me ping an ffmpeg developer that I can directly talk to 😄

it's going, I've been quite busy

it works but there's two main issues

in particular, it's not able to read from a pipe, which is a problem, and I believe it's due to a lack of a parser

so I'm writing an internal parser for the codec, although the decoder will be libjxl-dependent

the parser will be lavc only, and the parser code in lavc will be called from the prober in lavf

that's dated 2020

but yea, in other news I discovered two bugs in libjxl when writing the wrapper so that was fun

(both have been fixed)

Either way, I have tomorrow off so the plan is to get to it tomorrow

Well, in that case, is it ok if I talk to the ffmpeg dev about it?

She's quite the special one, so I'm sure she'd be glad to help/review the patch if she has time 😄

sure, also keep in mind the patch v6 that's in the mail list did get some discussion on IRC

and it's not going to be the final version

https://www.da.vidbuchanan.co.uk/widgets/pngdiff/

That's a neat one

The insisting on 14-bit dimensions is silly. We do encounter plenty of real images in the wild on the web that are larger than that - obviously typically the other dimensions is small. For those images, we cannot use webp but have to fallback to jpeg or png...

> We recommend the following order: header, ICC if any, pixels, XMP if any, EXIF if any. That's a bad idea: exif can have orientation and intrinsic dimensions, so it's better to have it early

sounds like the goal is to fit the number of pixels (or even subpixels) in 32 bits... but why? you can use 64 bits

Why would you even need to compute the number of pixels?

Anyway, it seems like a bad idea to design a format in such a way that it is simply impossible that an image will be too large to fit in memory

I have to say I still don't really understand the use case for QOI

It seems to be a combination of a GPU texture format and a regular image format, combining the disadvantages of both.

Am I missing something?

```c uint8_t *framebuffer = (uint8_t *) malloc(width * height * channels * sizeof(uint8_t)); ```

i don't think it was really meant to be practical, more just to play around with image compression. that it's not very far off png's efficiency is an accident.

for playing around it's of course nice - low amount of code, fun to play with

but it looks like some people are taking it more seriously than a toy example, talking about final specifications etc

i could see utility if you want to really thoroughly audit all your dependencies

also it's very easy to integrate, although so is stb_image

I don't think there's a lot of stuff you can do if you want to thoroughly audit all your dependencies

100 lines of new code might be more dangerous than depending on a bulky and bloated but old and widely used library like libpng

well, sure. even qoi depends on libc and a kernel.

my point was that it's possible for an experienced C programmer to pretty much hold all of qoi in their head at once. i'm not sure that that's possible with any other modern format.

It didn't make it onto patchwork, for some reason

Here are the patches, tho

This patch doesn't properly handle ICC even though FFmpeg's PNG does

so I need to make tha work as well

or at least, properly tag the colorspaces

QOI is more about efficiency which is somehow better than uncompressed images while maintaining high encoding/decoding speed with maximum simplicity But, yes, in my opinion, the priority of format simplicity alone is not worth the sacrifice of efficiency and speed that can be achieved Considering that people already want to add this format to browsers, TIFF, for the new PNG specification, game and texture formats, etc.

Also, there are comparisons with JXL as well, although a bit odd (with `-e 9`), given that QOI was not intended as a format for superior compression <https://github.com/nigeltao/qoi2-bikeshed/issues/25#issuecomment-992923430>

I also did comparisons with QOI and additional fast PNG modes on my test set, including QOI+Zstd, QOI+LZ4, QOI+Brotli, theoretically such options could be used with file system compression or on the Web and sometimes compression could be better than PNG, but still this use is quite niche

If you want to compare `.ppm.xz` or any image format `.xz` I wrote a GDK-Pixbuf loader for that

https://github.com/thebombzen/xz-pixbuf-loader

I chose formats with very fast decompression, LZMA btw was worse than Brotli with maximum compression (for QOI in general) Decoding speed is usually more important, although LZMA is faster at encoding than Zstd/Brotli

sure, and my code is MIT licensed so if you want to change it to work with any zlib-like API then feel free

it makes previewing images easier, cause then it'll work with GIMP, eye of gnome/eye of mate, etc.

like "did it work?"

There is also ZPNG, as far as I understood it is something like PNG with Zstd and more efficient and faster predictors

At this point though you might as well just use .ppm.lz4 or something

if your goal is fast lossless

Yes, that's exactly what I did, comparing different formats with good compression ratio and high decompression speed, Lizard/LZ5 is also good in its category (but, it's not widely used) Or there are some other formats: <https://github.com/inikep/lzbench/blob/master/lzbench18_sorted.md>

But, the point of LZ4/Zstd is that they can be used transparently in file systems (except Windows), and Brotli is supported in all modern browsers, without any additional plugins/apps so options how to use such additional compression are wider

A comparison with -e 1 would be more interesting

Yep, but at the moment JXL decoding speed is not very good compared to other formats, even lossless WebP, it would be better to compare after the upcoming optimizations

Decode speed of -e 1 encoded images should be better than the general case

modular mode is far slower than VarDCT I've found

I'm not entirely sure why

Because modular does rewrite the quantizer it loads every time

Vardct is simpler like 28 mpxs only lossless jpg transcode no modular tools right

But with modular tools you add those they are slow

Like 1.8 mpxs at speed 7

Yes, it should be, because different methods are used, it is basically lossy-lossless, and effective lossless methods are usually much more complex

Or max 3,6 mpxs

also lack if optmizations for cases that COULD be optimized

Don't expect more than this on i3 330m

No arm i think should be even x3 times better

Because there is more artificial intelligente Better ram

but in higher compression modes itll probably always be slower than vardct

But it depends on the speed you do

Yep

Also jon sneyers has explained this on latest jxl message

There is patches that is slow

And is a modular tool

One of the slower

I'm aware that modular is slower because it's basically lossless mode, but I was wondering if there was something else, like if it was much less well-optimized or something

the algorithm itself is slower, sure, but has there also been a higher effort placed into VarDCT?

yes there has been

Cause I'm usually at the point where I consider true lossless not even worth it when VarDCT d=0.2 is good enough for my purposes and *far* faster

It is less optimized at the moment, but lossless modes are always more complex and slower

sure, but that means more room for improvement is what I'm thinking of

Also https://discord.com/channels/794206087879852103/794206170445119489/916646398139703297

so lossless mode uses a decision tree to context model each pixel - it's definitely not meant to be fast 😆 (pretty similar to FLIF in that regard) in the future we might implement a few more specialized codepath that emulate say what web-ll does, but not there yet

Btw, using the LZ77 algorithm is still the most optimal for their tasks, since there are many other LZ variations?

LZ77 is mathematically the same as LZ78 for the most part, but it's better to implement in software since the dictionary is fixed-size

it's also true that VarDCT was designed for speed from the start, while Modular comes from FUIF which was initially designed for code simplicity

https://twitter.com/richgel999/status/1471645249156046856

https://twitter.com/richgel999/status/1471646274906726402

Is he ignoring the fact that you can make the formats encode faster while not losing much compression efficiency, if at all?

One benefit of QOI is that it literally has zero encoder options, which makes the Pareto analysis very easy

Yep On the one hand yes, but on the other hand, when I started making this comparison, the goal was to evaluate compression efficiency of various image formats which can be used specifically as image formats, not just storage formats, besides most of them have not yet had good optimization of encoding/decoding speed or even format finalization (so the speed comparison was almost useless) But, speed/efficiency comparisons are also needed, which can be added later

I see 🙂

However, to say that this comparison is not valuable anymore is also incorrect, basically it is to say that QOI and other fast formats are not valuable because most other formats have better compression, it is just different needs from these formats For Web use, for example, the goals are different, since hardware performance increases over time, it makes much less sense to use faster and simpler formats with worse compression than formats with higher compression, using more complex and slower methods, but with enough speed for practical use

Especially the concept of complexity, like very simple formats is good for faster understanding and creating different implementations, but is this simplicity is worth the loss of efficiency and speed if they are beaten by a more complex format?

Also encode speed and decode speed are rarely symmetric, and encode-once decode-many-times is the common thing for web images

(as opposed to general-purpose web compression like gzip/brotli, where a common case is encode-once decode-once: the html often gets generated per request and compressed on the fly)

https://twitter.com/richgel999/status/1472100826730663944

yeah they never mentioned valuable to who

high encode speed is not valuable to me

High encode speed is useful for local workflows - saving an image when you're still editing it, or temporary image files that will not be in storage for a long time

So yes, there's a trade-off between speed and density, and different use cases justify different trade-offs

I've been improving the faster speeds for lossless jxl: https://github.com/libjxl/libjxl/pull/1028

The slower speeds are still very slow to encode, the gap between -e 3 and -e 4 is quite big now

I think -e 1 can still be made ~10% faster after that PR

And then we could try to make an -e 0 that sacrifices some more density and is about twice as fast as -e 1

<:Thonk:805904896879493180> https://twitter.com/richgel999/status/1472509304557158401

https://twitter.com/MaxGraey/status/1472524345935335431

Hm, I think if a lot of people have such a need for simple and fast encoders, then in the future it might even make sense to make something like a separate lightweight JXL lossless encoder with only a very fast mode like in QOI or RLE + arithmetic encoding or something like that

You are reading my and <@179701849576833024>'s mind 😅

<:Poggers:805392625934663710> https://github.com/libjxl/libjxl/pull/1032

early christmas present by <@!179701849576833024> ^^

<@!794205442175402004> feel free to share some numbers 😉

(I was bored this weekend :P)

A comparison with QOI and fpng would also be interesting <https://github.com/richgel999/fpng>

I did some very simple testing and I think it's 1.5x faster than QOI and 1.2x denser or so

well, Jon did some of those

(without multithreading, to be clear...)

not sure about fpng but it should be a similar picture

I mean on Jon's data this is in the same ballpark of compression as *optipng*

just, huh, *a bit* faster?

you do need AVX2 though

(I mean NEON would work too, just didn't write it - and I'm sure one can make sse(3|4?) work also)

Also QOI Test Suite: https://phoboslab.org/files/qoibench/qoi_benchmark_suite.tar

What's the command to activate this fast-lossless mode, `--velucity`?

haha

so here are some initial results

😆 it's just a separate file, you don't need libjxl even 😄

left is density (smaller is better), right is speed (more is better)

basically we eat QOI for breakfast and have room left for fpng as a dessert

if I can summarize those results 🙂

There is also fpng_rle (but perhaps without sources yet) https://twitter.com/richgel999/status/1472505757547515909

to be fair, neither fpng nor qoi have nearly as much fun with AVX2 as my code does 😄 (compilers do part of the job, but still a 2-3x speedup comes from some manually vectorized code)

I believe qoi is pretty SIMD-hostile, but fpng could be SIMDfied without too much pain

Also many people might want a similar encoder but without almost any dependencies such as highway or openmp (although I understand that this will make the code much more complicated and I personally do not think that this is a good thing)

Where's the download button!? <:BlobYay:806132268186861619>

this is a single .cc file with no dependencies 😉

(well, except lodepng for reading input and the _main.cc)

https://github.com/libjxl/libjxl/tree/e9fa951ff5e20aa964eac7bbbe56631b92227266/experimental/fast_lossless just download the files one at a time?

(I realized there's a bug if the image is <= 256x256, I'll fix that...)

Does 10/12/16 bit images work?

it's hardcoded for 8-bit atm, like QOI and fpng

theoretically I think the approach could also work for 10-bit at similar speed

for higher bit depth there would probably be some speed penalty, no idea how much it would be

https://twitter.com/richgel999/status/1472924320397676544

tried it on this (well, only on the images larger than 256x256, due to the bug in fast lossless jxl encoding for single-group images)

QOI compressed the images to 8.00 bpp at 77.81 MP/s fpng compresses them to 7.84 bpp at 71.35 MP/s

fast lossless jxl encoding got them down to 6.80 bpp at 162.62 MP/s

<:JXL:805850130203934781> <:chad:768911266919088128>

There is also qoi-demo22 (seems to be faster and better) https://github.com/nigeltao/qoi2-bikeshed/issues/28

Is fast-lossless JXL encoding now faster than decoding?

yes, probably hard to make even a specialized decoder as fast as that encoder

I had quite a bit of fun 😉

well I don't feel like running 22 different QOI variants, I suppose some of them will be somewhat better

It's more like QOI version 2.2

https://twitter.com/jonsneyers/status/1472959101416226823?s=20

`cwebp -z 0` is also not bad for this compression

Yes, lossless webp hits nice trade-offs.

https://phoboslab.org/log/2021/12/qoi-specification

I'm not sure if QOI is actually much simpler than the subset of jxl that is used by luca's fast encoder (RLE-only, fixed prefix codes, fixed YCoCg)

Perhaps this is simpler for someone to understand

And yep, without a fast decoder, just a fast encoder may be less useful for some cases

Also, did this implementation for the fast encoder was the most logical and optimal, or other methods have not yet been tried?

I literally tried this in a weekend, there wasn't extensive study in it :P

One could do some amount of context modeling for example, and it likely wouldn't impact encoding speed much

https://news.ycombinator.com/item?id=29625084

How fast is the jxl decoder currently?

same

It depends quite a bit on what it has to decode

i'm downloading a torrent

Is that an image with lots of patches or something?

it utilizes my font suduwe

so essentially is lot a text like

but keep in mind that i'm downloading a toeent

so could be same speed

afte i finish downloading the toeent iwill ty again

how many patches the image has

There's no easy way to check, but you can decode with -s 8 to get an idea, or encode with --patches 0 to see how it affects speed and size

Admittedly it is more complicated ;)

Although the ARM version I just uploaded is 10x more readable than the Intel one ;)

I think fast-lossless JXL encoder is also worth a mention in this thread https://www.reddit.com/r/programming/comments/rkt6y5/losslessly_compresses_rgb_and_rgba_images_to_a/

Also, this is a speed comparison without PNG decoding time and since maximum speed is very important, maybe use the fastest PNG decoder and also add PPM support? Though also this fast standalone encoder should be minimalistic and without unnecessary stuff, but I think many people may compare total time including decoding

Wuffs seems to be the fastest decoder currently available (mango is proprietary), although I'm not sure how convenient it is to use

<https://github.com/nigeltao/qoi/commit/05cdef77eb472e17a3ef6e6d4e820de755af0d61>

<@!179701849576833024> There are also problems with compiling in Msys2 for Windows by default `../fast_lossless.cc:9:10: fatal error: 'endian.h' file not found` maybe add some minimal cross-platform build system like for libjxl?

I understand that there is no time or priority for this kind of encoder yet, but I have some thoughts for the future, like: - creating a separate repository for this fast implementation like for jxl-rs (for further discussion and integrations into different apps, like QOI does) - adding an API so it can be used and linked in as a library - adding another denser but still relative fast mode, like `-e 3` or more optimal for different kinds of content - adding a similarly fast decoder for these modes - adding 16-bit support for full PNG compatibility This is nice to have in libjxl, but narrower tasks can always be done better and a such implementation would be much simpler and lighter

Feel free to mention it! I don't think I should self-advertise :)

Yeah, I know... Tbh I only need that for endianness, to give an error if you are on a big endian machine, so probably there's a better way xD

Some of those might be tried in the future, but this is really very much a fun weekend project for now

I think you can use the .h directly if you want max speed :P

Yeah, I understand, I'm just looking at how popular QOI is, this format has been added almost everywhere in just a couple of days

Yes, Jon already mentioned, I'm just not very good at expressing thoughts in English and can't explain the details of this implementation

I'm ok with explaining the details afterwards if I get tagged or something :)

Or asked to, I guess

https://www.reddit.com/r/programming/comments/rkw5wz/a_challenger_to_the_throne_of_vector_graphics_svg/hpd6c0b/ interesting comment on SVG’s history

> But then Dominic Szablewski published the The Quite OK Image Format and showed me that there was interest in simpler formats. It inspired and motivated me to push for TinyVG completion and I got back to the project So the war for simple formats has begun

tbh I doubt it's going to go anywhere xD

I'd love a simple SVG competitor, SVG has enough features in it to near replace HTML

SVG2 adds a bunch of modes to disable things like resource loading and javascript, and there's a "native" variant that removes all of that as well

tinyvg looks promising

i really really really really want a vector format better than svg <:kekw:808717074305122316>

svg is _far_ beyond the kind of complexity that qoi was trying to avoid, well into bullshit territory

google/flutter was also working on an svg replacement: https://flutter.dev/go/vector-graphics

> SVG is really an application SDK that happens to include vector graphics (e.g. fully supporting SVG involves supporting XML, JS, DOM, SMIL, HTML, audio playback, keyboard, mouse, and touch input, form controls, HTTP submission, video conferencing, etc). Additionally, there is no clearly defined subset of SVG to target if one only wants "vector graphics": the modern version of SVG Tiny involves supporting JavaScript and video playback, while the original version of SVG Tiny requires an unusual subset of features, for example it does not support gradients, but does support custom fonts.

something just slightly more expressive than jxl splines would be nice as a vector format

say jxl splines + closed shapes with solid or simple gradient fill

I think that would be expressive enough to represent everything you need, while being simple enough to write a simple renderer in few lines of code

and more importantly: avoid the security headaches of having to implement (and sandbox) various turing-complete languages just to show an image

Hmm, I compiled the Windows version, but it seems that the encoded jxl images are incorrect 🤔

Like this

However, if at least the sizes are correct, it will be enough for me for some tests

I just pushed a fix for that 😄

(I mean for endian.h)

let me try that PNG...

mhhh works on Linux

what's your compiler?

msys2 clang

I will try to recompile with the fixes

I doubt it will change anything

what happens if you disable the -D flag?

Hmm, without -D and with fixes it's still the same And my CPU has AVX2 support

ok so the problem is somewhere else

oh

I'm silly xD

``` diff --git a/experimental/fast_lossless/fast_lossless_main.cc b/experimental/fast_lossless/fast_lossless_main.cc index 08b2af06..18bb459a 100644 --- a/experimental/fast_lossless/fast_lossless_main.cc +++ b/experimental/fast_lossless/fast_lossless_main.cc @@ -56,7 +56,7 @@ int main(int argc, char** argv) { encoded_size = FastLosslessEncode(png, width, width * 4, height, &encoded); } - FILE* o = fopen(out, "w"); + FILE* o = fopen(out, "wb"); if (!o) { fprintf(stderr, "error opening %s: %s\n", out, strerror(errno)); return 1; ```

try that?

(stupid Windows...)

Yep, it works

great

fwrite was replacing all the 0x0a with 0x0d 0x0a...

it is cool to see that even a really fast jxl encoder can still have decent compression

Can you share your build? 🥺 <:Windows:806135372298977342>

Do you also have `libgcc_s_seh-1.dll`? ^^

And also `libstdc++-6.dll`? x)

`libomp.dll`...

might want to make a static build

`libwinpthread-1.dll` ... please?

> Would be nice if that would become a new default standard. Considering how widely used PNG is am not sure this is realistic I'm not sure why people want to completely replace PNG with qoi, considering (fom my understanding) it has worse compression

Yep

Like JXL, AVIF and other modern formats (while having much bigger benefits) did not have as much hype and desire for people to implement everywhere as possible, as with QOI

woke image formats are popular

the fact it is easily understandable is likely a big part of it's popularity

is it that much easier than png

yes

easier enough for basically anyone to be able to understand how it works

qoi is good for its own usage but it should not be used by everyone 👍

tbh png is not that complex

deflate is simple enough, and PNG on top of that just adds chunks and simple prediction

sure maybe the details of the bitstream are not entirely trivial, and then you have things like palette etc

but the chunks exist for a reason...

i think it's even easier to understand the chunks as each row

so all you really need to know is png is just deflate

and each row being a chunk means it can be progressively decoded

definitely way easier to implement if all you need to do is run deflate on data

oh I meant things like sRGB chunk etc

i.e. metadata

yes, the HN thread showed that some people don’t seem to realize what color management is even for

which is okay in the general population but unfortunate if pushing for a format that lacks it

historically there was also an implementation quality issue that _discouraged_ proper color management for at least a decade

spent some time tweaking things and made it 5-10% faster and ~1% denser on screenshots

Experimenting with different group sizes for this kind of fast encoding mode can give any improvements or is the default already the most efficient?

Larger groups are just better for compression here, but not by much

And it hurts potential for multithreading

Yes, but I also meant a smaller group size, for QOI, as far as I remember, someone experimented with 64x64 tiles or something like that For JXL lossless the smallest is 128x128 and maybe with simpler encoding methods, efficiency losses will be lower than for slow and complex modes, but there will be advantages in higher threading or theoretically possibility to use less memory

<:Thonk:805904896879493180>

> decades of optimization

One day of optimizations from veluca counts as one decade

could you link this reddit

https://discord.com/channels/794206087879852103/805176455658733570/922735088150654988

sometimes I do get jealous

<:FeelsSadMan:808221433243107338><:FrogSupport:805394101528035328>

oh well, I guess that's how github stars work

I wish there was a button to transfer some of those FLIF stars to libjxl 🙂

doesn't feel right that flif has more stars than libpng and libjpeg-turbo combined, wtf

haha

new paper just dropped. haven't looked at it yet and I don't pay much to the DL compression people, but it's Qualcomm so I'm tempted to read it

https://arxiv.org/abs/2112.11312

so it's definitely nothing groundbreaking (at least for images) 🤷

Strange point of view, considering that the Wuffs author is also one of the most active participants in the development and has created many of their QOI implementations, as well as the fact that QOI does not bring any new revolutionary solutions that would surpass the other already known and are behind only because not enough optimized

And also the problem with QOI is that any faster or more efficient solutions are rejected for adoption in the format if they look even slightly more complicated, because the main priority in QOI is the maximum simplicity

at the end are they suggesting QOI _encoders_ could get better, or the QOI _spec_? there's a massive difference

as in, i think writing an optimal encoder given the current spec is trivial

they just said in theory it could encode at 500 MB/s (I assume they meant MP/s)

probably just nerd-sniped? I've also seen Nigel Tao in the IconVG discussion, so...

Yep, he seems to be interested in such things

https://twitter.com/richgel999/status/1473589374914805770

Btw, these precomputed dynamic Huffman tables can be also useful for fast-lossless JXL encoder?

working on it 😉

well, mod the train and the bug

try beeing as quick as possibly or the hype might have ended x)

it's my plan for today xD

1 MP is 4 MB in 8-bit RGBA, sometimes people express it in MB instead of MP

well they were referring to the tweet which iirc was showing MP/s ¯\\_(ツ)\_/¯

tfw the qoi spec is vague

i mean it's cool that it's short i guess but i don't feel confident implementing an encoder and decoder using only the spec, specifically because of edge cases

<@456226577798135808> Honestly, these results don't really make sense: https://discord.com/channels/794206087879852103/848189884614705192/923362379151073351

https://twitter.com/richgel999/status/1473905677273866242

<:FeelsReadingMan:808827102278451241>

Looks like the history of my repos

https://twitter.com/richgel999/status/1473922895911034880

So a good set of images to generate is also important or at least the most useful and usable for such fast implementations 🤔

Although, it also depends on what amount of time takes Huffman coding, for example, in the latest Zstd release it also significantly speeded up and this improvement is noticeable on the overall performance <https://github.com/facebook/zstd/releases/tag/v1.5.1>

Also, it would be interesting and useful to use something like only maximum asymmetric methods for a slower and more efficient mode, not as slow as the current cjxl, but for example something between PIK/`-e 3` and `-e 7` in efficiency, but faster and with very fast possible theoretical decoding This is a very popular thing for cases where very fast loading of very large amount of data is needed or for some game engines (with decoding speed even faster than PNG or at least the same speed per core) Maybe also a script that would merge fastjxl into a single header file like stb_image, as this is often liked by many devs And have own benchmark tool in the future, for example with functionality like qoibench or based on benchmark_xl but with external encoders/formats (depending on which one is more accurate and convenient)

Something like lossless PIK with fixed things would be good, but with more efficiency for non-photographic content (like to have efficiency always be overall better than well optimized PNGs on different images)

isn't fjxl pretty close to a single header already? 😄

(except decoding, ofc)

Yep, but I meant for the possible future or maybe encoding and decoding in different files, just like stb

I'm going to stick with single file for the encoder anyway

a single-file jxl decoder is not something that's going to happen, I think

but you can statically link with libjxl_dec

But, I meant about only fast_jxl and if there was the same fast decoder purely for fast_jxl images, but if there is a code which can be reused and there is no particular benefit from a separate encoder and decoder, then I think the files split makes not much sense

I want to avoid getting decoders out there that can only decode a subset of jxl. That's an interoperability timebomb, and risks reducing jxl to a de facto subset of what it is

(this notoriously happened with jpeg)

not to SVG, however

so maybe it’s ok as long as a complete decoder establishes itself first

to make sure that the cases where people resort to incomplete implementations truly are niche use cases

and not just “that’s all we have”

Yes. In particular if the subset is faster to decode and easier to integrate, I think there's a substantial risk it gets more adoption than the actual full decoder, and that is an issue then.

I think it's better to just make libjxl as fast as possible using specialized code paths

The use cases where you cannot afford the binary size of a full jxl decoder are probably very limited

We could add compile flags to make custom libjxl_dec builds with reduced functionality, but I think it should be easier to integrate the full decoder than to integrate such a subset-only decoder, so it's more likely that the latter is only done by people who know what they're doing

Hmm, yes, that might be a best solution, except that the complexity, code size and binaries will be bigger Btw, the speed of decoding fast_jxl images could theoretically be the same as their encoding speed?

likely not

These encoding methods are faster than decoding?

it's harder to SIMDfy huffman decoding unfortunately 😦

Is ANS better for SIMD and is it much slower in terms of decoding speed?

Because as I said before, something with very fast decoding and good compression is also quite useful thing

Would Zstd compressed raw RGBA data be any good for that?

Image format encoders will usually always be better than compressors for general data, since this is a narrower and better known task, at least if not using special data pre-filtering for better compression

Fair.

png is pretty much a preprocessor + lz77 😄

If you push things for speed, encoding is faster than decoding because the encoder knows all pixel values from the start while the decoder first needs to decode them

So the encoder can do prediction with simd but the decoder cannot

With huffman, the encoder can encode 16 symbols at a time and concatenate them, but the decoder cannot take the concatenated bitstream and decode 16 symbols at a time

Faster decoding could be possible by decoding multiple groups in the same thread so you can process multiple huffman streams with simd, but that gets very tricky to implement and in terms of memory locality it doesn't sound very appealing to work on 16 groups at the same time

And ANS is much slower in theoretical decoding speed?

Not much

It's probably similar enough to huffman in decode speed

Mostly slower / more annoying to encode

And you cannot do different parts of the bitstream in parallel and then concatenate them like you can with huffman

<:PepeGlasses:878298516965982308> https://news.ycombinator.com/item?id=29661498

I find it interesting that nobody is looking at JXL or WebP as very fast formats <:kekw:808717074305122316>

someone's suggesting zstd for lossless audio <:Thonk:805904896879493180>

> ZStandard is a very good compressor, with an especially fast decompressor. Maybe someone should try using this instead of zlib in an audio format (FLAC, WavPack, ...)

flac and wavpack don't actually use zlib do they?

now say that about jpeg xl 🤭

No, they use their own entropy coders.

lol zstd compresses one audio file i had lying around far, far worse than flac

surprising no one

anyone with a hacker news account feel like replying? https://news.ycombinator.com/item?id=29666336

Yes.

> _Who_ cares that it's not set up for simd? > Seriously, who? > This project is interesting because of how well it does compared to other systems of much higher complexity and without optimizing the implementation to high heaven. We can all learn something from that.

can we?

> QOI is designed with a very specific purpose in mind, which is fast decoding for games. This kind of image will be very unlikely be large enough to benefit from multi threading, and if you have a lot of them you can simply decode in parallel. It’s not meant to the the “best” image format. but it sure would benefit from SIMD...

Indeed <:kekw:808717074305122316>

GPUs are just SIMD units 😛

Rather, SIMT.

Also, I'm pretty sure that the main purpose in mind for QOI is just simplicity.

I think speed and simplicity were the main selling points of qoi.

which reminds me of an old post about LightDM I believe

which was similarly touted as being much less code than GDM

the article pointed out that it achieved that by leaving out a whole bunch of features (for example relating to accessibility)

and that if it added them back, it would likely end up with a similar amount of code as GDM

not sure if that prediction ever came true but I guess we could check

the conclusion was basically “sure, it’s easy to have a lightweight codebase if you remove most features”

so not a very new lesson from QOI, it would seem

Damn it, why not just work on a standard that already exists?

We already have enough formats with YUV, multi-threading, multiple bit depths, etc.

https://www.reddit.com/r/AV1/comments/rkcx0o/we_need_to_rethink_avif_lossless_mode/

> Avif is coming now already and for companies there's just no reason to switch to JXL 🤔

https://www.mdpi.com/2079-9292/10/3/360/htm

> avif is much faster than jxl on the slowest speed do people not realize how dumb a comparison this is? like, i could make libjxl win by deleting all the presets except lightning, but that would make the encoder objectively worse <:kekw:808717074305122316>

Try the 'slowest setting' of fjxl 😛 (it has only one setting)

anyone know where, in practice, JPEG is actually decoded in hardware?

I assume in cameras

lol https://stackoverflow.com/questions/46497948/is-it-possible-to-use-hardware-jpeg-decoding-on-android-and-if-so-how

Intel CPUs since ivy bridge have had hardware for decoding JPEG in quicksync video

yeah but i'm not aware of anything that actually uses that hardware

But I don't know how widely used it in by software.

except maaaaybe if you have a webcam/capture card using MJPEG

Yeah. I think most things just use software decoding.

trying to argue against "no jpeg xl hardware decoding"

hell, even AVIF isn't decoded in hardware afaict, although it would probably benefit more than any other codec <:kekw:808717074305122316>

The thing with images is that they much more often exceed the limitations of hardware acceleration, as compared to video.

Is webp hardware accelerated anywhere. vp8 has acceleration hardware right?

vp8 depending on the device

nvidia has hardware vp8 decode since maxwell except certain pascal cards didn't have it <:Thonk:805904896879493180> https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new

according to wikipedia, intel dropped vp8 support in RKL and ADL https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Hardware_decoding_and_encoding

idk about AMD

vp8 never really took off the way vp9 did so it wouldn't surprise me if we saw more lineups dropping it

Fair. I think that the only two major users that I know of are YouTube and webp.

youtube may have previously, but i don't think they serve vp8 anymore

just h.264, vp9, av1, and maybe 3gpp or some other old thing for feature phones

I think you can still get it on older videos.

I don't think they encode to it anymore though.

i remember seeing vp8 previously but i haven't seen any videos with it lately, including old videos

https://github.com/190n/yaqoi

docs coming soon TM but: ``` make ./enqoi -i foo.png -o foo.qoi ``` i'm pretty sure that encoding does actually work <:kekw:808717074305122316>

if i have time and motivation i wanna make it multithreaded

Isn't the original qoi also written in C?

yeah that's why it's "yet another"

i might make it multithreaded

MT encode seems easy enough - is MT decode possible at all?

i don't think so

well maybe with cooperation from the encoder, but there isn't really a way to indicate that

i did plan to write a decoder too but honestly that seems less interesting now

except maybe as some kind of "qoi inspector" that shows how different parts of the image were encoded

oh i just realized that my encoder is broken oops

oh the problems were deeper than i had thought

It's a bit silly that runs of 1 are allowed

In qoi

While you can already do a diff of zero also in 1 byte

could also do an op_index using whatever the last pixel hashed to

Yes, that too

ok i think i fixed this problem, but my output is still a little larger than the reference encoder <:Thonk:805904896879493180>

optimal encoding must not be as trivial as i thought

Well if it's not a run, then either a pixel is 1, 2, 4 or 5 bytes

ok seems like i missed an opportunity to use OP_LUMA

i definitely use it sometimes, because the reason for this result was writing that opcode incorrectly

Ah

You're not adding all pixels to the hash table

Or are you?

the only cases i don't are for run and index in which case the hash table should already contain the current pixel

Maybe you are

oh for luma i think i'm calculating `(cur_px.r - last_px.r) - (cur_px.g - last_px.g)` instead of `(last_px.r - cur_px.r) - (last_px.g - cur_px.g)`

but in that case it's weird that my output decodes correctly <:Thonk:805904896879493180>

Is it actually using that option?

you mean OP_LUMA? yes, 34,396 times on that image

ohhhhh

my `op_luma_compatible` function doesn't account for wraparound

the current pixel goes from `#ffffff` to `#0f0f0f`, so the difference is `-240`, but you can actually make that work by encoding a difference of `+16` because of overflow

ok i'll fix that later today

I just noticed too

You shouldn't use int16 for the differences

Just use uint8 for everything

just uint8?

yeah that makes sense

Then you get the wraparound automatically

(can reinterpret it as int8 if you want, or just change the conditions)

sike i fixed it now

i now have identical output to reference on at least that random screenshot, i'll test more later

thanks for the help!

If I would do a QOI, I would do it like this: 111: run of 2 to 31 pixels, special cases for direct RGB or RGBA pixels like in qoi 100xxsaa: all channels unchanged except channel xx which gets a value -4..+4 (s is sign, aa is amplitude-1, zero diff cannot be expressed) 000xxddd: same but don't write the pixel yet (read next code first and apply it as if the previous pixel was what you have after doing the diff) 101xxxxx: 5-bit hash 001xxxxx: 5-bit hash but don't write the pixel yet 011ddddd xxxxxxxx yyyyyyyy: copy 2 to 33 pixels (given by d+2) starting 0 to 255 (y) rows above this pixel, at x position -128..127 (signed x) from the current positin.

time to make ur own qoi extension™️

<:Thonk:805904896879493180> https://twitter.com/richgel999/status/1475789363183239174

im already tired of this QOI meme

https://c.tenor.com/pu_reybkdMYAAAAM/quoi-what.gif

https://c.tenor.com/xXSj3e2-zcQAAAAM/jdg-quoi.gif

I mean, QOI is good as an experiment, but why add it to real working apps, it's a simple format, easy to integrate, but, for everything else, the advantages are very questionable

Well it's not worse than, say, BMP

It has little value as an interchange format though - it does nothing that PNG cannot already do

BMP mostly exists because it's a very old, proven and well-known format, from a time when maybe there wasn't anything better and BMP support is not that common nowadays, especially in modern apps, usually PPM is more common for a lightweight format And for Basis Universal, I think using FPNG from the same author would be a better solution (especially since it's just a replacement for the encoder/decoder, not adding a completely new format)

What I think would be useful is something like PPM/PAM/PFM/farbfeld that works for any number of channels, with multiframe support, and bit depths up to 32-bit float.

As an uncompressed format to pass things between applications like imagemagick and ffmpeg

Ah and with a way to store an icc profile too

Something like this: 8 bytes: magic (0x1337DA7A "img\0") 1 byte: planar or interleaved (0=planar, 1=interleaved) 1 byte: bitdepth (valid options are 1..16 and 32, bytes per sample is 1, 2 or 4, samples are stored as uint8, LE uint16 or LE binary32 float, padding zeroes in the msb, so e.g. 10-bit is done as uint16 with range 0..1023) 2 bytes: LE uint16 nb_channels 4 bytes: LE uint32 width 4 bytes: LE uint32 height 4 bytes: LE uint32 nb_frames 4 bytes: LE uint32 icc_length (if zero: implicitly sRGB) icc_length bytes: icc profile blob Image data itself: If planar: samples[frame][channel][height][width] If interleaved: samples[frame][height][width][channel]

https://twitter.com/phoboslab/status/1475936085737938945

data:image/avif;base64,AAAAIGZ0eXBhdmlmAAAAAGF2aWZtaWYxbWlhZk1BMUIAAADybWV0YQAAAAAAAAAoaGRscgAAAAAAAAAAcGljdAAAAAAAAAAAAAAAAGxpYmF2aWYAAAAADnBpdG0AAAAAAAEAAAAeaWxvYwAAAABEAAABAAEAAAABAAABGgAABBsAAAAoaWluZgAAAAAAAQAAABppbmZlAgAAAAABAABhdjAxQ29sb3IAAAAAamlwcnAAAABLaXBjbwAAABRpc3BlAAAAAAAAAPAAAACgAAAAEHBpeGkAAAAAAwgICAAAAAxhdjFDgQAMAAAAABNjb2xybmNseAABAA0ABoAAAAAXaXBtYQAAAAAAAAABAAEEAQKDBAAABCNtZGF0EgAKChgd++f7ICGg0IAyighE+QAoFChZ+PAga+9CwCrDFRkyzczpUZpkWDrAIpVqUUkzDZRC010BI4K+3EY0rOItBrtbnIkgt7WsvzwzPh4RgI53oD93YlXhc9zwKgE60SwxTw3S3qsQpa+3GCNGi+OuXHvlM0B8hvKiEKpdzWgWt8wt2Y5yD+SDr3j9DtXwHKC9+d0lFeFUWSrNqDBp4SwnzjcdIaugDnEs2NV+Kqu7Zo+e/5spzyqOfBFsdskRDl5QmeRIE3mzwe3NqsGZk7S7Cc6NXI4jQfflXkulWQbkoHDkihpR1QMMdbDB9EG16gomABYEOuQLhUrrQW6xEpYZUuHIMy90w7jDnIkFfUptoLdwdO8slz4za8PV3RqlWajXu/yNC2IPhpPQoF7bjL2pVgx1ImAwPfgMa3/rSjmNOv9iAyU+EEyXBePQjWNDTmqecIPTmoF9K3n/0/r+VnUqwUYm+dSc25GBpngseIUD7OPKjWsZeAa/OtMVlYwkoyLgLkPbm7OjC3IoRxcDK7pCjLYGbyV4KxXSEO0vnVZWsXKvVEQtsXZ80CnmG3yMFma+8cutQUgnxEw0qJx+K5QR0Dif21i5GOvETUTHHgFfnHF35QRdBgway96bL4EUJLxjvftEppQ8gB8GIfOF3a8FsuTfSdnO302cqwVsK5yKLxWPxu8dDv6EnRY7X06a5dqcoJeny5nC4J0DjX9tskKCySLoREnAcSKvwYCux4LJpYDqnbm1uYsi7fk1nkiwsVmyo/ZP0KuKq2nblcfAwQ1sRHCwxELfltZZG9kaKTntRkb5S6N/VZUa3CP0YWAqT5c7oPadP2i526brpX2yKyDT+IQIuYbXXZZFN2m+duyhBFuY/H6lxUkXhdPEtNoyNf4+JWIFt3sYig9r83zBaG6eULQhr/zOXc8h0Fiybvn8Zz1MNmXh64k/IvRACC0kTsfFzY2oTiywaOlbMvLOvOVAejyjFpZl7evYme63r4mBfYZVxptdPcY1mAWQ0DOOa+/4Bk2PHOuYdXMSOwe+0X9zqogjEBr00lPifvZMf+vcFgsB/tiM+W+B2/FchVcDJWDrHbcQpn27gKs3j5+wiIOCI9/qSyw0VsCeyEMgRGUhWqNRHwBsZmrhGFijUnuytEDTD4FC3A0PEzVQKl+1/PTJKScFVSCyl6eOfOWrsJh8ZgnP6nKg3eeEtIULZVgSomS7ElBDNrI/o3QWV7vRHeWRsx2ENi3zLYtOk7w6JkrkmuDDjh4EvwcWjlVwrNbITjUZat5l9IQfOx8vwfbq77TPRiQ1CVR0Fd+ZmqquBQ0yCiswp0whDG0qwwhENGPOFH/rPTOEWdXsgR2lw/0sIviJhHUqAnwg6xqhb3qyikHRzGl3/HNZVeqWzg==

https://c.tenor.com/oQBk2zzwYBgAAAAM/aaaa-cat.gif

(the avif header in base64)

A jxl starts with `/w` in base64 and from there on it can basically be anything

When the optional container is used, it will also have some AAA (zero bytes)

https://youtu.be/59jHEoNSlA0

2 bytes of 'overhead' for naked jxl, 42 bytes for containered jxl, ~250 bytes for avif iirc

Where 'overhead' is defined as signatures or redundant header fields

https://cdn.discordapp.com/attachments/677266163994198020/925852791908499556/matrix-trailer-ssa.mkv

So it's a subtitle (Substation Alpha) encoded video