JPEG lossless transformation format and arithmetic coding

[simon]

Hi

I would like ask two questions about JPEG coding

(1) I noticed a "strange" behaviour of JPEG lossless transformations. This procedure is assumed not to recode the JPEG blocks but just to keep the desired ones (cropping) or change their order (rotation) to be lossless. Actually, it is lossless (so it does the job properly but strangly the resultant image seems to be systematically coded in Huffman optimized / non progressive format, whatever the initial format of the image and whatever the format specified in option (huffman optimized or not, progressive or not), which involves some (lossless) recoding of the blocks. Why don't use the initial format, or at least the format specified in the writing option ?

(2) Why not implementing the arithemetic coding for JPG (as provided by the Independent JPEG group) ? in the past there were patents on this but they all have expired so that a few viewers are already able to read/write arithmetic jpg files.

Thanks
Simon

[xnview]

(1) I noticed a "strange" behaviour of JPEG lossless transformations. This procedure is assumed not to recode the JPEG blocks but just to keep the desired ones (cropping) or change their order (rotation) to be lossless. Actually, it is lossless (so it does the job properly but strangly the resultant image seems to be systematically coded in Huffman optimized / non progressive format, whatever the initial format of the image and whatever the format specified in option (huffman optimized or not, progressive or not), which involves some (lossless) recoding of the blocks. Why don't use the initial format, or at least the format specified in the writing option ?

yes right, huffman is optimized

(2) Why not implementing the arithemetic coding for JPG (as provided by the Independent JPEG group) ? in the past there were patents on this but they all have expired so that a few viewers are already able to read/write arithmetic jpg files.

Arithmetic coding is not yet supported...

[rapik]

I find it disturbing, that "lossless" transformation does some optimization to the file. Even if it will not lost any information. Files, I've tested get 10% smaller. Windows Explorer changes one byte when rotating a JPEG image. That's exactly what one would expect from a "lossless" transformation. XnView does a lot with the file and still calls it "lossless".

[Karl02]

1) XnView should use the JPEG options that are selected in the settings.

2) Arithmetic coding is supported in the IJG library since version 7 (2009-06-27). The current version is 9a (2014-01-19).
Overview: http://sylvana.net/jpegcrop/
Changelog: See file change.log here: http://sylvana.net/jpeg-bin/jpg9aexe.zip
List of applications: http://sylvana.net/jpegcrop/losslessapps.html
jpegcrop demo program: http://sylvana.net/jpegcrop/jpegcrop.zip

3) @rapik: Some file changes are usually not a problem if they are lossless. However, you could use the lossless rotate method that only changes the EXIF orientation tag. Unfortunately, this doesn't work currently in XnView. See my suggestions for improvement here: http://newsgroup.xnview.com/viewtopic.p ... 26#p126126

[XnTriq]

I'd like to request an option to prevent XnView from optimizing the Huffman tables during lossless transformations.

• Jpegcrop: Preferences and Options description