Hacker Newsnew | past | comments | ask | show | jobs | submit | Nanopolygon's commentslogin

HALIC is by far the best lossless codec in terms of speed/compression ratio. If lossy mode were similarly available, we might not be discussing all these issues. I think he stopped developing HALIC for a long time due to lack of interest.

Its developer is also developing HALAC (High Availability Lossless Audio Compression). He recently released the source code for the first version of HALAC. And I don't think anyone cared.


Thank you for the information! Appreciate it. Will look into this more.


AVIF/AV1 is a codec that encodes both lossy and lossless files very slowly. JXL is significantly faster than AVIF. But AVIF provides better image quality than JXL even at lower settings. However, AV2 will require much more power and system resources for a small bandwidth gain.


> But AVIF provides better image quality than JXL even at lower settings.

I don't think that's strictly true.

The conventional reporting has been that JXL works better at regular web sizes, but AVIF starts to edge out at very low quality settings.

However, the quality per size between the two is so close that there are comparisons showing JXL winning even where AVIF is supposed to out perform JXL. (e.g. https://tonisagrista.com/blog/2023/jpegxl-vs-avif/)

Even at the point where AVIF should shine: when low bandwidth is important, JXL supports progressive decoding (AVIF is still trying to add this) so the user will see the images sooner with JXL rather than AVIF.

---

There is one part where AVIF does beat JXL hands down, and that's animation (which makes sense considering AVIF comes from the modern AV1 video codec). However, any time you would want an animation in a file, you're better off just using a video codec anyway.


To be fair, those comparison image size aren't small enough. Had it been 30 - 50% of those tested size AVIF should have the advantage.

But then the question is should we even be presenting this level of quality. Or is it enough. I guess that is a different set of questions.


If you are really going to do something new, I recommend that you proceed through a work that is very good at this. For example, HALIC(High Availability Lossless Image Compression). It is both extremely fast and has a very good compression ratio, and memory usage is very very low. There is also very strong Multithread support already. I think something like this would be great for the new PNG. Of course, we don't know what the author of HALIC thinks about this.


Solutions such as OptiPNG and Pngcrush require extra processing power on top of the already slow PNG. But in most cases they are still behind.


Champion! I wish you hadn't commented so ignorantly. Please also try to look at the processing speeds! Or you can also try not to comment at all...


HALIC does almost the same degree of compression tens of times faster. And interestingly, it consumes almost no memory at all. Unfortunately, this is the case.


HALIC being faster still doesn’t mean that lossless JXL is so slow as to warrant hardware acceleration.


Yes, I also think that HALIC should be destroyed ;)


QOI is just a simple filter. It cannot do full compression. In fact, in certain cases it can increase the size instead of compressing. It is unnecessarily overrated, of course, mostly because it is open source. The rest is irrelevant. There are another codecs that is as fast as QOI (or even faster and multi-core) but with a much higher compression ratio.


QOI is just a simple filter. It cannot do full compression. In fact, in certain cases it can increase the size instead of compressing. It is unnecessarily overrated, of course, mostly because it is open source. The rest is irrelevant. There is another codec that is as fast as QOI (or even faster and multi-core) but with a much higher compression ratio. HALIC (High Availability Lossless Image Compression). But because it's closed source, it definitely didn't get the attention and respect it should have gotten. And that's why I think it stopped developing.

https://github.com/Hakan-Abbas/HALIC-High-Availability-Lossl...


>>> In fact, in certain cases it can increase the size instead of compressing.

Fwiw, all (lossless) compression algorithms will increase the size of some inputs.


> Fwiw, all (lossless) compression algorithms will increase the size of some inputs.

They rarely meaningfully increase the size though. Typical compression algorithms, when faced with hard to compress sections, can add a handful of bits to wrap them up. Total overhead a fraction of a percent.

When QOI encounters noisy pixels, it has to spend an extra byte per pixel, inflating the file by 33%.


one pretty simple qoi improvement would be a tag to say to store the next n pixels uncompressed. I think there's room in the tags for adding it


I wanted to use HALIC but ended up using SQZ instead. QOI is overrated but QOIR and my own QOIX are a bit more interesting, albeit ultimately stupid.


A simple filter may still do wonder if it is carefully chosen ;-)

The apparent death of HALIC was indeed unfortunate, I've heard that its decoder was less than 1K lines of code so it must have had a carefully designed and optimized context model in its heart. But there are so many other formats that are F/OSS but weren't highlighted enough anyway...


For a format to proliferate as a standard, it has to be open source. Nobody cares about 5% smaller images if not everyone can view them.


Historically speaking, that’s not true; WMV and FLV were extremely popular for over a decade in the early 2000s. Closed source formats can, and have, become de facto standards if they solve a pressing need that open standards don’t (or provide a stepwise increase in functionality or performance) and if there’s sufficient market demand.


In lossy mode I think there is no difference between AVIF, HEIC or JXL. AVIF is even a little bit ahead.

For lossless mode, JXL's fast modes (-e1 and -e2) are fast. But their compression ratio is terrible. The higher levels are not usable in a camera in terms of speed. Of course, my favorite and many people's favorite in this regard is HALIC (High Availability Lossless Image Compression). It is a speed/compression monster. The problem is that for now it is closed source and there is no Google or similar company behind it.


Last time I tested, libjxl e1 had a better compression ratio than default libpng, while being two orders of magnitude faster. See https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#the...

The point of reference here is not PNG but lossless JPEG, which was the best available option in DNG before version 1.7 of the DNG spec. Lossless JPEG compresses worse (but faster) than PNG.

I don't know how HALIC works but if there is no FOSS implementation available that seems like a no-go.


> In lossy mode I think there is no difference between AVIF, HEIC or JXL. AVIF is even a little bit ahead.

AVIF is definitely not ahead for the high quality levels you'd use in photography. AVIF is ahead at lower quality levels.

> For lossless mode, JXL's fast modes (-e1 and -e2) are fast. But their compression ratio is terrible.

JXL lossless e1 is still a lot better than the lossless compression people tend to use for photos these days. Like Apple has been using Lossless JPEG, which sucks.


Agreed. At camera quality jpeg xl is far ahead in quality. Apple's last announcement is about camera quality, close to lossless kind of lossy. In this domain jpeg xl does not have real competition. AVIF and HEIC don't even support more than 12 bits of dynamics, and become slow when quality is increased.


>AVIF is definitely not ahead for the high quality levels you'd use in photography.

I read the parent's point of comparison in terms of speed, not quality.


Hakan; Ignore the open source stuff for now. I speak as someone from within the industry. You may not listen to me and be upset later. If those who say this had done even half the work you did, be sure they wouldn't be talking like this.

It seems that there is a serious effort. And your work clearly crushes other codecs. This will cause serious discomfort in some circles. I don't know much about HALIC, but it is said that it is also a very serious work.

There's no point in rushing for open source. First of all, improve your work as much as you can. If serious offers come later, you can evaluate them. Don't give up control.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: