Destruction by jpeg

[Saorsa]

This is just for fun.

With other discussions of raw vs. jpeg I thought I would try to work on an image to destruction and see what happens working in jpeg only. This is pretty extreme in the look of the changes but I only used contrast as a variable.

This first image is the original and I noticed that, when I cropped it, it ended up one pixel off being square. So, I cropped into the second image which is identical except for being 1024x1024 instead of 1024x1025.

This one is 1024x1025 with a file size of 559kb


Removing one line of pixels results in 1024x1024 with a file size of 556kb



Then, to see the impact of processing I used the FastStone viewer to increase the contrast as far as possible. That yielded this with a file size of 619kb.



A little harsh, eh? So, let's reverse it by reducing contrast by the same amount. That ended up with this image with a file size of 483kb.



Obviously, it didn't go back to the previous form because data had been converted irreversibly. So, let's go the opposite way and increase contrast again. This one creates a 641kb file but some of the data is gone forever.



Working in raw, I could quickly have eliminated all of these effects.

[DanK]

I tried something similar with white balance. This is why I virtually never shoot in jpeg format. People reply that it often doesn't create problems in editing. I suppose that is true, but I can't see taking the risk.

[Shadowman]

Brian,

Did you close and reopen and of these in between transformations or just work on an open file?

[Saorsa]

Brian,

Did you close and reopen and of these in between transformations or just work on an open file?

I closed and renamed them each time I made a change. Each of the images was been retitled using 'save as' to reflect the action taken and the new version opened for the next step. I actually continued the process a few more times but the changes, while noticeable, were less striking.

[DanK]

Depending on the editor, you would have to save to see if a change is reversible. information is lost only when a jpeg file is created. For example, if you load a jpeg into LR, all of the edits from that point on should be reversible, until such time as you export a new jpeg. However, that is exactly the point. When you shoot a jpeg, you are saving a jpeg, hence creating edits some of which are not reversible.

[IzzieK]

Along the question of John above, does that mean you worked on the original jpeg shot each time you changed your pp? I must have misunderstood what I read from your response?

[Saorsa]

No, the intent was to show that editting in jpeg results in loss of data. As pointed out, had I not saved the images I would have been able to step backward while in the editting program. BUT, once the jpeg was saved that data was lost. I used the 'save as' function to create individual files to post here.

Had I just closed the edit session with a save, the original file would have been irreversibly changed. That is one reason you need to be careful dealing in jpeg only files.

In my own workflow I shoot Raw+JPEG fine for quick posts or emails I work with the jpeg. If it's a shot I want to work with I work with the Raw file and save a seperately identified jpeg from the raw processing. As a result, I end up with three versions of a worthwhile image. DSC_1234.jpg, DSC_1234.nef and DSC_1234a.jpg. This way I can compare the results of my processing between the jpegs.

All jpeg processing after that is done from the 'a' image.

If, for example, a salon wants 1920x1200 or 1024x768 I crop the 'a' image and 'save as' DSC_1234c192 or DSC_1234c107. These are common aspect ratios for salons so I am likely to keep them rather than eliminate them after use. If it is one I intend to enter in exhibits I also give it a title at this time since they must be consistent across salons.

If I were to resize for email I would save it as DSC_1234m

[MrB]

The trouble with this sort of "just for fun" editing, is that some people will take the results seriously, and as evidence for not shooting and editing JPEGs. The point, obviously, is that editing methods used on any image from the camera should be intended to enhance the product, not to be deliberately destructive to it.



Someone shooting JPEGs would try not to blow highlights, because that data is then lost irrevocably but, in choosing the camera settings, he/she attempts to get an image from the camera that is close to the desired product, and then only a copy of the file will be edited.

The editing required is then usually not extreme, although full-size, high-quality JPEGs can withstand quite a lot of sensible editing, before the image quality becomes noticeably affected for normal viewing on screen or print, e.g. at the accepted photo sizes used in clubs around the UK.

For preserving at full file size after all editing has been done, the new JPEG would then be saved at the highest quality (lowest compression) setting. If anything goes wrong, the original JPEG is still available for copying and re-editing.

Cheers.
Philip

[dem]

As far as a car analogy can go, it is a bit like driving a family car into the river to show that it is not good for off road driving.

