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

  • 30
  • Idea
  • Updated 5 years ago
  • (Edited)
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
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
  • hopeful for an improvement

Posted 7 years ago

  • 30
Photo of Andrew Rodney

Andrew Rodney

  • 557 Posts
  • 92 Reply Likes
I believe that because Adobe feels proprietary raws are read only, the alternative is sidecar files. All the other files are read/write, non proprietary files. In that context, the behavior makes some sense. Is there a reason you would not want the metadata data written into the file format itself?

As for saving data without asking, isn’t LR doing this all the time? Well to the database (or the data itself if so set).
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
Hi Andrew,

Thanks for commenting. Yes, that's the reasoning I derived as well.

My point is: Yes, there is a reason I would not want the metadata written back into the file itself: I simply don't want changes to my original out-of-camera files, however trustworthy the application. Yes, I have them backed up several ways.

As it is, I can accomplish this by just not using Camera Raw on any formats that it feels comfortable doing such write-backs to. This makes sense in another way in that Camera Raw was designed for, well, raw files, not JPEG or TIFF or PSD or whatever. The line grays a good bit when we talk about DNGs.

I'd simply like to be able to configure Camera Raw to use the metadata database or XMP file in ALL cases via a configuration option. Then it would be consistent in its operation, and I would not need to worry about whether I'm opening an original JPEG with Camera Raw.

Someone else will have to speak for Lightroom. I don't use it.

-Noel
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 382 Reply Likes
Speaking for Lightroom: two thumbs up, way up. And in the case of Lightroom, support for virtual copies would also make sense, big sense...

Thanks for posing this Idea Noel.

-Rob
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 382 Reply Likes
To Forum Administrator: please add 'Lightroom" designation to title, so Lightroom users know that this applies to them too - thanks.

To be clear: this idea is about not writing back to original camera files, and handling all photos consistently, by using an XMP sidecar for all file types (and virtual copies), or possibly in a common database if not Lightroom environment.
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
Thank you, Rob.

Yes, I'm envisioning the use of XMP sidecar -or- central database, EXACTLY as is done now for raw files that cannot be written back into.

-Noel
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 382 Reply Likes
You bet, Noel.

The common objection to this 'Idea' seems to be the argument that sidecars are a workaround for proprietary raws, but some of us would prefer sidecars regardless, or in your case the central database.

I think the main barrier to adoption is that Adobe is trying to make in-file xmp a selling point for DNG.

Technically, this would be nearly trivial to implement.

I'm hoping but not expecting...,
Rob
Photo of Robert Gonzalez

Robert Gonzalez

  • 9 Posts
  • 3 Reply Likes
Lightroom needs to be patch so that xmp files can be generated for use with dng files.

dng is not a valid raw choice unless I can treat it like any other raw file. I can't.

Our raw files are archived on dvd (read only). the edit data is archived as xmp in another location. I can use acr to force the xmp files after the edit but it would be better if lightroom didn't arbitrarily refuse to do it. (It did it in beta).

I'm not interested in hearing from anyone who wishes to argue that eliminated xmp files is a good thing. It's isn't. They're tiny and they can be used to recreate an edit long after the dngs have been removed from a catalog.

Did I mention that our raw files are archived in read only format before they're edited? They're received from photographers on dvds and those discs become our archive.

This reply was created from a merged topic originally titled
Lightroom needs to generate xmp files from dng..
Photo of Andrew Rodney

Andrew Rodney

  • 557 Posts
  • 92 Reply Likes
>dng is not a valid raw choice unless I can treat it like any other raw file.

Why not?
Photo of Robert Gonzalez

Robert Gonzalez

  • 9 Posts
  • 3 Reply Likes
Interesting. The reason is built in to the sentence that you commented on yet you ask why not anyway.

It can't take the place of what I'm using if I have to treat it differently.

Geez
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
Andrew, I suspect the difference Robert is sensing is the core concept of this thread - that the Adobe software feels comfortable in writing back into the DNG file, while proprietary camera raw files are "hands off", but that's just a guess.

Some people really want their raw files to be untouched. This is not a difficult concept.

-Noel
Photo of Andrew Rodney

Andrew Rodney

  • 557 Posts
  • 92 Reply Likes
