This content has been marked as final. Show 15 replies
What are your output settings in ACR (click on the blue line at the bottom of the ACR window).
You are trying to bake images twice: once in camera, then in ACR...
High quality JPEGs? what is their weight and their pixel dimensions?
Why do you need to color correct them? it should be the work of the Photographer, on his raw files.
The output settings are Adobe RGB (1998); 8Bit; 3504 by 2336 (8.2MP); 240ppi.
PECourtejoie, I thought that ACR was nondestructive and after I save them as a different file type, I thought that the compression that happens with a jpeg would stop. The jpegs are 3504 x 2336, 2.51MB. I have to color correct the photos because the photographer did not and sort of left us hanging, it's along story, but that is where it stands.
> I thought that ACR was nondestructive
It is. Absolutely.
>and after I save them as a different file type
Then, at that point, you are not dealing with raw files or with ACR at all.
> I thought that the compression that happens with a jpeg would stop
WRONG! Every simple time you save or re-save a JPEG, lossy compression is applied, destructively. No exceptions. It has nothing to do with ACR.
A couple of points;
1 Saving a JPG as a TIF or PSD should not result in further loss.
2 I take it that these are Canon images. 2.51MB is not a very high quality level for a full sized 8MP Canon JPG. ACR maybe taking the files beyond their limits especially if you are using the Fill Light or Clarity tool excessively.
>1 Saving a JPG as a TIF or PSD should not result in further loss.
That is correct, because at that point you are NOT saving a JPEG. Rather, you are saving a copy of the image in memory as a TIFF or PSD.
Therefore, the statement in #4 is correct: Every simple time you save or re-save a JPEG, lossy compression is applied, destructively. No exceptions.
> Every simple time you save or re-save a JPEG, lossy compression is applied, destructively. No exceptions
There is an exception: when saving with the same encoding parameters.
The encoding is governed by a set of usually 128 parameters (plus some more); these are stored in the JPEG file. When the same set of parameters is used in repeated encoding (saving), there is no loss incurred.
Unfortunately, none of the JPEG processing programs I know offer the choice of "compress using the same set of parameters as in input". However, if you save a file repeatedly by the same program using the same "compression quality", then the same set of parameters will be used.
This fact is misinterpreted by some, who claim that repeated saving does not cause loss and prove that claim with such repeated saving. Right, it does not cause new loss, *under those particular cirumstances*.
On the other hand, I saw the proof of desctructive repeated saving using the same quality setting as well; I can't explain it.
Over the years, we have had at least two discussions over this issue in the Photoshop Macintosh forum. The last one turned very ugly. But in BOTH, tests ultimately confirmed that there is in fact NO EXCEPTION.
Doing a SAVE AS, over and over again, in Photoshop (any version, the most recent time CS3 was used), did cause artifacts in the image. I don't know if the thread is still intact, but here are excerpts from relevant posts:
Freeagent - 3:16am Jun 14, 08 PST (#33 of 148)
Hate to jump in on this beautiful little argument, but I just did what Ramón said: Screenshot > save as jpeg > make a copy > "save as" on top of itself 20 times, closed and reopened for each pass.
However, in Difference blend mode, I *did* get some readings of up to 4 in the info palette - don't know if this is significant (I suspect that's random and you'd get the same with tif or psd. I'll check that also).
Freeagent - 6:00am Jun 14, 08 PST (#34 of 148)
Hmmm...interesting update: I repeated the same procedure with .psd. This time, the info palette showed dead zeros all across in difference blend mode. Completely velvet black.
Then I redid the jpeg run - starting from a fresh original - but saving at a lower quality, 5 instead of 12. But still no change made to the file, just open and "save as".
And what do you know: the familiar jpeg artifacts. 4 passes was all it took. So the readings I mentioned above weren't random at all...
Your post implies that, somehow, the "encoding parameters" would be saved together with the JPEG. Since you're quite an expert at looking inside the guts of files, can you tell us where and how these "encoding parameters" are recorded in the file?
Otherwise, it would be impossible for the application to know what the "encoding parameters" were when the file was saved last, so it couldn't "decide" whether to re-compress or not. I had never heard of such a thing, but then that doesn't mean squat, as I am the farthest thing from a JPEG expert, and I avoid them like the plague.
[EDITED "and" for as in the very last sentence.]
now I am quite baffled. For years ago I conducted respective tests and demonstrated, that repeated saving with the same "quality" does not introduce image deterrioration; others did the same tests and came to the same result.
Now, to be sure, I did it again, and the result contradicts my earlier findings. Although the deterrioration is after five consecutive savings practically irrecognizabe without hugely amplifying it, it is there, and that is an issue of principle.
While it is possible, that I and others made some error in those tests, the question is (for me) what causes the difference.
I verified, that the encoding parameters are unchanged. Thus the difference must come from the calculation required to transform between the original pixel values and the encoded values by
a. the conversion between RGB and YCbCr,
b. the discrete cosine transform (a variation of Furier transform).
However, any differences resulting from the calculation (iteration, rounding) should be eliminated by the subsequent lossy step, the "quantization" (which is an euphemism for "throwing away most of the data"). Even if there is a difference between the first and second savings, there should not be any between the fourth and fifth savings - but there is.
One explanation could be, that the encoding and decoding functions work with different precision, though this sounds very outlandish.
Re the encoding parameters: they *have to be* stored in the JPEG file, otherwise the data could not be decoded, except by that program, which knows the parameters. However, JPEG is not designed for human consumption but for computers (this fact makes testing a program, which reads or writes JPEG data a serious PITA). The metadata can be analyzed only by a hex editor, and one has to know the structure of that data.
Re knowing, if the file has to be compressed or not: JPEG is *always* encoded. There are different variants of the encoding method, but there is no "unencoded" version.
>Now, to be sure, I did it again, and the result contradicts my earlier findings. Although the deterrioration is after five consecutive savings practically irrecognizabe without hugely amplifying it, it is there, and that is an issue of principle.
Thanks for checking, G.
Not having a good understanding of all aspects of JPEG compression, I'm baffled at how a copy of Photoshop on machine B could possibly know the EXACT coding parameters used earlier to compress and save a given JPEG in machine A.
>Re knowing, if the file has to be compressed or not: JPEG is *always* encoded. There are different variants of the encoding method, but there is no "unencoded" version.
That I fully understand. My question was about what I wrote above in this post: how a copy of Photoshop on machine B could possibly know the EXACT coding parameters used earlier to compress and save a given JPEG in machine A.
Incidentally, I've been in discussions over this same issue for over six years. Running the tests each time showed me the results you have obtained and confirmed here.
As you brilliantly put it:
Although the deterioration is after five consecutive savings practically irrecognizabe without hugely amplifying it, it is there, and that is an issue of principle.
Photoshop's JPEG encoding has changed over the years (versions). I'm pretty sure at one point Photoshop did have an encoding that would only re-compress an image tile that had changed from the original opened image. Thus, if you opened an image and merely re-saved with no changes, it would not re-compress the image at all. Only those portions of an image that WERE different than the open state would be compressed. But I think that was then and now is now. Part of the reasoning for the compression of only newly changed tiles was machine speed and compression optimizations...but machines now are so fast that the current JPEG compression schemes take almost no machine time at all.
Photoshop always had to re-encode "foreign" encodings such as what you might find coming out of a camera...and while the data in the JPEG DOES give enough data for an app to decode the JPEG, it doesn't necessarily have the data needed to re-encode in the EXACT same scheme.
Needless to say, with the exception of JPEG 2000 lossless encoding, resaving a JPEG should always be thought of as lossey...
Thank you for that added insight, Jeff. That change must have happened before or as I started to use Photoshop.
Needless to say, with the exception of JPEG 2000 lossless encoding, resaving a JPEG should always be thought of as lossey.
> Needless to say, with the exception of JPEG 2000 lossless encoding, resaving a JPEG should always be thought of as lossey...
This is correct *in the sense of this thread*. However, this subject is often causing misunderstanding in conjunction with DNG, because people associate JPEG with lossiness. Therefor I find it necessary to fine-tune it.
JPEG has two versions of *lossless* compression as well. The original one was dead born, virtually no-one used it. The replacement is supposed to be better, but nobody is using it. However, the original version turned out to be quite suitable for compressing raw image data, and it is used in quite a few cameras, for example all Canons past the 10D and 300D; furthermore, it is the choice of compression in DNG files.