Skip to main content
Noel Carboni
Noel Carboni
Legend
May 18, 2011
Open for Voting

P: Add a Camera Raw Option to Prevent Writing Back into Input Files

  • May 18, 2011
  • 55 replies
  • 2025 views

Given:

Under some conditions Camera Raw writes data back into (overwrites) its input files. Example: A JPEG file.

Under other conditions Camera Raw maintains this same kind of information in a separate place (e.g., Sidecar XMP or central database). Example: A CR2 or NEF file.

Assuming one uses Camera Raw to open out-of-camera original files as many photographers do, depending on what mode one has captured the images in, Adobe is inconsistent about whether to keep its hands off them or overwrite them... This seems to be because some formats are proprietary and some are well documented. From a programmer's perspective, this makes perfect sense.

Trouble is, from a user's perspective, this behavior cannot be described as anything but inconsistent.

Personally, I do not want my original out-of-camera JPEGs updated/rewritten under any circumstances.

Camera Raw will not touch a proprietary raw file, such as a Canon .CR2 or Nikon .NEF. There's a whole process for remembering settings in a separate database or sidecar XMP files. So far so good.

However, if you open a JPEG, TIFF, or DNG through Camera Raw, data WILL automatically be written back into it to tell another run of Camera Raw in the future what settings you used - without the software ever having warned you it will do so.

It is true that some functions EXPLICITLY rewrite input files. You can ask the software to write new thumbnails back into DNG files, for example. This seems fine - the user has instructed the software to overwrite the file, and the user is in charge, after all.

Overwriting/rewriting an input file without being instructed to do so is NON-INTUITIVE BEHAVIOR for any application. Simply put, I would not expect an input file to be overwritten by Camera Raw.

And we do see that it causes people confusion and surprise from time to time. You may right now be reading this in disbelief. I recommend you go test it for yourself (on a copy of one of your original JPEG files).

The original file being overwritten is a chief reason why I don't configure Photoshop to open my JPEGs through Camera Raw.

Adobe:

Please give those of us who don't want our input files overwritten an option for using the database/XMP sidecar instead in EVERY case.

Thank you.

