Hacker News new | ask | show | jobs
by bob1029 1223 days ago
Very interesting. I will be digging into this one. The first thing that popped out at me:

> We can decompose a given image into the three color channels red, green and blue. Each channel can be represented as a (m × n)‑matrix with values ranging from 0 to 255. We will now compress the matrix A representing one of the channels.

I wonder if the author considered converting to YCbCr colorspace first. The luminance component (Y) is substantially more important to the human visual system than the Cb/Cr components. Some subsampling of the chrominance components would probably work well in these schemes.

2 comments

This leaped out at me too. Doing lossy compression on RGB is not setting yourself up for success. Of course, then you'd need two sliders in the UI; one for how much to compress the Y and one for the CbCr.

SVD also works on complex matrices. I imagine there's value in compressing the subsampled Cb/Cr channels as real/imaginary components in a complex matrix.

The representation by SVD would work almost identically. SVD is one of those absolutely magical, amazing algorithms that power a ton of things we do every day.
Especially if YCbCr is a linear transform of the RGB. (I'm not sure if it is, but it's likely to be close). If it is, it's essentially just making eigenvectors from a matrix with a different set of bases.
> is a linear transform of the RGB

It is for every implementation I've seen. I have it defined both ways as 4x4 matrices in my code (3x3 is not in System.Numerics).

It appears to be a linear transform from "gamma-adjusted" RGB. So probably not straight from sRGB. [1]

The article does not mention it, but I assume it just takes sRGB color components.

[1] https://en.wikipedia.org/wiki/YCbCr#R'G'B'_to_Y'PbPr