native jpg decoding

[matthiaskrgr]

It might be nice to have jpg reading support.
Currently flif does not accept jpgs.

While converting jpg to flif is obviously not something desirable since jpg already implies loss of information in most cases, having to convert jpg to png and then png to flif (if there are no losseless originals of the jpgs available) is not very comfortable either...

[jonsneyers]

Could be nice in combination with storing the actual pixel data in YCbCr, like JPEG, instead of the reversible YCoCg we're using by default.
We could use this: https://cdn.rawgit.com/libjpeg-turbo/libjpeg-turbo/1.4.x/doc/html/group___turbo_j_p_e_g.html#ga0828a38ae29631ac28b6857cefb0eebf

[psykauze]

I've made some benchmarks with jpeg files as inputs just for fun.

As expected, conversion from lossy to lossless format is non-efficient here a screenshot of the results. (Sorted by "FLIF non-interlaced"/"JPEGtran progressive" ratio)

[jonsneyers]

Interesting. What quality are those JPEG originals? I would expect the ratio to be different depending on the JPEG quality. Obviously encoding compression artifacts has a cost, while it is "free" for the format that produces the artifacts :).

Also, it would be interesting to see a comparison between partial FLIF files and JPEG files w.r.t. some perceptual metrics like SSIM. I.e. take a lossless original, compress it with FLIF, compress it with JPEG at various quality settings, decode truncated versions of the FLIF file, and plot the results (bits per pixel on the x-axis, SSIM on the y-axis or something like that).

[psykauze]

I'm using various images (300) I've got from a homemade sharing files website. There's drawings, pictures, screenshots, fractals, memes, scans, etc...

I'll sort images by bit-per-pixel.

I also attach the log file:
jpeg2flif.txt

[jonsneyers]

uncmpJPG can be used to extract the raw DCT coefficients (I think those are 12 bit signed ints or something like that) from a JPEG file: https://github.com/packjpg/JPEG-Developers-Package/tree/master/uncmpJPG

We could use FLIF to store the raw DCT coefficients. Maybe store it internally as an animation with 64 frames (one for each DCT coefficient), or something like that.