This content has been marked as final. Show 39 replies
Camera Raw adjustments made on JPEG and tiff images are not stored in XMP files. Those changes are stored within the image file itself, the same as with DNG files.
For jpeg and tiff images, since the info is stored in the file itself, is the image being degraded each time an adjusment is made in camera raw? Is the image effectively being re-saved?
With the camera raw info in the image itself, why won't an earlier Bridge version read that info. Is it just not aware of that information unless it's a true RAW file? Is it possible that other apps (Nikon capture, for instance) would be able to read the jpg with camera raw adjustments?
As a side note, how does the average user find the type of info you wrote? Seems these types of things are not in the manuals, help menus, etc.
Thanks for the answer, by the way.
Any time a JPEG image is saved again, there is a certain amount of data that is lost primarily through compression. That cannot be avoided. Tiff files incorporate compression that causes no degradation of your images. If you use maximum quality with your JPEG images it will probably take several saves before you see a noticeable loss. My normal procedure for working with JPEG original images is to do my initial adjustments in ACR, then save those adjusted images as tiff images, and do all of my further editing on those tiff images. If at a later time I decide I need JPEG images I will use the image processor to create new JPEG images as copies. It seems to me that this preserves sufficient quality for what I am doing.
The reason older versions of Bridge will not recognize those changes is because, as you suspected, it is not aware of that information being available in JPEG or tiff images. And it's doubtful that the Nikon software would have that capability either.
The information that I'm giving you is simply stuff that I have gathered from following these discussion forums. As you might suspect, I spend more time here reading than I probably should. There will be a revised version of the widely acclaimed "Real World Camera Raw..." book available sometime in September, according to Jeff Schewe. I am hoping that there will be at least a small section devoted to editing JPEG and tiff images. Don't misconstrue anything, I have never met Jeff and probably never will. I am just hoping that there might be some information available in the book when it is published.
>how does the average user find the type of info you wrote?
The "average user" doesn't find it.
That is, if we define the average user as one who doesn't read manuals, books about his software. or forums like this one.
>For jpeg and tiff images, since the info is stored in the file itself, is the image being degraded each time an adjustment is made in camera raw? Is the image effectively being re-saved?
No on both. The edits made in Camera Raw are stored as metadata within the file but the image data does not get rewritten in the process. In order to get these edits to actually change the pixel data, you need to save out a new version of the file or open it into PS (from CR) and then save. And in the case of JEPG, that is when successive recompression will rear its head so to speak.
Thanks for more good info. I'm familiar with the typical loss of data through multiple saving of jpegs. I just wasn't sure that using ACR was actually re-saving. If so, I'm not sure I grasp the benefit vs. just opening the jpeg, doing adjustments in Photoshop as I've always done, then saving as something better, like a tiff.
Actually, I've heard it stated that saving even a tiff multiple times will eventually cause image degradation. I believe this was at either a Photoshop World or Mac Design conference.
But, in any event, it's all good info to know.
The "open in camera raw" idea suggested, incorrectly I think, that now one can manipulate data in formats other than RAW, without slowly destroying the data. But it sounds like the same rules of saving and re-saving still apply.
"Actually, I've heard it stated that saving even a tiff multiple times will eventually cause image degradation."
Horse crap...the _ONLY_ time a tiff could suffer _ANY_ degradation is if you chose jpg compression as the image compression option. A straight tiff or using LZW or ZIP compression will NEVER cause degradation because those are "lossless" schemes...
Be real careful who you listen to....
Yeah, stop listening to idiots.
I do appreciate the info given here. I have to admit, I'm a bit surprised by the corseness of some discussion here though. Not having used the Adobe forums that often I just took it for granted that these official forums would on a little higher plain.
As a pro who's been in the photo/web/digital imaging business for some time now, but always open to learning more, I find many forums useful. The ones that I use often, though, refrain from such pointless posts such as, "Stop listening to idiots." And, where someone who is trying to improve their knowledge makes statements that others feel or KNOW are incorrect, correction is made without resorting to childish, unprofessional dialogue.
I'm trying to be careful who I listen to, thus the "how does the average person find out this info" question. At this point, other than Ramon's posts, I have a nice thread from which to make a coin toss about whom to believe as I don't personally know anything about any of the other authors. I don't at all mean to step on toes of any experts who may have posted to this thread, but if that's the case, you're simply not an expert that I'm yet aware of. Don't take for granted that everyone has heard of everyone else and knows their credentials.
Mr. Shewe's seems believeable as it's written with very adamant language. But prior to his post, one said the info DOES change the jpg one said the info DOESN'T. How does one make a decision whom to believe? How is one to be careful of a source when learned at a well-respected conference full of well-known and well-respected session leaders?
Seems like the question of whether ACR is affecting the underlying jpg/tiff data in a negative way is pretty basic and important info for the average user who is using raw adjustments. Does Adobe not have user info available on this?
These are user to user forums, Chris. You are not addressing Adobe here.
That being said, anyone that tells you that TIFFs degrade after each resaving is an idiot.
Lots of strong opinions/personalities on these forums, dont take any of it personally. But there is also a lot of extremely useful info and if you follow many of the treads, the knowledge level of various regulars will become apparent.
In terms of your question about why youd use CR for JEPGs or TIF vs Photoshop, its just a different workflow. One advantage is that it gives you the ability to use CR image processing controls that are not easily duplicated in PS. Another is that you can load multiple images via the film strip mode and sync your edits. And it is essentially non destructive until you render out a new image. So you can tweak endlessly and never touch the pixels until the image is saved as a new version.
Hope that helps-
Only metadata is touched when using ACR for JPGs, TIFFs and RAWs alike - no file degradation to JPGs as long as the edits take place in ACR - effectively 'metadata realm'.
"How is one to be careful of a source when learned at a well-respected conference full of well-known and well-respected session leaders? "
Unless you state the person who said something and name the exact conference you are referring to, there's no way to give you an absolute answer...there are a lot of "experts" out there and not all of them have equal knowledge...then of course there is the chance that what somebody has said is misunderstood by the listener...so, second hane knowledge is even less reliable. So, I come back to be careful who you listen to (and then listen carefully).
And it's Schewe, not Shewe...do a google on schewe and you'll know exactly who I am.
What's more, Jeff is currently writing a book on the subject so you can take it that he DOES know what he's talking about!
>then of course there is the chance that what somebody has said is misunderstood by the listener.
How can we ever forget C_h_a_n_d_i, who swore that she had been told 'by experts' that "JPEGs deteriorate over time, just sitting there on your hard disk", as if they were bananas or eggs. :D
Ah but she did live in a hot country as I recall
Okay, since I'm the one who created the confusion, I will ask the question again. Camera Raw is able to write metadata changes to JPEG and TIF images. As far as JPEG images are concerned, is writing this metadata done nondestructively if you save the JPEG image directly from Camera Raw?
It is my understanding that if I open the JPEG image into Photoshop directly from Camera Raw and then save it again as a JPEG, that will cause image degradation. But if I save the changes made to the JPEG by clicking the "Done" button in ACR what effect does that process have on the JPEG image?
And I apologize for any confusion that I may have caused.
Its simple. When you re-compress a JPG, you will get further degradation of the image. The image has already been degraded from the first time it was saved as a JPG. JPG is a lossy compression format, and every time you save a JPG, you loose information. That is also true when you re-save a JPG.
When you open a JPG in Camera RAW and do edits to it, you are working on the metadata level. The edit information is written by ACR into the header of the file, and ACR uses this information to display your edits, without re-encoding the JPG (the file has not yet been 'saved'). This is the whole idea of using ACR for edits of TIFF and JPGs - what you do in there is non-destructive and reversible.
If you save this ACR edited JPG file as a TIFF or PSD file, you will not loose further information to compression.
If you choose to save it again as a JPG, you will loose information - see paragraph 1.
That is what I thought, but for some reason I still had a little confusion about it. Thank you for clearing it up for me.
>if I save the changes made to the JPEG by clicking the "Done" button in ACR what effect does that process have on the JPEG image?
ACR has to decode the JPEG data in order to present it on the monitor. When creating a new file, ACR can take the decoded data (the image in the format ACR stores it in memory) and encode it, or it can re-read the original, encoded data and write it unchanged (of course, it may have kept that in memory in encoded format as well...).
Which way ACR is doing it can be answered only based on knowledge of the actual program code. It could be both ways.
However, even if ACR is re-encoding the image data, it does not lead to any degradation, because ACR will use the very same parameters for the encoding. I don't *know* this, but I am pretty sure that if ACR re-encodes the data, it does not change the parameters; this is the reasonable way.
One has to understand, that the "quality" setting is only a symbol. The actual JPEG encoding is based on a set of parameters, at least 256 independent values plus a decision of huge impact. Changing any of these parameters between decoding and re-encoding does cause image degradation; otherwise not.
You still don't get the concept. Whenever you click the "Done" button in ACR it writes information to the HEADER of the file, regardless of its format. It never modifies the image data. It doesn't matter if it's a raw file, a DNG, a JPEG, or a TIF. ACR never modifies image data, NEVER.
Alright, one exception. Original raw files and XMP sidecar files. But even in that situation the image data is NEVER modified!
>You still don't get the concept. Whenever you click the "Done" button in ACR it writes information to the HEADER of the file, regardless of its format
I'm afraid you are oversimplifying this.
A JPEG file does not have any "header". The adjustments are recorded in XMP form in a so-called "marker", in the APP1. This is located somewhere in the *middle* of the JPEG file.
There is no such thing as "writing only to the header of the file". The file has to be re-created completely. The image data part of the file can be copied or re-created *without any image modification*, as I described this before, perhaps in too technical terms.
Launch Bridge just to verify this.
Target an ACR-modified JPEG in Bridge. Go to the Edit menu > Develop Settings > Clear Settings
The adjustments (modifications) are stripped instantly. The pixels in the original JPEG were never touched by the ACR adjustments. The image was in no way "recreated". Some information was just added as metadata, and the metadata is removed by the Clear Settings command, leaving the original JPEG in its original condition.
It's impossible to get this across to this person. I don't know, maybe "header" was not the proper term. I am not a file format guru. But the concept is the same regardless. Wherever ACR writes those metadata it does it without altering the picture data. That is the concept that is trying to be explained. It is the same concept that is used in Lightroom, but we won't go into that here.
Upon re-reading his posts, I thing G Sch objects to the use of the phrase "unaltered file" when we mean unaltered pixels.
>The pixels in the original JPEG were never touched by the ACR adjustments
This statement is meaningless. We were not talking about "touching the pixels" but "degrading the image".
>The image was in no way "recreated"
This is not the question of opinion but of the actual program code.
You stated on another thread, that you "don't deal with JPEG" (and you supported this with another factual sounding but incorrect statement re JPEG). I think the best is if you stick to "not dealing with JPEG".
>It's impossible to get this across to this person
Laypeople often have difficulty to explain their misguided ideas in technical terms; I am used to that, though your stubborness is over the average; you don't even try to understand the issue.
>Wherever ACR writes those metadata it does it without altering the picture data
I stated, that *the image data part will not be modified*, either by copying the original data or by re-creating it. This was the essence of my original post, which you did not understand.
>We were not talking about "touching the pixels" but "degrading the image".
OK, Mr. Know-It-All, how would you accomplish the degradation of an image without touching or altering its pixels?
Inquiring minds want to know. Give us lay people the benefit of your expertise. Thanks in advance.
This just gets worse and worse!
> We were not talking about "touching the pixels" but "degrading the image". >
Please explain to us how the hell you think that an image is being "degraded" if the pixels remain UNTOUCHED?
> "A JPEG file does not have any "header". The adjustments are recorded in XMP form in a so-called "marker", in the APP1. This is located somewhere in the *middle* of the JPEG file".
I just edited a JPEG in ACR, then I examined it in a hex editor and in Word.
The JPEG file started with the SOI marker code FF D8. Then at byte 20 was FF E1, the marker code for APP1. Then the XMP followed that.
The "http://ns.adobe.com/xap/1.0/" at the start of the XMP started at byte 24. The rest of the XMP followed, up to byte 2966. Hardly the middle. (It was a 44KB JPEG).
Care to elaborate on the significance of that finding for the benefit of us, mere lay people, Barry?
The pixel data is NOT modifed. Nothing is "degraded" by the metadata edits to any format supported by Camera Raw, including JPEG files.
>how would you accomplish the degradation of an image without touching or altering its pixels?
>Please explain to us how the hell you think that an image is being "degraded" if the pixels remain UNTOUCHED?
Are we attending a course of basic English comprehension?
I stated clearly, that
b the image data will not be degraded, whatever way ACR is going
The essence of what I posted is, that this effect can be achieved on different ways. In other words, perhaps this can help further: no matter, if the image is re-created or copied from the old file, the result is not degraded.
THIS WAS THE SUBJECT OF THIS THREAD.
>I just edited a JPEG in ACR, then I examined it in a hex editor and in Word
I just edited a JPEG in ACR, then I examined it in SPF. The APP1 marker (note: there are no tags in JPEG) starts at 25ba.
However, this is irrelevant: *wherever* the marker is, the *file has to be rewritten* in order to incorporate the data. There is no such thing as "inserting some information into the header".
Thomas Knoll, creator of Photoshop and ACR has spoken in post #31.
We can now let this rest.
>Are we attending a course of basic English comprehension?
No, but you might consider one in writing.
Hmmm I don't know where I pulled "Gabor" from. It just seems to ring a bell from another discussion you may have had with someone else.
> "Care to elaborate on the significance of that finding for the benefit of us, mere lay people, Barry?"
While Jim Hess doesn't know the technical details of how XMP metadata is held in JPEGs, he does have an awareness that it is held near the start of the file.
While "G Sch" DOES know the technical details of JPEGs, (probably more than anyone here except Thomas Knoll), he was wrong to state that the APP1 containing the XMP was in the middle of the JPEG/JFIF file. In fact, at least in my experience, it is near the start.
This can be important for software that wants to update XMP metadata. For example, once a JPEG has XMP in it near the start, it might be possible for software to update the XMP without having to re-write the whole JPEG file, as a performance optimisation. This would be in contradiction to what "G Sch" said:
> "There is no such thing as "writing only to the header of the file". The file has to be re-created completely".
I don't know if there is a technical reason why this can't be done. But I observe that there can be a few KB of nearly-empty space (in the form of lines of spaces) between the end of the useful XMP data and the end of the XMP packet. This could be there to allow it to be edited without interfering with the rest of the file. (I notice that, having re-edited the XMP in a way that changes the length of the useful data, the end of the XMP is still in the same place - the editing didn't change the position of the rest of the data in the file).
I don't know whether Bridge+ACR (etc) actually do just over-write blocks. Perhaps, if I have time, I'll run a timing test on 100s of large JPEGs already containing XMP to see if I can change the XMP metadata in all of them and have it saved at the speed of block-updates rather than file-rewrites.
ps: Having re-read what "G Sch" has said in this thread, I see no hint that s/he ever believed that changing the XMP metadata degrades the image. Quite the contrary - I'm sure s/he believes it doesn't, and has said so from the start.
>he was wrong to state that the APP1 containing the XMP was in the middle of the JPEG/JFIF file. In fact, at least in my experience, it is near the start
A JPEG file has a specific structure. ACR inserts the APP1 marker after the APP0 marker (that contains the Exif data), into the JPEG structure, in betweeen other makers. Someone knowing the structure of a JPEG file should not interpret the "middle of the file* as the *physical middle*, because the bulk of the file contains the image data (in one or more chunks), which can not be interrupted by any other marker (except...).
Anyway, this is inconsequential; update in place is equally possible at the end of file. The point is, that the *structure* changes with inserting the XMP data.
>This can be important for software that wants to update XMP metadata. For example, once a JPEG has XMP in it near the start, it might be possible for software to update the XMP without having to re-write the whole JPEG file, as a performance optimisation
First of all, the "original" JPEG usually does not contain any XMP data.
i This excludes all initial adjustments from being updated in place.
For the cases that someone makes adjustments with ACR repeatedly: updating in place is a risky action. Anything happens before the update is finished (that may stretch over sector boundaries) and the file is ruined (although in our case only the XMP data would be ruined).
The safe procedure is: create a temporary file with the updated data and when that is finished "exchange the names", and as the last action, delete the original.
I checked out the result of repeated adjustments: although the APP1 marker has lots of reserve and the file size does not change after repeated adjustment, the actual data shifts between the adjustments. Changing one parameter may shift most of the data within the APP1 marker's length, and this can go over sector boundaries (the XMP data space is over 8KB).
It is *possible*, that ACR makes update in place *in case of repeated adjustments*; the extra space allocated for the APP1 marker points in that direction. The performance advantage could become relevant with mass-updates, but then again: first time adjustments are no candidates anyway.
>I see no hint that s/he ever believed that changing the XMP metadata degrades the image
It is refreshing to see, that someone actually reads and comprehends messages, instead of transmuting them into their own thoughts.
> "Someone knowing the structure of a JPEG file should not interpret the "middle of the file* as the *physical middle*, because the bulk of the file contains the image data (in one or more chunks), which can not be interrupted by any other marker (except...)".
The 44 KB JPEG I was looking at had (I think):
APP1 > containing XMP (at byte 20)
The XMP wasn't in the "middle" either in a logical/structural sense, nor in a physical position sense. All that can be said is "it wasn't actually AT the start"; (just near it). For some purposes, this matters.
> "This excludes all initial adjustments from being updated in place".
True. The first insertion of XMP will require a re-write of the whole file. It is only subsequent amendments to the XMP that can, with a suitable implementation, just use block-over-writing.
> "Anything happens before the update is finished (that may stretch over sector boundaries) and the file is ruined (although in our case only the XMP data would be ruined)".
Or SOME of it may be. I don't know how big sectors are nowadays - when I was helping to design mainframe operating systems, decades ago, we often used 2 KB. Can they cover a block of real XMP data now?
>APP1 > containing XMP (at byte 20)
The point is, that the XMP data is
i within the JPEG structure,
it is not an appendage nor a header of it.
The reason that it is so close to the beginning is, that this file does not have Exif data.
>I don't know how big sectors are nowadays
The sectors are 512 bytes in general (there might be some exceptions). Think of the cluster size: it can be as low as 512 bytes; the sectors can't be larger.
>when I was helping to design mainframe operating systems, decades ago, we often used 2 KB
It depends on the number of decades. Earlier the mainframe disks were not sectored, the blocks were written in variable length (CKD, count-key-data, the "count" is always 8 bytes, the key is from 0 to 256, the data in variable length...).
There is no effective search mechanism with the sectored disks; ISAM and keyed direct access would not work. Sectored disks are useful for applications requiring keyed searches only with VSAM.
Plus, in the times of expensive disk space, one could write blocks with size of the full capacity of the track, utilizing the total physical capacity of the disks.
Of course, ISAM is dead now, and the price of disk space is a tiny fraction of the price on a 7MB or 29MB disk.
(The above is more than a bit off topic.)