-Noel

    55 replies

    Show previous replies
    Noel Carboni
    Noel CarboniAuthor
    Legend
    June 20, 2012
    Cake to you and I seems to be an obstacle to Adobe, referencing how long we've been discussing this.

    Regarding the name ambiguity, couldn't the very same XMP file carry multiple sections, one for each similarly named input file?

    -Noel
    areohbee
    areohbee
    Legend
    June 20, 2012
    Technically, it's cake to read/write from sidecar vs. embedded, *but* there is no spec for how to name files, in the case of RGB sidecars. In other words, the xmp spec says: "same basename, xmp extension", but then if one shot raw + jpeg, and imported separately, the xmp filename maps to same, and saving xmp for one would overwrite the other. One idea:

    * include the extension for rgb files, thus asdf.nef would have asdf.xmp, but asdf.jpg would have asdf.jpg.xmp. But that has the problem that asdf.jpg.nef is a legal filename for a raw nef file (stupid, but legal), which would then have the name conflict problem again.

    So, for 100% robustness, it almost demands a name change for the raw's too. In other words, for zero possibility of name conflict, one would need to change to asdf.nef.xmp for raw xmp files. But, then it would not be backward compatible.

    Another idea, use different extension for rgb xmp files, e.g. keep asdf.xmp for asdf.nef sidecar, but have asdf.jpg use asdf.jxmp for it's sidecar name. But then asdf.tif would need a different one too, e.g. asdf.txmp. Then if there was a png, it would need a different one too, etc.

    So, there are some tricky issues to be worked out. Not insurmountable, but tricky.

    My sense is that we will *never* see this change. Hope I'm wrong, but I do not expect it. Why? Because I think these issues were already thought about, and decision made - not to look back... Adobe thinks of sidecars as a necessary evil when file format does not support embedded xmp, as opposed to a plus for people who prefer sidecars for various reasons... DNG supports embedded xmp, and that's the file-format Adobe is pushing...

    Rob
    areohbee
    areohbee
    Legend
    June 20, 2012
    Hi Noel,

    Technically, it's cake to read/write from sidecar vs. embedded, *but* there is no spec for how to name files, in the case of RGB sidecars. In other words, the xmp spec says: "same basename, xmp extension", but then if one shot raw + jpeg, and imported separately, the xmp filename maps to same, and saving xmp for one would overwrite the other. One idea:

    * include the extension for rgb files, thus asdf.nef would have asdf.xmp, but asdf.jpg would have asdf.jpg.xmp. But that has the problem that asdf.jpg.nef is a legal filename for a raw nef file (stupid, but legal), which would then have the name conflict problem again.

    So, for 100% robustness, it almost demands a name change for the raw's too. In other words, for zero possibility of name conflict, one would need to change to asdf.nef.xmp for raw xmp files. But, then it would not be backward compatible.

    Another idea, use different extension for rgb xmp files, e.g. keep asdf.xmp for asdf.nef sidecar, but have asdf.jpg use asdf.jxmp for it's sidecar name. But then asdf.tif would need a different one too, e.g. asdf.txmp. Then if there was a png, it would need a different one too, etc.

    So, there are some tricky issues to be worked out. Not insurmountable, but tricky.

    My sense is that we will *never* see this change. Hope I'm wrong, but I do not expect it. Why? Because I think these issues were already thought about, and decision made - not to look back... Adobe thinks of sidecars as a necessary evil when file format does not support embedded xmp, as opposed to a plus for people who prefer sidecars for various reasons... DNG supports embedded xmp, and that's the file-format Adobe is pushing...

    Cheers,
    Rob
    Noel Carboni
    Noel CarboniAuthor
    Legend
    June 20, 2012
    That's interesting... So there already is logic at least partly there to handle settings input from possibly different sources. Thanks for that tidbit, Rob.

    -Noel
    areohbee
    areohbee
    Legend
    June 20, 2012
    Bridge(/ACR?) will write xmp as sidecar if DNG is read-only, but Lightroom will not, ever. Lightroom *will* read xmp from DNG sidecar, *if* xmp in sidecar is newer than embedded xmp.
    Noel Carboni
    Noel CarboniAuthor
    Legend
    June 20, 2012
    Thanks for adding your thoughts, guys. It's good to see this idea getting some traction.

    -Noel
    F
    FeedbackCommunityMember
    Inspiring
    June 20, 2012
    Develop settings and metadata is saved to the database, and if the user chooses again "closer" to the actual file. For raw files to a xmp sidecar file, and to jpg files (and others) to the header of the file itsself.

    This inconsistency ruins one huge advantage to saving the settings/metadata to a place other than the fast database: whereas backing up the work done on raw files, is a dream come true (as during an incremental backup or synch to a network storage only the small xmp files are copied/backed-up), this does not hold true for the jpgs, they must be backed up completely every time anew.

    Please add support for xmp sidecar files for jpgs and other non-raw files, and thus offer the option of leaving the jpgs untouched, just like the raw files. Thanks!

    A
    Anonymous
    June 20, 2012
    Maybe this is possible already, but I didn't see it. Can't Lightroom give us the option to write the metadata to a XMP sidecar file when using DNG? I know one of the advantages of DNG is the lack of sidecar files, but for those of us backing up our photos (especially when it is offsite, like Backblaze or Carbonite) it is a major pain in the... Every time I slightly modify a photo or add a tag it will have to reupload the whole file. Staying with the original RAW file is not an option, as they are completely uncompressed (twice the size).

    F
    FeedbackCommunityMember
    Inspiring
    June 20, 2012
    I want an option to force all filetypes to use xmp sidecar files only, and not to modify original file.

    While xmp data is written inside of tiff and jpg files, this makes backup to add unnecessary media consumption as those files are changes (e.gg size and CRC do not match to previous copy). This is totally unnecessary use of media space, and very annoying especially with off-site backups.

    Further, this unnecessary change of original file increases possibility of file corruption, should something go wrong.

    I agree, that in some cases where e.g. raw+jpg are used, this will require special renaming measures during import, but should not be an issue.

    For me, changes to original tiff-files are risking hight quality scans, and are unnecessaryli increating size of backups (incremental, and differential, running always full backup is not an option).

    Noel Carboni
    Noel CarboniAuthor
    Legend
    June 19, 2012
    Yes, or in Adobe terms, JDI. They might argue that it's a design change, but it's a design error so that's what's needed!

    -Noel
    Show more replies
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices