2 ms·
From TFA: > My understanding is that JPEGs don’t have lossless rotation by default, and that is true for sips as well. This is incorrect. JPEG's can be lossl
by pwg 2y ago
From TFA:
> My understanding is that JPEGs don’t have lossless rotation by default, and that is true for sips as well.
This is incorrect. JPEG's can be losslessly rotated in 90 degree increments. See the -rotate option to 'jpegtran' in the libjpeg toolset.
https://man.archlinux.org/man/jpegtran.1.en https://man.archlinux.org/man/jpegtran.1.en
Best guess at what the author saw, the original files were likely originally compressed with an encoder that did not optimize the huffman table, and his newer tools likely do compute an optimal huffman table for compressing the DCT coefficients, that and the fact that the author was doing a lossy recompression would often result in file size reductions.
Also, passing jpeg's through jpegtran's lossless '-optimize' option often shrinks them in size. I.e., the jpeg's direct from most cameras often shrink (sometimes substantially) when optimizing them this way.
- a_e_k 2y agoRight. The lossiness in JPEG comes from quantization of the DCT coefficients. But with the way the DCT works: - You can flip a block horizontally, left-to-right, by negating the DCT coefficients in the odd-numbered columns (zero-indexed). - You can flip a block vertically, top-to-bottom, by negating the DCT coefficients in the odd-numbered rows (zero-indexed). - You can transpose a block by transposing the DCT coefficients. In combination, that's enough to rotate a block in 90 degree increments, and to do so losslessly/reversibly without harming the original quantization (you don't even need to do an IDCT). Then you swap the blocks around to the right order and redo the lossless entropy encoding stages.
- audrey1 2y agoOnly fully losslessly if the image dimensions are a multiple of the MCU (usually 8x8px or 16x16px, I can't recall/depends) any pixels part of a DCT block on the edges are cropped when rendered, so jpegtran will drop those blocks when transforming the image since the alternative is introducing artifacts, since jpeg only supports cropping DCT blocks on the right and bottom edges. I modified jpegtran to work as a dll and wrote a python wrapper for it for a project so I could use it in a small-image compression pipeline (due to several limitations with calling the binary). I needed to save a few hundred million 100x100 jpegs, so I overwrite the height/width to trick the decoder into thinking the edge blocks are full, then I stitch them into ~10x10 mega-images with my jpegtran wrapper, requantize with mozjpeg, then recompress with dropbox lepton, it saves about 20-30% overall, with each step saving about 10% each (the stitching benefits the lepton step). https://i.imgur.com/6PV5WDM.jpeg https://i.imgur.com/6PV5WDM.jpeg
- 01HNNWZ0MV43FF 2y ago8 vs 16 Probably depends on whether chroma subsampling is enabled, off the top of my head
- lifthrasiir 2y agoNot just that, but the Exif orientation can be used to do the lossless rotation nowadays. (It's really the postprocessing step, but that step is now widely implemented.) This approach has no MCU limitation and even is honored by JPEG XL. > Best guess at what the author saw, the original files were likely originally compressed with an encoder that did not optimize the huffman table, and his newer tools likely do compute an optimal huffman table for compressing the DCT coefficients, that and the fact that the author was doing a lossy recompression would often result in file size reductions. `jpegtran -optimize` or any other optimizer (I tried ECT in particular) didn't work much for this particular image, so the Huffman table should have been almost optimal. Probably it has very low quantization factors instead.