Adobe feels comfortable writing back to lots of non proprietary file formats and uncomfortable writing back to proprietary formats they don’t control. That’s not a difficult concept for both legal and other reasons. Since there are oh so many proprietary camera formats that continue to come onto the scene every time a new camera is produced, the idea makes a bit of sense. You’re ‘stuck’ with sidecar files. But none of the above explains why DNG isn’t a valid raw choice. Its a different chose but not valid?
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
He did explain why not. He has read-only DNG files and would like to archive just the metadata in the XMP files, which are a few orders of magnitude smaller than the image files. That would represent a substantial savings in both space and time especially since he has the image data archived already.
Photo of Andrew Rodney

Andrew Rodney

  • 557 Posts
  • 92 Reply Likes
http://forums.adobe.com/message/3245182:

>It would be great to have an option whether to imbed XMP metadata into DNG file (as it is write now), or create XMP sidecar files as Lightroom does for proprietary RAWs.

Answer why its not useful:

Because it's half-baked in backup terms - you can't simply dismiss a swathe of LR work as "image relationships properties" - and it forgets that one valuable aspect of DNG is precisely that it is designed so you can safely write metadata to the format (though you'd be on your own if you do so to your only copy of the image....). Development time spent on sidecars for DNGs (JPEGs too, and why not TIFs?) would be unavailable for more important enhancements.

John Beardy

Uodate: Since you changed your post while I was writing.....

'And by the way, ACR can be forced to act like this. If you mark your DNGs as "read-only" ACR will not touch them, but will create sidecar XMPs.
While Lightroom just removes "read-only" attribute and overwrites original file without shame'

Then use ACR..... LR's ethos is to start from scratch, not slavishly replicate earlier tools.
Photo of Robert Gonzalez

Robert Gonzalez

  • 9 Posts
  • 3 Reply Likes
Writing the data "safely" has never been a concern of mine. I find the xmp files to be vital since I don't have the option of writing the metadata back to the dng (them being read only)

More than once, I've been able to recreate an edit of an event using the raws and the xmp file which allowed me to pick up where I left off.

If the originals were dng, this would have been impossible. I would have had to re-edit the job from scratch.

Fyi, Lightroom 3 doesn't remove the read only, it returns an error writing metadata.

And I haven't hit on a consistent set of changes to make and change back. Apparently, acr thinks some changes aren't worth saving.
Photo of kada jawi

kada jawi

  • 13 Posts
  • 2 Reply Likes
My backup solution does not allow for differential backups... every file that is modified even one bit has to be saved again (which takes about a minute). That is a pretty big issue, I can't just go back and update a couple of tags. Sometimes even regenerating the thumbnails as I moved the catalog location meant I had to reupload a huge portion of my library (taking a few months, which meant had I lost my drive many files would have been lost!). In an ideal world we don't need sidecar files. In reality it is a useful thing for some of us, so why not give us that option?
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
I guess the question I didn't have answered before was "what does the software do when you have a read-only DNG file?"

I just did some experimentation on some proprietary raw files, along with JPG and DNG files, making some of the DNG and JPG files read-only (but the folder still read/write), using Camera Raw 6.4.1, and here's what I found...

When configured to use the central database, Camera Raw did NOT attempt to write back into the DNG files, and instead went to the central database to store/retrieve conversion parameters. Consistently, it used sidecar XMP files in the same folder as the DNG files when configured to use sidecar files instead of the central database.

It emitted an error when Camera Raw tried to write back into the JPG files unconditionally.

Clearly the DNG files are being treated differently than JPEGs. This may answer Robert's point and it does make Andrew's question valid...

Robert, have you actually TRIED using DNG files for the task, given your processes?

-Noel
Photo of Andrew Rodney

Andrew Rodney

  • 509 Posts
  • 90 Reply Likes
>Because Adobe dropped support of the PhotoCD import plug-in from their latest products?

The Plug-in was Kodak’s, it doesn’t run in Lion. The standalone Kodak software for DCS process is even older and requires OS9. So while its not impossible today, it requires hardware and OS’s that I don’t own any longer.

Even if Adobe did drop support for DNG, its an openly documented format. Anyone who wanted to continue to render that data could. DCS files and probably PCD were not.
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
Ah yes, I forgot about the discontinuity in the Apple legacy. Thanks for the info.

I suppose it's up to whomever has archival data to occasionally review capabilities and convert to a more modern, still-supported format as needed (e.g., when you still DID have PCD or DCS support, you should have converted all your images to TIFF).

I can see that it probably wouldn't hurt, if sensing an impending discontinuity, to make DNG in addition to keeping your proprietary camera raw files then. But that doesn't mean it has to be right now.
Photo of Andrew Rodney

Andrew Rodney

  • 509 Posts
  • 90 Reply Likes
Right on. And yes, TIFF is a smart move if only based on history. TIFFs (an openly documented Adobe owned format) and PSD (not an open format but one still around thanks to Adobe’s longevity) I created in 1990 in Photoshop 1.0.9 and can be opened today in CS5 among other products. The nice thing about DNG is at least there’s a pretty high quality JPEG embedded of the current rendering if so set and desired. And if the history of imaging is any indication, a betting man will probably find DNG will hang in there a long time like TIFF and PSD. But there are no guarantees.

I have lots of legacy, proprietary image files that are now saved on what amounts to drink coasters. FITs files from Live Picture, whatever Xres saved, whatever College saved etc. Of course I could render them as TIFFs and probably did if the image was important to me. I could do the same with raws but would rather not, considering them digital negs that improve with age. Improve in terms of new technology such as PV 2010 versus 2003. I fully expect to see Adobe improve their raw processing technology so my preference would be to have a raw format that has the best chances of being processed in the future. Again, based on history and having been burned more than once, DNG seems to be the good bet here.
Photo of Robert Gonzalez

Robert Gonzalez

  • 9 Posts
  • 3 Reply Likes
So, you don't' have any of the apps that you used on those files 10 years ago? Look around, I'm sure you can find them somewhere.
Photo of Andrew Rodney

Andrew Rodney

  • 509 Posts
  • 90 Reply Likes
>So, you don't' have any of the apps that you used on those files 10 years ago?

Sure, they just can’t be run! Are you a Mac user? Can’t run OS9 on Intel hardware. Can’t run Rosetta under Lion.

You have 8 track tapes? Great. You have a machine that can play them? No, SOL. Got any files on Syquest drivers or floppies but no hardware to access that data? SOL.

And yet, TIFFs I created in 1990 in Photoshop 1.0.7 can be opened TODAY on the latest hardware and OS. In dozens upon dozens of different software packages. Thanks to it being an open, non proprietary format. DCS files, PCD files, hosts of others? No such luck. Not good, especially when pixels I created 22 years ago the same way are accessible. Pixels I created 10 years ago are not. DNG is the TIFF of raw data (its a variant of TIFF). Based on the history, I’ll stick with that for archive of my precious raw data for obvious (to me) reasons.

Sticking with proprietary raw, at least in several examples for me, is like having a 4x5 B&W neg and no enlarger or silver paper to make prints.
Photo of Robert Gonzalez

Robert Gonzalez

  • 9 Posts
  • 3 Reply Likes
My point has nothing to do with jpgs or tiffs. Only with the fact that lightroom needs to have an option to use xmp files with dng at my discretion, not Adobe's.
Photo of Andrew Rodney

Andrew Rodney

  • 476 Posts
  • 76 Reply Likes
Now all you have to do is convince Adobe why.
Photo of Robert Gonzalez

Robert Gonzalez

  • 9 Posts
  • 3 Reply Likes
Because I'm the customer and they do things because of me, not themselves.
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
Yes, an option that would FORCE the use of external storage for development settings is exactly what I'm requesting in this thread. And this option DOES need to affect all file types that can be opened by the raw processors (Camera Raw / Lightroom).

For those who seem to want to oppose this request, note that all I am requesting is an OPTION, not a permanent change to the operation of the software. Thus, you get to keep working as you do now, but the products become more useful for people like Robert and me who need to keep it from writing back to original files.

As far as convincing Adobe goes... What part of "applications shouldn't normally write back to input files" don't you understand? What they're doing now is inconsistent and wrong!

-Noel
Photo of kada jawi

kada jawi

  • 13 Posts
  • 2 Reply Likes
I don't mind the default behavior, it's just that for some use cases it makes much much more sense to use sidecar files. A here be dragons warning that tells the user what the option is for, and what the risks are behind it should be sufficient. It's like Apple telling iPhone developers that they can not use the volume buttons to take photos, because it confuses the user. Yes, perhaps, but banning a very successful application from the App Store just because there is a hidden website that users of this program can visit, so that they can activate that feature? I assume when they go through such lengths they very well want that feature and know of the consequences! I don't even mind editing a config file hidden somewhere on the hard disk.
Photo of Robert Gonzalez

Robert Gonzalez

  • 9 Posts
  • 3 Reply Likes
Noel Carboni asked:

Robert, have you actually TRIED using DNG files for the task, given your processes?

Yes, some photographers insist on sending us dng even though we've asked for camera raw direct for the camera without any changes.

I can either use the Bridge/ACR method of forcing xmps or burn new dvds using the edited dngs.

I'd rather just save the xmps.
Photo of Zalman Stern

Zalman Stern

  • 2 Posts
  • 1 Reply Like
Camera Raw will write sidecar .xmp files for DNGs if the DNG file is readonly. (I use this in my workflow as my main camera is DNG native and I do not want my raw originals getting modified.) I'm not sure if this works in Lightroom, but if not, it could be regarded as a bug and just fixed. This is a small step toward giving users full control over where metadata is stored, but it can help quite a bit.

There is certainly awareness within Adobe of the workflow issues discussed here. I agree that embedded XMP causes pain for some workflows and the lack of user control is regrettable. Unfortunately the easy changes we can make look to introduce more problems than they solve and it is hard to do something winning in just Camera Raw and Lightroom as a strong selling point of XMP is that it interoperates well across a vast range of products from Adobe and other vendors. If the other apps don't also respect the constraints, the metadata ends up with the same field stored in multiple places and becomes ambiguous or inconsistent.

-Z-
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 382 Reply Likes
|> I'm not sure if this works in Lightroom, but if not, it could be regarded as a bug and just fixed.

It does not work in Lightroom. I like the idea of regarding it as a bug to be fixed. (there have been several forum discussions about it, but I don't recall any comment from Adobe)

There is a partial solution for Lightroom users:

xEmP

In the case of DNG and RGB, it depends on xmp being 1st written to the source file, therefore you can't make them read-only. xmp will then be extracted and written as sidecar if changed. So, it solves the problem of a smaller (sidecar) file for settings/metadata that is only modified when necessary. It does not solve the problem of writing back to originals, or storing in common database. It also writes xmp-like files for virtual copies so they can be backed up and restored if necessary.
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
Zalman,

Clearly you understand the concept of never wanting an original file overwritten...

The software is MALFUNCTIONING as it is now.

But if you're worried over consistency with past (incorrect) operation confusing existing users, just add the new "Never Overwrite Original Files" option I mention here and default it to off. You can still use embedded info if you find it, but this would prevent you from writing embedded info back into ANY FILE TYPE.

This is not hard to understand!

Adobe presents Photoshop is a professional product - and I'm sorry to be blunt - but honestly you folks treat operations on your users' files in a very amateur way indeed!

-Noel
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
Sigh. Now we have Camera Raw 7 and no fix for this.

I think we can see how well Adobe listens to its customers.

-Noel
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 382 Reply Likes
Hi Noel, I can relate. Consider casting a vote on this one too:

http://feedback.photoshop.com/photosh...

I think this issue qualifies as a longstanding issue of the "low hanging fruit" variety.
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
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
Photo of Kimmo P

Kimmo P

  • 6 Posts
  • 1 Reply Like
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).

This reply was created from a merged topic originally titled
Lightroom: Option to force all filetypes to use xpm sidecar only (ptotect original file).
Photo of kada jawi

kada jawi

  • 13 Posts
  • 2 Reply Likes
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).

This reply was created from a merged topic originally titled
Lightroom: Sidecar files when using DNG (for offsite backups etc.).
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 372 Reply Likes
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.
Photo of Noel Carboni

Noel Carboni

  • 117 Posts
  • 11 Reply Likes
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
Photo of Mike Henderson

Mike Henderson

  • 2 Posts
  • 0 Reply Likes
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!

This reply was created from a merged topic originally titled
Lightroom: XMP files for JPGs please.
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
Thanks for adding your thoughts, guys. It's good to see this idea getting some traction.

-Noel
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 382 Reply Likes
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
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
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
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 382 Reply Likes
|> "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
Photo of John McAssey

John McAssey

  • 191 Posts
  • 9 Reply Likes
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.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 382 Reply Likes
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
Photo of Noel Carboni

Noel Carboni

  • 118 Posts
  • 11 Reply Likes
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