A comment on "reversing contrast by the same amount":

Start with a 100, increase it by 50%, get 150. Then take 150 and decrease it by the same amount of 50%, get 75. Oops, not a 100, slightly overshot. Could this be what made the image so washed out?

[dje]

No, the intent was to show that editting in jpeg results in loss of data. As pointed out, had I not saved the images I would have been able to step backward while in the editting program. BUT, once the jpeg was saved that data was lost. I used the 'save as' function to create individual files to post here.

Brian I think your tests are showing the results of destructive editing rather than the effects of jpeg compression. I converted your original jpeg file to a tiff and repeated your tests in Faststone, and got similar results to yours. In this situation, there was no jpeg compression involved in the intermediate steps of the processing.

Dave

[Manfred M]

I tried something similar with white balance. This is why I virtually never shoot in jpeg format. People reply that it often doesn't create problems in editing. I suppose that is true, but I can't see taking the risk.

This is also true for a 16-bit TIFF or any other image format. The white balance gets "baked-in" as soon as you are not working with RAW data, so this is not specifically a jpeg issue.

That being said, I take care to get my white balance right in camera, so rarely need to worry about it in post.

[Brev00]

If I were to process jpeg's, I would make a copy first and save the original. Which is what I often do after raw conversion. I will save the raw result and then play. I can always go back to the raw original if the raw result is giving me problems. The same principle would hold true for jpegs except one cannot undo the jpeg original. This demonstration just reinforces the notion that I should always go back to the initial stage if I want to undo or override my processing.

[Saorsa]

I wasn't trying to do anything with compression. You could run the same experiment only using alternating high and low compression with saves in between and, some boring evening, I might. I would think that if your editor is not set for minimal compression those changes might also be destructive if you save to the original file name.

The point I was trying to validate was the information loss in editing and saving. Compression was not a factor in what I was doing and I would expect that, in this case, TIFF would act exactly like the jpeg I was using. If you increase contrast or reduce it and then save that version it will be different.

It really doesn't matter whether you use raw, jpeg, or tiff, your workflow should include a way to get back to the baseline data because editing changes are cumulative. I used extreme examples of contrast change as a demonstration.

With Capture NX, I can take an editted raw file and return to the baseline. My friends who use photoshop always work on a copy.

[dje]

Brian I must have mis-understood your intent. I thought you were concerned about the effects of multiple jpeg saves (and the corresponding application of compression associated with each). It seems you were just demonstrating what can happen with destructive editing

By the way, you can edit a jpeg non-destructively in Lightroom/ACR.

Dave

PS Just noticed Dan mentioned non-destructive jpeg editing in LR in post 5.

[Manfred M]

Okay - time to debunk some myths about jpegs as well as to identify the limitations and of course cover off destructive versus parametric editors.

1. Cameras that shoot 14-bit raw have 16,384 colours or perhaps more accurately tonal values for each colour channel. 12-bit 4096 distinct tones per channel and 8-bit has a mere 256 tonal values per channel.

Do a severe edit on a 12-bit or 14-bit image there are many "shades" between colours and the risk of artifacts like banding will be quite limited. Take an 8-bit jpeg, bmp, tiff, png, etc. file and the risk of having banding will be a lot higher due to the limited range of tonal values that are available. THIS IS NOT JUST A JPEG ISSUE!

Just to complicate issues a bit more, the colour space that you are using will increase the likelihood of banding even more. A wider gamut color space means the difference between two shades represented by two values one digit apart actually represent shades that are further apart. A small colour space like CMYK will have relatively little shade difference between two values, sRGB will have a larger offset, AdobeRGB and even wider one and a wide gamut colour space, like ProPhoto will have an even wider offset. I've seen recommendations that ProPhoto should never be used in 8-bit mode because of the potential for banding issues.

2. The largest single improvement in storage space for a jpeg comes from throwing away half the bits in the colour values. Even though 14-bit is the largest amount of information a raw file delivers, computers work in 8-bit, 16-bit, 32-bit, 64-bit character lengths. This means a 14-bit piece of data is stored as a 16-bit value with two "0" (zero) values in the leading bits.

