Is a JPG guaranteed to produce the same pixels?

Question

I know there are plenty of benefits to shooting in RAW, but at the moment it seems that JPG works just fine for me. The file sizes are way smaller, and darktable seems to work just fine with them (although interestingly enough it seems like it's actually faster with editing RAW files, but that might just be a hallucination).

As far as I can tell, the way darktable works is by creating a sidecar file containing the edits to make to the original JPG file, so in theory the edits are non-destructive (i.e. it's not recompressing the image to JPG every time).

Given all of that, I was curious - is the same JPG file guaranteed to produce the same pixels when rendered each time? For instance, say I have a JPG file that's saved at 98% quality. If I open that at 100% zoom, is it going to have the same pixels when I open it in darktable as when I open it in Google Chrome? Or when you open it in Photoshop? What about files that are at a higher compression, e.g. 50% quality?

Answer 1

is the same JPG file guaranteed to produce the same pixels when rendered each time?

Yes. It's just a list of numbers that represent color values (in a clever way to make it small). There is no information "produced" in the process of opening a jpeg file that would be different between two applications.

What about files that are at a higher compression, e.g. 50% quality?

Then the numbers in the list will be different. (more zeros) Other than that, there's no difference.

Answer 2

Short Answer

No, decoding is not guaranteed to always be the same. However, the differences are guaranteed to be very, very small.

ISO Specifications

The International Organization for Standardization (ISO) specifications for JPEG has the following specifications for decoders (emphasis mine):

A decoder shall

a) with appropriate accuracy, convert to reconstructed image data any compressed image data with parameters within the range supported by the application, and which comply with the interchange format syntax specified in Annex B for the decoding process(es) embodied by the decoder;

b) accept and properly store any table-specification data which comply with the abbreviated format for table specification data syntax specified in Annex B for the decoding process(es) embodied by the decoder;

c) with appropriate accuracy, convert to reconstructed image data any compressed image data which comply with the abbreviated format for compressed image data syntax specified in Annex B for the decoding process(es) embodied by the decoder, provided that the table-specification data required for decoding the compressed image data has previously been installed into the decoder.

Appropriate accuracy is very strict. Any converter following these specifications has to be compared to a reference algorithm. For a single pixel, each component can only differ by one bit from the reference. Furthermore, the (squared) error over each 8x8 pixel block and over the whole image needs to be very low.

But why would it be different?

Unlike bmp or png, a jpeg doesn't store the pixels themselves but a description of the image. To reconstruct the individual pixels a complex mathematical algorithm is used. After every step, the algorithm stores the result in memory. This is where things can go wrong: a value in memory has a certain precision, the machine precision. Because of this the value has to be rounded. While the specifications ensure that a minimal precision is used for, there is no maximum. The rounding may thus be different for each implementation. It can even be depending on the hardware used, as some processors use more bits of precision than demanded. Some early Pentium processors even did it plain wrong.

Tiny oversimplified example: calculating 5 * 0.12 by repeated addition.

Storing intermediate values using one digit of precision, a computer might do this: 0.12 + 0.12 = 0.24, store intermediate result as 0.2 (rounding down). Then calculate 0.2 + 0.12 = 0.32, store as 0.3 (again, rounding down). Continue this pattern and the result will be 0.5 instead of the expected result of 0.6. If a higher precision was used (two digits, for example), the result would have been different.

Answer 3

No, you can't depend on decoded JPEG images being bit-for-bit identical.

As an example, I tried viewing the image at the top of this page in two different browsers: Chrome 53.0.2785.143 and Internet Explorer 11.0.9600.18426. They look identical, but I put screen captures into an image editor and magnified the difference. You can see that they're not the same.

Here's the original image:

And here's the difference between the two browser renderings, enhanced:

Answer 4

Compression and JPEG internals itself do not influence the reproducibility of already compressed file - it will yield the same pixel output in correctly working programs given that

• the colour space of a photograph matches the colour space of the colour management system
• you are viewing the image at 100% scale i.e. output pixel-to-pixel to the monitor

If, for example, the image file contains AdobeRGB data it may yield different pixel data in sRGB colour systems because different algorithms can be used for conversion from AdobeRGB to sRGB and they may use different precision for calculations. Photoshop and Chrome are very likely to use different algorithms for colour conversion.

Many browsers are not properly set up for colorimetric purposes and may not use the monitor profile at all and may display the image completely differently from Photoshop.

When the image is scaled the difference between resizing algorithms will show up, similarily.

---

That might be overcomplicated but probably something you would like to know.

Answer 5

Most JPEG encoding schemes are not intended to be exactly accurate, they are 'perceptually lossless'. Such a principle will be applied in implementations of both encoder and decoder algorithms.

It is reasonable to expect that in a decoder some optimizations will be implemented which favour performance over accuracy, that colour management may not be implemented at all and that the RGB-Y'CrCb conversion will not be identical between decoders.

JPEG is meant to be 'good enough', differences would be subtle and that is the output one should expect. The same principle would apply irrespective of the compression level applied to the source file.

Answer 6

@Aaganrmu is generally correct. There is no guarantee that a particular JPEG file will be rendered exactly the same way each time it is opened, even by the same program.

In practice, unless a program has been updated, opening the same file with the same program will produce the same results. Many programs also use the same decoding libraries and will produce the same results. It would be too much effort for programmers to intentionally introduce variation in the JPEG algorithm to produce different results every time a file is opened. It is also not what users would expect or want. (This is ignoring color profiles and correction, which is a separate step after decoding.)

The possibility for variation comes from different input potentially resulting in the same output as a result of the transformations, rounding, and quantization that occur as part of the JPEG algorithm. These operations are also the source of JPEG artifacts.

The JPEG decoders knusperli and jpeg2png are designed to reduce JPEG artifacts within constraints allowed by the JPEG algorithm. They produce output that should give the same data that was input if re-quantized with the same settings. (If I understand their operation correctly, they ignore differences that may be introduced by rounding errors.) As a result, they take longer to decode, and their output is different (better?) than that of other decoders.

Here are 100% crops to show the difference between libjpeg (left) and jpeg2png (right):

Answer 7

A pixel is just a color, one average color sampled from that tiny pixel area. Color is how we see detail. We see a black power wire running across an image of a blue sky only because the color is different. Color is the detail.

JPG Quality 50 is just 50, just a number, it is NOT 50%.
JPG 100 is not 100% of anything. 100 is pretty good JPG, but it is still JPG.

JPG artifacts (caused by lower Quality factor) alters the pixel color. The pixel is a different color, and a pixel is only color, so that is a different pixel.

Encoding (creating) JPG is often different in each programs. There are several options, assumed differently in different programs. Quality 80 in one program unlikely matches Quality 80 in another program.

My guess is that decoding (showing) JPG is standard, showing what was encoded.

JPG is better today than it used to be, but there are still JPG artifacts.

One type of JPG artifact is that JPG tries to make the color in 8x8 pixel blocks be all 64 be the same one color if they were already similar color. Low JPG Quality tends to show those 8x8 pixel blocks in areas of similar color (skies, walls, etc).

Another type of JPG artifact is a blurring or an echo of sharp edges offset somewhat from the original edge.

See http://www.scantips.com/basics09b.html for some samples of JPG artifacts.

Low JPG quality can make email and internet smaller and faster, but for our actual photographs, there seems simply no good reason why we would want low JPG Quality. :)