Cant view lossless jpg?

[XingXingXing]

I cropped a normal jpg using jpgcrop (http://jpegclub.org/) the original picture opened fine, but the result image just throws out an error each time i attempt to open it.

But the MP version of XnView can open it, i use the normal version. I searched to see if XnView by default cant open lossless images, but it seemed it was a feature of it and its just me that has the issue
This is the cropped result image that refuses to open


What am i doing wrong?

[XnTriq]

Arithmetic coding are currently not supported by XnView Classic.

The Entropy Coding Method is the final *lossless* part of the JPEG compression scheme. It does *not* affect the image quality. You can transcode between different methods without image degradation.

Huffman default uses predefined Huffman tables for the final entropy coding stage as given in the JPEG standard.

Huffman optimized corresponds to the cjpeg and jpegtran -optimize switch.
Here is what the IJG v9 usage.txt file says about this switch:

• Perform optimization of entropy encoding parameters. Without this, default encoding parameters are used. -optimize usually makes the JPEG file a little smaller, but cjpeg runs somewhat slower and needs much more memory. Image quality and speed of decompression are unaffected by -optimize.
  
  The -optimize option to cjpeg is worth using when you are making a “final” version for posting or archiving. It's also a win when you are using low quality settings to make very small JPEG files; the percentage improvement is often a lot more than it is on larger files. (At present, -optimize mode is always selected when generating progressive JPEG files.)

In the jpegtran and Jpegcrop context, using this option has less downsides than in cjpeg. The higher memory usage is inherent to jpegtran operation anyway, and the additional runtime is very short.
So if you prefer smaller output file sizes with minor operation penalty in Huffman mode, just turn this switch on.

Arithmetic coding provides the best compression results, i.e. smallest file sizes, and is therefore the preset default setting. CAUTION: arithmetic coded JPEG is not yet widely implemented, so many decoders will be unable to view an arithmetic coded JPEG file at all.

[XingXingXing]

Im not really proficient in image manipulation terms, but does that mean XnView classic cant view lossless images then?

The picture doesnt display in firefox and chrome too

[XnTriq]

XnView Classic (as well as the web browsers you mentioned) are able to dispay losslessly edited JPEGs if they haven't been saved using arithmetic coding.
In Jpegcrop, you have to change the setting for Entropy Coding Method (in File » Preferences...) from Arithmetic to Huffman default or Huffman optimized to prevent this problem from occurring.

Follow these steps to make images like the sample you uploaded (324et4e5tgh.jpg) compatible with XnView Classic:

1. Select the JPEG file(s) in XnViewMP's browser.
2. Go to Tools » Metadata » Clean….
3. Deactivate all checkboxes except for Optimize Huffman table.
4. Confirm with OK.

[XingXingXing]

XnView Classic (as well as the web browsers you mentioned) are able to dispay losslessly edited JPEGs if they haven't been saved using arithmetic coding.
In Jpegcrop, you have to change the setting for Entropy Coding Method (in File » Preferences...) from Arithmetic to Huffman default or Huffman optimized to prevent this problem from occurring.

Follow these steps to make images like the sample you uploaded (324et4e5tgh.jpg) compatible with XnView Classic:

1. Select the JPEG file(s) in XnViewMP's browser.
2. Go to Tools » Metadata » Clean….
3. Deactivate all checkboxes except for Optimize Huffman table.
4. Confirm with OK.

Sorry for viewing this late! The notification went to my spam folder

Thank you! That solved the problem!

Happy Holidays too!

[XingXingXing]

Btw, does this mean Arthmetic is a recent version of lossless JPEGS? Like something too recent for most things to view it, or is it something proprietary and unsupported?

[XnTriq]

Happy Holidays & Welcome to the forum, XingXingXing (-:

Btw, does this mean Arthmetic is a recent version of lossless JPEGS? Like something too recent for most things to view it, or is it something proprietary and unsupported?

JPEG compression in and of itself is lossy (even at quality factor 100). Hence, resaving a JPEG image will introduce so-called generation loss. There are exceptions, though: With the right software, certain transformations (like cropping and rotating) are possible without further quality degradation (lossless transcoding vs. lossy re-encoding).

While there are various proprietary file formats incorporating JPEG compression, arithmetic coding is not a proprietary standard.

2: JPEG and Arithmetic/Huffman Coding.

Here's where everything went awry. JPEG came out around 1990 as a standard for lossy images. As a quick background, there are 3 steps to JPEG compression.

1. The data is transformed using the Discrete Cosine Transform or (DCT). This step is lossless.
2. The data is chopped, removing the least significant bits. This step is lossy.
3. The resulting data is compressed using either Huffman coding or Arithmetic coding. This step is lossless.

So whether you use Huffman or Arithmetic coding has no effect on the actual resulting image. They should be pixel-accurate (unless I'm missing something). All that changes is the size. Arithmetic coding is basically “just better”. It gets better compression ratios. It's not a lot better, but 6% improvement with no downside is pretty good.

But there is a downside, and that is patents. You can find a quick list at wikipedia: http://en.wikipedia.org/wiki/Arithmetic ... US_patents. As a result of having these patents, the guys who made the format were scared to use Arithmetic encoding in JPEG. So while it's part of the official format, most image readers and writers only support Huffman coding.

3: Aftermath.

On top of that, those patents have now expired, but due to inertia we can't really go back. Photoshop CS 5.1 doesn't open them. Chrome/Firefox/IE don't open them. Due to the difficulty of changing formats, we seem to be stuck with Huffman coding for the near future.

Support was introduced in version 7 of IJG's official code for reading and writing JPEG image files (libjpeg). JPEGclub.org “develops new JPEG features and maintains the Independent JPEG Group's (IJG) software”.
XnView's as well as XnViewMP's “JPEG functions are based in part on the work of the Independent JPEG group”, but arithmetic coding has only been implemented in MP so far. (There's only one developer responsible for all things Xn.)

8<––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––>8

• Wikipedia
  • Independent JPEG Group
  • libjpeg
  • JPEG
    • Lossless editing
    • Lossless further compression
    • Entropy coding
  • Lossless JPEG
    • JPEG-LS
    • JPEG 2000
  • Lossless compression
    • Graphics
  • Lossy compression
  • Compression artifact
  • Generation loss
  • Arithmetic coding
    • US patents

• About.com
  • Graphics Software
    • Working with Digital Photos and Scanned Images
      • Q&A: Does Rotating Images Degrade Image Quality?
    • Graphics File Formats and Types of Computer Graphics
      • JPEG and JPEG 2000
        • JPEG Myths and Facts: Page #1 + Page #2
          “The JPEG image format has quickly become the most widely used digital image format. It's also the most misunderstood. Here's a collection of some common misconceptions and facts about JPEG images.”
        • The Pitfalls of JPEG Compression
          “JPEG compression makes your pictures nice and small so you can fit more on your storage card, but too much compression can damage them beyond repair. Your camera probably offers options to let you choose the best compromise between image quality and file size.”
  • Focus on Linux
    • Linux / Unix Command Library (Man Pages)
      • jpegtran
        “jpegtran performs various useful transformations of JPEG files. It can translate the coded representation from one variant of JPEG to another, for example from baseline JPEG to progressive JPEG or vice versa. It can also perform some rearrangements of the image data, for example turning an image from landscape to portrait format by rotation.
        jpegtran works by rearranging the compressed data (DCT coefficients), without ever fully decoding the image. Therefore, its transformations are lossless: there is no image degradation at all, which would not be true if you used djpeg followed by cjpeg to accomplish the same conversion. But by the same token, jpegtran cannot perform lossy operations such as changing the image quality.”
• Steve's Digicams: Tech Corner
  • October 2004: JPEG Images – Counting your Losses
  • August 2005: Whatever Happened to JPEG2000?
• ImpulseAdventure: Digital Photography Articles
  • JPEG Lossless Rotation, Lossless Crop
    “With a photographer's desire to preserve the digital negatives as much as possible, there is a strong need to be able to rotate photos without reducing the quality in the process. The rotation might be done for a variety of reasons, including: correctly orienting a vertical portrait shot when the camera doesn't have a built-in orientation sensor, rotation for stylistic reasons, true rotation to match the EXIF orientation flag, etc. Similarly, one may want to crop a photo without degrading the quality of the uncropped portions of the image.
    As the ‘loss’ (more properly: additive compression error) is completely dictated by the details of how JPEG compression works, it is important to understand some of the basic concepts.”
    • How to test?
      “With all of the concern about lossless rotation, it's worth knowing whether or not your particular software is capable of rotation without incurring additional compression error. It is virtually impossible to do this visually, and so a more object means must be used to perform this check. Fortunately, it is very easy to do, and I describe two of these methods below.”
  • JPEG Lossless Rotation or Flip with Partial MCU
    “As described on the JPEG Lossless Rotation page, it is not possible to rotate some images losslessly. Images that have dimensions that are not a multiple of the MCU dimension (typically 8x8 pixels) will not be rotated or flipped losslessly. This page explains the reasons why.”

It is extremely important that the reader understand that compression quality cannot truly be represented by a single value. JPEG compression quality is actually defined by a pair of quantization tables (each with an array of 64 values). Trying to make a comparison between a pair of matrices is not at all straightforward (or always possible).

So, then why are “quality” numbers listed for each camera/software source? Many programs encode their JPEG images using quantization tables that are generated by scaling the coefficients in a “standard” table that is provided in the ITU-T specification.

The IJG group has proposed a method of scaling these coefficients according to a “quality factor” scale. This is NOT a percentage! It is merely a number from 1-100 representing the scaling factor used in generating the table. A quality factor of 100 does not mean Lossless compression! Instead, it generally represents the quality factor that will generate the highest quality compressed image with the provided scaling algorithm.

That said, many software programs and some digicams are indeed using scaled versions of this standard table. If we know that a given program has used the IJG scaling method, then we can indeed make a comparison, because all numbers in the matrices will move according to the algorithm in a similar manner.

So, what about other digicams / software editors that didn't use the IJG scaling method? People always love to make comparisons, and comparing multiple 64-element matrices is not intuitive to the average person. Therefore, as an incredibly rough approximation, a calculation has been made for each source to derive the closest / approximate IJG quality factor for a given table. If the quantization tables follow the standard trend of limited compression in the low-frequency components rising to moderate compression in the high-frequency components, then the approximate quality factor may indeed give one an idea as to how the overall quality may appear.

• Dr. Dobb's Journal: Inside Intel's JPEG Library by Mark Nelson

JPEGs whose dimensions are not divisible by 16 are cropped by XnView during “lossless” operations like rotating or flipping.

In general, all of the lossless transformation commands rely on the fact that the widths, heights as well as X & Y offsets are all multiples of the MCU size. In other words, all corners of the rectangles shown in the diagram above will line up on the boundaries of the JPEG MCU (Minimum Coded Unit) blocks.

In general, these blocks are 8x8 pixels, but can be 16x8, 16x16 or 8x16, depending on the chroma subsampling being used.

To be on the safe side, it is recommended that you try to select dimensions and offsets that are multiples of 16 pixels. In other words, W, H, X and Y should all be multiples of 16.

One cannot truly perform a lossless rotation on a JPEG whose dimensions are not an integer multiple of the MCU size. In other words, a photo that is 501 x 483 pixels cannot be properly rotated or flipped losslessly!
Please read my article that explains partial MCU and lossless rotate / lossless flip operations.

As described on the JPEG Lossless Rotation page, it is not possible to rotate some images losslessly. Images that have dimensions that are not a multiple of the MCU dimension (typically 8x8 pixels) will not be rotated or flipped losslessly. This page explains the reasons why.

[...]

Many programs will crop the partial MCUs instead of cropping pixels & shifting or extending, as this avoids the reduction of image quality.

• ImpulseAdventure: JPEG Lossless Rotation Test

[/list]