JPEG-like DCT transformation

[jonsneyers]

See also #144.
A new transform could be added, which should be especially useful for (ex-)JPEGs but also for images in general to possibly improve compression and certainly improve progressive decoding.
Take 8x8 blocks, transform them in some lossless way using some kind of DCT, then replace the pixels by DCT coefficients in such a way that the most important ones are in the positions that get encoded earliest (in the interlaced pixel ordering).

[psykauze]

As I know of DCT transform, it is lossless. The thing that lose data (and improve JPEG compression) is the quantization coefficient. Quantization purpose is to delete some low coefficient frequencies.

[psykauze]

I've made some tests with 8x8 dct2 transformation via matlab on lukas_2d_8_breast_1_t.png file, it seem to be lossless (compare -metric AE = 0) and it improve both PNG and FLIF compression.
Original PNG (+pngout) = 993 613 B (FLIF0.2.0rc2 = 974 203 B)
Original PNG+Black borders (for matching 8 multiple) (+pngout) = 1 000 933 B (FLIF0.2.0rc2 = 974 439 B)
DCT Transform PNG (+pngout) = 606 917 B (FLIF0.2.0rc2 = 468 981 B)
Reconstructed PNG (+pngout) = 1 000 933 B

[jonsneyers]

Impressive!
On Feb 10, 2016 18:57, "psykauze" notifications@github.com wrote:

I've made some tests with 8x8 dct2 transformation via matlab on
lukas_2d_8_breast_1_t.png file, it seem to be lossless (compare -metric AE
= 0) and it improve both PNG and FLIF compression.
Original PNG (+pngout) = 993 613 B (FLIF0.2.0rc2 = 974 203 B)
Original PNG+Black borders (for matching 8 multiple) (+pngout) = 1 000 933
B (FLIF0.2.0rc2 = 974 439 B)
DCT Transform PNG (+pngout) = 606 917 B (FLIF0.2.0rc2 = 468 981 B)
Reconstructed PNG (+pngout) = 1 000 933 B

—
Reply to this email directly or view it on GitHub
#209 (comment).

[psykauze]

I'm really sorry, I've made a mistake.

The graphicsmagick package installed with octave can only work with 8bpp images but the "matlab/octave" DCT transform values need to be stored as "double". So, with my set-up the DCT image is corrupted because of the "double" to "uint8" conversion.

So, open an image, DCT transform it in a "double" matrix, Inverse DCT transform it and save it to png is lossless.

But, open an image, DCT transform it, store it as 8bpp PNG, open it, Inverse DCT transform it and save it to png is NOT lossless.

[psykauze]

I'm working on a lossless jpeg-DCT-like transform but for now I have some issues for storing the DCTed data due to float to int conversion.

Also, JPEG standard have many things that does not match FLIF algo, because:

1. The RGB to YCbCr method is different. It mean the resulting FLIF Y plane will contains some Cb&Cr info from jpeg.
2. The jpeg YCbCr planes have not necessary the same size (4:2:2 means Cb&Cr are horizontally half size of Y, 4:2:0 Cb&Cr are quarter size) and the jpeg DCT transform is made on all planes individually.
3. JPEG algo have also a DCT quantization method used for increasing entropy. Until FLIF can't implement and detect quantization values, it will be harder to FLIF to beat JPEG.

If you really want to compress ex-JPEG files you'll need to use the same YCbCr transform, the same DCT transform, planes with different sizes (4:2:2, 4:2:0, ...) and a quantization matrix.
(You probably need to decode only the huffman algo on JPEG so you have already a YcbCr(4:'x':'x')+DCTed+Quantized image that you can "flif")

[psykauze]

Ok I have hacked a DCT-2D algo for improving entropy.
I make a DCT-II transform then I add +1028 and multiply by 8 before converting in unsigned integer (I've heard this is lossless, need to theoretically confirm).

So, with the same file lukas_2d_8_breast_1_t.png, the PNG output size is 2409427 Bytes, the FLIF size 1866616 Bytes.

So, it is much more than before transform.

[DarkZeros]

The key issue with DCT transforms is that the DCT coeficients have to be mapped matching the interlaced pattern. So that the encoder can predict in a logical way the next coeficient based on previous blocks, as well as allowing interlaced encode.

First level -> DC
Second level -> 1st order freq
...

Otherwise #334 is not going to be met even with DCT transform.

Is it possible to know the amount of levels? Is there a maximum amount of levels? It should not be difficult to make them match if they are known at the transform level.

[ziemek99]

FLIF has been superseded by JPEG XL, which has lossless (bit-exact, including all metadata) JPEG transcoding based on extracting original DCT coefficients and encoding them untouched with JPEG XL's better entropy coding. You can read more about JPEG XL on an official website, community website, dig into GitHub repository or join Jon, other JPEG XL devs and the community on a Discord server.