The other part of what a jpeg has is "lossy compression'. This means a compressed jpeg file will not produce a file that is IDENTICAL to the one you started out with. If you use a high quality setting, it is unlikely that you will be able to tell the difference between a compressed jpeg and the original file. Decrease the quality level and the system will throw away data more agressively, any you will not be able to get back to the quality level of the previous image.

However, the BIG MISUNDERSTANDING is that you will lose quality every time you save a file when you do not change the quality setting. This is totally incorrect; there will be NO quality degradation whatsoever. The compression algorithm has already optimized the way the data is compressed and re-running the compressor over and over and over again is going to give you exactly the same result. Digital computers are like that, give them the same input, they give you the same output, as as we are dealing with integer values, rounding errors never creep in. If you don't believe, go ahead and try it (I sure have, and was able to confirm that this is correct).

This also means that edits to jpeg files will generally result in little or no degradation, even if you are working with secondary or tertiary files.

Now let's get on to parametric and pixel based editors, as this appears to be causing issues as well.

There are two types of editors in use; parametric editors (Lightroom and Adobe Camera Raw) and pixel based editors (Photoshop and Photoshop Elements) are probably the best known, but by no means the only ones.

The way parametric editors work is by recording parameters that are run through a particular mathematical equation that alters the way each individual pixel is displayed. The original pixel data is NEVER touched and to undo a edit, the original settings have to be erased or undone. The only real problem with this type of editor is that there has to be a mathematical equation developed, as well as the key parameters for this to work. This ends up resulting is a editor with very limited functionality when compared to a pixel based editor. The other advantage is that the edit data files are quite small.

Pixel based editors are extremely powerful as they can manipulate any specific pixel in the image. Their downside (as shown in some of the examples in this thread) is that it is more or less a one-way path. Once a pixel has changed, there is no way of getting it back to its former state (other than the limited "undo" functionality that many editors have built in). Even this undo is limited. Save the image and close the file, the undo data is gone.

Pixel based editors have introduced a level of flexibility and the ability to undo edits (a.k.a. non-destructive editing) by using adjustment layers, layer masks, clipping masks and smart objects. While these tools are quite powerful and let you undo edits and fix issues much more flexibly and quickly that a parametric editor can, the file sizes can become extremely large.

Hopefully this clarifies some of the issues brought up on this thread...

[rpcrowe]

So much energy goes into the question "WHY SHOOT RAW?"

IMO, the proper question might be "WHY NOT SHOOT RAW?"

I cannot see any reason not to shoot RAW The problem of file size has been mitigated by the reduction in price of camera and computer memory! It really doesn't take me any longer in my workflow to have my original files in RAW than to shoot in JPEG. It is a lot easier for me to work with a RAW file, opening it and doing some initial edits in ACR than to shoot in JPEG and work around things like correcting white balance.

That might not be the case for other photographers but it is certainly true for me!

Additionally, I like the ability to correct distortions in ACR...



Maybe, if I were needing a file to transmit immediately to a sports editor, I might shoor JPEG. But, since I have no need to do that, I continue to shoot RAW...

[Manfred M]

So much energy goes into the question "WHY SHOOT RAW?"

IMO, the proper question might be "WHY NOT SHOOT RAW?"

Simple analogy, Richard.

I have two cars sitting in the driveway; a Hyundai Elantra and a Volvo XC 60.

The Volvo is a much nicer car, it's more comfortable, has a great safety rating and it just a joy to drive.

The Elantra cannot compare to the Volvo, other than it is cheaper to run and fix.

So, if I just want to run around town or get groceries, the Elantra is really the way to go, because it is good enough. Give me a long road trip or winter driving (the Volvo has All-Wheel Drive - AWD), and I will pick the Volvo. The number of km / miles clearly show that the Elantra gets more use, even though it is the lesser vehicle.

The same argument goes for jpeg versus raw. Often jpeg is good enough, but there are times I will use raw, just because of the extra features. I've pretty well always been a jpeg + raw shooter, simply because it works for me.

I spent most of my working life figuring out the most effective way to get things done; so I continue to apply that to my personal life and hobbies. A good enough solution will often be better than the "best" solution. I know a lot of users sneer at jpeg shooters, and frankly I don't care, so long as I get the "job done" in the most effective manner.

