Lossless transcoding from JPEG about pik HOT 4 CLOSED

Currently this claim/plan is vaporware -- no re-packing of jpegs is actually supported in pik. We have the technology, it is well tested, too, but we didn't yet figure out the correct way to deploy it -- and the time to do the deployment.

Our re-packer "brunsli" can recompress jpegs by 22 % (1 % worse than Lepton) and uses 2.5x less cpu than Lepton in decoding. I am contemplating if such jpeg recompression would be better to be embedded into the content-encoding layer (like Brotli and Shared Brotli, possibly inside Shared Brotli) or if it should be inside an image codec. Sometimes JPEGs are inside a big file such as a tar or zip file (like Android APKs), and a lossless recompression there would help. Othertimes, they may be base64-encoded inside a web page. Having those two use cases covered would require that a more generic encoding (like the one in Shared Brotli) would improve those use cases.

On the other hand, having the image codec to deal with it might allow more interactive results or lower resource consumption in a browser viewing the images. Particularly, it feels more than a bit silly to reconstruct and repackage a jpeg image from a recompressed image only for the purpose of viewing it a few milliseconds later.

Perhaps the correct solution is to add it in both compression use cases. What do you think?

from pik.

A follow-up: we indeed added YCbCr to support recompressing JPEG coefficients in JPEG XL. Losslessly recompression of entire JPEG bitstreams is also supported.

from pik.

I am mainly interested if the PIK format actually makes it possible to store 8x8 blocks from a JPEG as is, together with the correct colorspace, so that when decoded, this image looks exactly like the result of decoding the source JPEG file. And if not, then which changes to the format are necessary to make it a theoretically valid use case. I've read that PIK uses its own colorspace which is nowhere near YUV, so then it will need to support YUV as well. Perhaps something else is missing, too.
Even if it's never going to be present in the official encoding tool (and that's totally fine), it will be made eventually if the format supports it. Writing another converter/encoder for an existing format is totally possible; but amending an already adopted specification could be practically impossible.

On the other hand, having the image codec to deal with it might allow more interactive results or lower resource consumption in a browser viewing the images. Particularly, it feels more than a bit silly to reconstruct and repackage a jpeg image from a recompressed image only for the purpose of viewing it a few milliseconds later.

Yes it is; and it won't work without javascript, and in a lot of other situations…
I saw that PIK format could be close to being a strict superset of JPEG (if it's going to use 8x8 DCT), so I decided to ask how feasible is it to alter it a little bit to solve this problem as well.

This all, of course, only makes sense if PIK format is going to eventually become as widely supported as JPEG is.

from pik.

Yes, these are important considerations. Pik's own colorspace is pretty far from the traditional YUV colorspaces -- not even a linear transform -- and images that have been heavily quantized into any traditional YUV420 colorspaces will take a 5-15 % density hit when stored in Pik's colorspace at similar quality. I haven't gotten my mind around this yet to think if we should add complexity because of this, but it is definitely an appealing idea. Also, the YUV colorspace is cheaper to decode than Pik's own colorspace.

from pik.