Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A luma dependent chroma compression algorithm (image compression)

bitsnbites.eu

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Show HN: A luma dependent chroma compression algorithm (image compression)

#11

Post by theandrewbailey »

tverbeure wrote: post #6

AV1 has the CfL (chroma from luma) prediction tool. h.266 has CCLM (cross component linear model) and AV2 has improved CfL. When you see the AV2 version, it’s very similar to h.266, which is more advanced than AV1 CfL: they are using filters that cover up to 6 luma pixels to determine the chroma baseline. The algorithm described in this blog post is pretty close to what AV1 CfL does.

> The algorithm described in this blog post is pretty close to what AV1 CfL does.

This checks out. I've played around with AVIF, and noticed that it kinda traces high contrast edges and smudges the rest. Higher quality settings mean less smudging.

Re: Show HN: A luma dependent chroma compression algorithm (image compression)

#12

Post by mbitsnbites »

schobi wrote: post #8

Image and video compression has become a field that is painfully hard to enter. State of the art is complex and exhaustive, the functionality of reference encoders and comments/versions among them is really a lot. We are well beyond where a dedicated individual can try an idea, show that it is better and expect that others can pick it up (e.g. in standardization). It is not sufficient to run a few dozen images and ju…

I truly get that. That's also one of the reasons why I started from scratch once I got the idea, rather than researching all the available papers and implementations etc (because the latter is quite overwhelming, while the former took me about a week of spare time hacks).

My scope is also a bit unusual, I think, because one of the applications I'm thinking about is to "augment" luma-only codecs with chroma. One such codec is https://gitlab.com/llic/llic

But most of all, I wanted to learn.

Re: Show HN: A luma dependent chroma compression algorithm (image compression)

#13

Post by mbitsnbites »

fleabitdev wrote: post #9

You've rediscovered a state-of-the-art technique, currently used by JPEG XL, AV1, and the HEVC range extensions. It's called "chroma from luma" or "cross-component prediction". This technique has a weakness: the most interesting and high-entropy data shared between the luma and chroma planes is their edge geometry. To suppress block artefacts near edges, you need to code an approximation of the edge contours. This is…

Thanks for the feedback, and the interesting ideas. It's good to know that I was on to something and not completely off :-)

I'm mostly doing this for learning purposes, but a hidden agenda is to create a low-latency codec that can be used in conjunction with other codecs that deal primarily with luma information. AV1 and friends are usually too heavy in those settings, so I try to keep things simple.

Re: Show HN: A luma dependent chroma compression algorithm (image compression)

#14

Post by mbitsnbites »

ffworld wrote: post #2

You talk about an algorithm. However, you never visited any of the practical implementations of Chroma from Luma, which is used in Production. It is part of the AV1/2 video codec; for instance, it has been widely adopted too since 2018. https://arxiv.org/pdf/1711.03951 So do IETF early draft of the idea. https://datatracker.ietf.org/doc/draft-midtskogen-netvc-chro... Give a read of the work if not:)

Thanks for the references! After writing the blog I was looking for such references.
Post reply on HN