For me at least, jpeg is often the most effective route. I am certainly not saying that raw does not offer a more robust solution, I'm just saying that in most cases it is overkill, at least for me. Perhaps I am saying I'm a good enough shooter to get away with jpegs most of the time...

[DanK]

Manfred,

thanks for the detailed explanation.

This is also true for a 16-bit TIFF or any other image format. The white balance gets "baked-in" as soon as you are not working with RAW data, so this is not specifically a jpeg issue.

Good point. I do a lot of image stacking, and my software will not accept raw files. I use 16-bit TIFFs for this. The only adjustment I always make to the base raw files before exporting them as TIFFs for stacking is white balance. That way, the WB is correct in the composite, and I don't have any other edits baked in (other than the default Adobe rendering) that I might want to undo later.

Dan

[george013]

Manfred,

2. The largest single improvement in storage space for a jpeg comes from throwing away half the bits in the colour values. Even though 14-bit is the largest amount of information a raw file delivers, computers work in 8-bit, 16-bit, 32-bit, 64-bit character lengths. This means a 14-bit piece of data is stored as a 16-bit value with two "0" (zero) values in the leading bits.

I don't think you mean this, but there are no bits thrown away. I read this as being truncated. The values are recalculated. The max.value of the 12 bit is 4096 and of 8 bit 256. For neutral middle gray the values would be (2048,2048,2048) for 12 bits and (128,128,128) for 8 bits.

2. The largest single improvement in storage space for a jpeg comes from throwing away half the bits in the colour values. Even though 14-bit is the largest amount of information a raw file delivers, computers work in 8-bit, 16-bit, 32-bit, 64-bit character lengths. This means a 14-bit piece of data is stored as a 16-bit value with two "0" (zero) values in the leading bits.

For this one the same as before.
There is internal and external storage. On disk a RAW-file is not saved in words, the 16-bit. There is a real difference between filesizes of a 12-bit RAW or 14-bit RAW. That wouldn't be as they were saved in 16-bits words. And with a hexa-editor you will not see the filling zero's.

However, the BIG MISUNDERSTANDING is that you will lose quality every time you save a file when you do not change the quality setting. This is totally incorrect; there will be NO quality degradation whatsoever. The compression algorithm has already optimized the way the data is compressed and re-running the compressor over and over and over again is going to give you exactly the same result. Digital computers are like that, give them the same input, they give you the same output, as as we are dealing with integer values, rounding errors never creep in. If you don't believe, go ahead and try it (I sure have, and was able to confirm that this is correct).

There is some but minor. I did this not so long ago but didn''t save the results but still have the pictures.
It's not as how I would do it again.
As basis a embedded JPG in an edited RAW-file, so high quality. I saved this twice as quality 100 and quality 50. Opened the saved file and saved it again giving a sequense number. Did this 5 times.
100 basic, filesize 8.001.744, amount of colours 256646.
100-5, filesize 8.021.172, amount of colours 250284
50 basic, filesize 1.328.184, amount of colours 270170
50-5, filesize 1.328.062, amount of colours 269531.
As you can see the filisize is growing with the quality 100. But with all off them the amount of colors is decreasing. I did do this with Iview, I should do this at least with a start jpg from Capture.
The JPG-function is saving a rasterimage in a compressed way. When I re-open the JPG-file again, my rasterimage will be different.

With the test I did,I couldn't see any difference between the pictures.


@Mike,

Good point. I do a lot of image stacking, and my software will not accept raw files. I use 16-bit TIFFs for this. The only adjustment I always make to the base raw files before exporting them as TIFFs for stacking is white balance. That way, the WB is correct in the composite, and I don't have any other edits baked in (other than the default Adobe rendering) that I might want to undo later.

Just be glad that your software doesn't accept raw files. You do your stacking on raster files. And if your software should do the conversion, you wouldn't be sure about the result.

George

[dje]

According to Eric Chan of Adobe in this thread here, conversion from 12 or 14 bit to 16 bit in ACR/LR is done by scaling. ie multiplying the pixel values by a simple multiplier. eg if the 14 bit white level was set at a raw data level of say 16,000, then this is mapped to the maximum value possible with 16 bits, 65,534. So in this case, the scaling factor would be 65535/16000.

I believe dcRAW works the same, can't say for other raw converters.

Dave