Legend

Open for Voting

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

Forum|Forum|14 years ago
May 18, 2011
55 replies
1999 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

areohbee

Legend

In my opinion, Adobe made a mistake (er, I mean: "decision") a long time ago, which we may have to live with for a long time to come:

* Original filename extension not included in xmp sidecar filename.

(this would be a good decision if your plans were firm to live forever with embedding xmp in all but proprietary raw files; otherwise: not a good decision)

This means JPEG, with same basename as RAW, for example, will have same xmp sidecar filename.

So, we got a problem. Not insurmountable, but a problem nevertheless.

I personally hope they bite the bullet and tackle it head on / take the bull by the horns and wrestle him down, i.e. find a way to support sidecars for all file types so we can end this discussion ;-}.

I try to keep expectation low, but hopes high...

Rob

F

FeedbackCommunityMember

Inspiring

I was constantly annoyed that .jpg files downloaded from phones got timestamps changed, making it impossible to find out even which month they ware taken, until I found that Lightroom is destroying the (file) timestamps.
As Adobe seems not to know (or does not care) - not all phones embed EXIF data in photos.
Thus I got most phone photos with timestamp destroyed, which made me extremely angry! Why the hell you do this? DAM software destroys metadata!!!

It should be not so complex to put option about whehter to modify any existing file or just create sidecar file for it.

It makes much more sence that file's timestamp equals exif's "create time/date" (if any).

F

FeedbackCommunityMember

Inspiring

I like a clear separation between Digital-Asset-Management and editing of my video, audio, image and office files. With this I use for DAM other tools and for editing Lightroom, CaptureOne and others. I dislike updates or modifications of any big video or raw image files just because of minor meta data updates. That is why I set read-only for video, dng, jpg, ... and I really would appreciate consistent settings for xmp sidecar handling in Lightroom. GeoSetter, IMatch and JPhotoTagger are good examples of tools which are respecting consistent xmp sidecar settings.

In addition to the original posting idea/proposal I like to protect not only original out-of-camera JPEGs under any circumstances, but also ALL other original files like DNG, PNG, ... If possible this could be realized in addition through detection of read-only attributes of files. E.g.: Instead of error message when exporting XMP data ot DNGs wiht LR, there could be an automatic or user confirmed generation of XMP sidecar.

Roman

JJMack

Community Expert

As you put it its good to have options. Users have different needs and preferences. There is no clear one right way to do something as complex as asset management. For some making use of a database is the right way to go. Even then there having redundant information in image file may give them more options for an application may come about that the may feel a need to may know how to use metadata and know nothing about how to use the users fantastic database. Databases can facilitate many thing some user want and need to do and they can and do co exist with metadata. Many do not want to become or have to become software engineers they want a life. Some even want to put that behind them. Adobe is making that harder for me to do for their new releases are not up to snuff.

Yes I know autosave saves versions of a document your editing not over the original was just testing you there...

However if you give a novas user a loaded gun what prevent them form shooting themselves in the foot when they use File>Save. I'm willing to bet that more the one new user has resized an image to email to someone using File>Save only to find out later on they no longer had an image file worth printing.

JJMack

Noel CarboniAuthor

Legend

First off, you clearly don't understand AutoSave.

But secondly, if *I* choose File - Save, then I'm commanding the software to save over the file. That's not the same as overwriting my file when I just choose File - Open - not by a longshot!

I sense that you're trying to get me to "think differently" about files and applications, or maybe to try to teach me basic computer usage. Thanks for the effort, but with 36 years software engineering experience under my belt neither of those things is likely.

-Noel

JJMack

Community Expert

If a Program like Photoshop opens an as you call it an input file and you make updates to it and you use menu File>save or with CS6 have left the default autosave preference setting un changes does not the input file get over written with the exception of RAW files. For Photoshop can not write Camera RAW files. You have to got to be careful or defaults will kill you. No!

JJMack

Noel CarboniAuthor

Legend

John, you say that it's good that image data is not altered, that it all should be done via metadata, yet you advocate the Adobe software writing the metadata into the original file.

It's not a big leap to understand that some folks think ALL the data in the original file is something we don't want altered, is it?

Like Rob says, I'm not looking to change the product to avoid writing in any metadata-capable file for everyone. I'd just like the OPTION to do that. I'd even expect the default would be to work as it does today.

I don't understand your comment "However when it come to Jpeg Image data other application will alter this data". From my perspective, properly written computer applications in general have INPUT files (which they open) and OUTPUT files (which they save), and if one doesn't save over an input file one really doesn't expect it to be altered!

-Noel

areohbee

Legend

Nobody is suggesting the removal of the option for embedded metadata. But for those of us who understand all the ins and outs and would still prefer sidecars or database only, we would like the option. I can even imagine multiple checkboxes:

1. Embedded.
2. Sidecar
3. Database (if non-Lightroom environment).

That way, user can have his/her cake with frosting, or without, and eat it too...

Rob

JJMack

Community Expert

Noel you wrote

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

Then you should not use LR or the Bridge for they are metadata editors. I personally think that that good. Raw camera image data is not altered. Which is what I care most about. However when it come to Jpeg Image data other application will alter this data. Only Camera RAW data seems safe for now. I also feel the some metadata should not be changeable like some EXIF fields not all though. I also feel the best place to record RAW conversion setting is better placed there then in external locations like databases and sidecar files. I like the ability of keeping information about an image in the image files themselves. In standard formats like EXIF IPTC etc. My vote would be to do away with the ACR database and sidecar files in favor of keeping RAW setting in metadata and perhaps even supporting versions of raw conversions. I also feel more application should utilize this data like web galleries generators should get copyright, title, description, EXIF and other metadata information. I also have no objection of LR building logical database over this information quick indexed quires are useful for many applications.

JJMack

areohbee

Legend

|> "couldn't the very same XMP file carry multiple sections, one for each similarly named input file?"

I suppose it could - but I haven't thought through the implications. - definitely not insurmountable...

~Rob

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded