Lightroom: Problem saving metadata if certain adjustment brushing is present (often with guided upright)

  • 1
  • Problem
  • Updated 3 weeks ago
  • In Progress
  • (Edited)
Hi,

I've been having problems saving metadata under certain conditions in 2015.8..  LR will say saving metadata, but the badge will come back on after.

So far, I've been able to narrow down that it seems to happen most often when an adjustment brush is used along with guided upright.
 
The problem comes in when I try to replicate it in photos that are ok with it.
On problem photos - copying, then deleting the problem adjustment brush will allow it to save ok.  But if I re-paste that copied brush, it wont save again.  Even more puzzling is that if that if there are more than one brush, then it seems to only have a problem with ONE of them.  And again, I haven't been able to determine a pattern as of yet..  It took me quite a while to even narrow it down to an adjustment brush issue, recently.

Also of note is that it will have problems saving even if there are snapshots with the offending brush, even if the 'current' doesn't include the problem brush.

Also important here, is that just turning off upright won't fix it - only removing the offending brush will..

Sooo, therefore it might not even be a problem collision with guided upright! ...  It's just that I notice the problem occurs most often when guided upright is involved.

The only way I've been able to work around this is to create virtual copies with the offending brush (and the other settings).  However, then I lose the belt-and-suspenders backing up of settings - which I find very important to me.
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
  • Puzzled and frustrated

Posted 1 year ago

  • 1
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 3154 Posts
  • 510 Reply Likes
Chris, 

Have you attempted a preference reset to see if it makes the problematic brush - metadata save operation behave as expected?

1. Close Lightroom
2. Hold down [Alt/Opt]+[Shift] and relaunch Lightroom.
3. Overwrite the Preference file when prompted to do so.
4. Close Lightroom.
5. Restart your computer. 

Does the issue still present?
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
Just tried that..

The issue still persists.

This is a similar issue that has existed ever since maybe LR4 or LR5.  And perhaps it was because of a brush back then too, but I never narrowed it down that far.  That issue seemed to disappear for quite a while, until recently.  However, it should also be noted that I've only recently started to do more brush-type work.

Back then the workaround was to do a 'read' after a 'save' metadata and it would be fine from then on.  The metadata was actually saved.  But that doesn't work for the current [for-sure] brush related issue.

I just did some testing - saving one out as a lossy DNG, adding the snapshot of the offending brush, then removing and reimporting.  It looks like in this case, the metadata is also actually saved..  But doing a 'read' doesn't resolve it's status this time around.

It looks like this board won't accept [even lossy] DNG's - on top of a 2MB limit.  So I saved out and re-imported as a size-limited jpg.  The base rendering here was WITH the offending brush kept in when exporting.  Also included is an original  snapshot without the brush - and the snapshot WITH the offending brush.  It still doesn't register the 'save metadata' operation even as a jpg.

(Keep in mind that this is an old crappy test shot, and since it was exported WITH the offending brush as current - that the snapshots are going to look really really weird. ;)  Hopefully they still come across through this method.)


(Edited)
Photo of John R. Ellis

John R. Ellis, Champion

  • 3309 Posts
  • 829 Reply Likes
The forum software strips all the metadata from the photo.  Could you please upload the original problem photo to Dropbox or similar and post the sharing link here?  

There's been a steady stream of occasional complaints over the years about incorrect metadata status.  Some of the causes have been resolved in earlier versions, but clearly not all.  Unfortunately, the only way it will ever get fixed if users can provide a precise recipe for reproducing the problem(s).  
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
But, if they're able to download it (below), and it does indeed have the saving problem for them as well - wouldn't there be a far better chance for it to get fixed?  All they would have to do is make a copy that doesn't include either the current settings with the brush (only one, here), or a snapshot that includes the brush.

...  Seeing as how they would know far more than me about XMP, and how they write out the LR instructions.  They might be able to figure out which instruction is causing it to fail.  Or at least have a better idea than I as to which direction to go to be able to reproduce another offensive brush in another image.
(Edited)
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
Ah,  I was worried they might not come through.  But now I'm even more puzzled why Adobe would set the forum up to strip metadata like that..??

Anyways, here is the jpg file - I reset it before exporting this time.  So snapshots shouldn't look so odd.

I used a Box account..  First time I ever used it like this - so hopefully it allows download.

https://app.box.com/s/3euitmj1ti164gf7d1mgteo2klavc7qn
(Edited)
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 3818 Posts
  • 1265 Reply Likes
> now I'm even more puzzled why Adobe would set the forum up to strip metadata like that..??

It's third party software - not something in Adobe's control.
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
I would've thought a big account like Adobe would've had some sway in the matter though.  ;)

But like everything these days, Abobe likely outsources the web hosting, who in turn outsources the BB software, who in turn outsources the coding, who in turn knows nothing about image metadata.  =)
(Edited)
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 3154 Posts
  • 510 Reply Likes
Chris, is it a specific Brush Preset, a specific set of settings or do both change with time?
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
I don't really use brush presets.  And as of yet, I haven't been able to pin down any commonalities as to when a certain brush, either any of the settings or where it's painted, will cause a problem with any given image.  At this point I only have about 3 main images with this problem, but the problem doesn't seem to present itself until another snapshot is made, and then trying to save it - regardless of whether or not the new snapshot contained any new brushing.  There were more than 3, but for the others, I just deleted the snapshots and re-did everything (often without any brushing, IIRC).

I was initially thinking it could have something to do with pushing saturation beyond some limit.  Then I was thinking it could have something to do with a brush going 'past' the edges, of either the original frame and/or a cropped portion - maybe in conjunction with any upright settings and/or lens correction.  The first (saturation) doesn't seem to be the case.  I still have a suspicion about the latter, but not a whole lot of reasoning behind it yet - and it may be just because I was thinking that as I was trying to narrow it down.

    (What finally narrowed it down....  First I tried deleting all the snapshots thinking maybe it thought there were 'too many'.  When the problem persisted, but at this stage an image reset 'fixed it',  I started narrowing down the current settings by doing a bunch of copy & pasting of settings --- half of what is available to be selected, then half of that, etc..  Until finally reaching the brush.)

Have you been able to download the one from the Box.com link, and confirm it has a problem saving? (Or I should say, reporting that it had saved.)
(Edited)
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 3154 Posts
  • 510 Reply Likes
I cannot download the file you placed in Box. It says it is either no longer there or not accessible to me. 
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
Terribly sorry about that..  First time I ever tried sharing a file.  :)

I put a copy on a Google Drive instead.  It allowed an option to make it completely public, which I couldn't seem to find at Box.
https://drive.google.com/file/d/0B9w405O3QdgyTVhxcW41MVdGdk0/view?usp=sharing

Hopefully you can check it out [this time], and if it shows it saved with the problem brush (only one in there) either as current or only in the snapshot (01) - then it must be something specific to my machine/set-up.  (To be clear, it turns out it actually does save, but LR doesn't want to recognize that.)

Many Thanks.

ETA:  I just found out that if pasting just the problem brush onto another photo, either from the same camera or a different camera, that it will cause it to also have problems registering the 'save metadata'.

ETA 2:  **IMPORTANT UPDATE!:  On another image that developed a problem, I took away ALL settings and just left the brush area 'painted'.  It still had a problem until I deleted the brush's pin.  (I went and did the same for the image at GDrive - and the same thing: problem until I deleted the pin.)  So it seems to be something about how or where the brush is painted - not any particular settings of the brush.  In this particular instance, there were areas where I was erasing with a lower flow.  I painted with full-flow feathered auto-mask, and then started erasing with a low flow feather no-auto-mask brush.  This was in the upper right corner of the image.
     On the image at Google Drive, I also remember there was painting and erasing done with low-flow feathered brushes - and it was on the right side.  But to throw another wrench in this puzzle, I did try that already - painting with a low-flow feathered brush on edges  - and there was no problem.
   And in both cases, the problem will persist even after a full-flow erase over the whole image.  Very strange.
(Edited)
Photo of Roey Yohai

Roey Yohai

  • 1 Post
  • 0 Reply Likes
We have the same problem.  we have three computers working on files from a shared drive, and when someone is done working on a folder of images, they select all and save metadata (just as a safety, the 'automatically write metadata into file' is on).  however, nearly always, a small number of photos doesn't save. sometimes it'll be 18 out of 141, or 40 out of 800, unpredictable numbers, no rhyme or reason to it. often times when we look at the files that popped up as 'unable to save to file' , the metadata will be actually saved.  but it's unsettling.  
sometimes erasing the xmp file for the problematic file will solve this upon resaving, but sometimes not.  Does anyone else run into this problem?
permissions are well managed and we always check to make sure they're ok...
any thoughts would be appreciated!
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 2920 Posts
  • 424 Reply Likes
Do you have Automatically Write Changes to XMP enabled in your Catalog Settings?
Photo of Chris

Chris

  • 43 Posts
  • 2 Reply Likes
No.  I do it manually after a session.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 2920 Posts
  • 424 Reply Likes
So far, I am unable to reproduce, Chris. Either there is a missing step or you have a machine-specific issue. 

What is your OS?
Photo of Chris

Chris

  • 43 Posts
  • 2 Reply Likes
Windows 10, on gateway NV75S02u -- AMD A8-3500M APU w/on-board Radeon 6620--512MB graphics using shared 8GB (maxed out) memory
(Edited)
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 2920 Posts
  • 424 Reply Likes
Chris, 

I still haven't been able duplicate your bug exactly but I have found an issue with the Metadata on Windows when opening your catalog that isn't there on Mac. I am filing an issue on it and we will see if it helps your condition too. 
Photo of John R. Ellis

John R. Ellis, Champion

  • 3378 Posts
  • 848 Reply Likes
This post by Patrick Philippot might be highly relevant to the problem reported here: https://feedback.photoshop.com/photoshop_family/topics/wrong-timestamp-stored-in-lightroom-catalog-c... .  Patrick examined the catalog SQL database and found that the relevant database field "touchTime" could differ quite a bit from the operating system's last-modified time and the XMP:MetadataDate field, and when it differed, invalid metadata status would be displayed.  Rather than getting a single time value and using that to set the last-modified file date, XMP:MetadataDate, and "touchTime", LR appears to be getting a separate time value for "touchTime".

This issue might happen more often with JPEGs than raws, because LR will often (always?) rewrite the entire JPEG when it writes out metadata. If LR is setting "touchTime" after it finishes writing metadata, then every now and then it could take many seconds to write out a JPEG (due to operating-system and disk variabilities), and "touchTime" would differ considerable from the last-modified date and XMP:MetadataDate.
(Edited)
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 3154 Posts
  • 510 Reply Likes
Though the other post is about a a different issue the two problems seem to be related. I have referenced both threads to the filed issue but do not feel merging them is prudent. 

Thanks John!
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
Yeah, I don't think merging would be prudent either.   They're a bit too different. The timestamp issue resolves with a save-read, while the offensive-brushing problem doesn't.  Plus the [now likely] timestamp issue has existed for eons, while the offensive-brushing has only been in the recent version or two.
However, the similarities are that in both cases, it seems the metadata actually does save just fine, and they both will reshow the down-arrow badge after saving.
-----------------
And for the timestamp issue, probably not only writing out JPG's like John says - but also DNG's as well..  As I only use DNG's, and had this issue often when I was saving metadata on a higher-latency drive setup.  Though I'm guessing that there would be less of an issue with proprietary raws, as the written XMP files are small.

Either way, but especially for the offensive-brushing since it can't be resolved, it's certainly very unsettling to those of us that have come to wanting/needing the reassurance of having that belt-and-suspenders backup.  :-/
(Edited)
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
Some more insight to this, as I've been noticing:

It seems to happen more often, the more brushstrokes there are.  Either that, or the increased number of brushstrokes just gives it more of a chance to trigger it.  I might even go so far as to say, with a 'high' number of brushstrokes, it may almost certainly happen.
(Edited)
Photo of John R. Ellis

John R. Ellis, Champion

  • 3309 Posts
  • 829 Reply Likes
That is consistent with the hypothesis that the larger the amount of metadata being written, the more likely that the internal "touchTime" timetamp will be much different than the last-modified timestamp: https://feedback.photoshop.com/photoshop_family/topics/problem-saving-metadata-if-certain-adjustment... . Brushstrokes consume a relatively large amount of metadata.
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
Could be related, but the TouchTime resolves with a save-read, whereas this never does.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3309 Posts
  • 829 Reply Likes
That's the thing about bugs -- by definition, they behave in ways not well understood.
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
Oh - I tried editting that..  No wonder it didn't take.  :)  Here is what I revised it with:

Could be related, but the TouchTime issue resolves with a save-read, whereas this never does. And resetting an adjustment brush-pin's brushings and settings doesn't resolve it either - only deleting the pin will. In the radial and grad, just resetting the brushings (leaving the pin and settings intact) will resolve it, but not with the adjustment brush.

And at this point, what I notice is just an unscientific correlation.
(Edited)
Photo of Chris

Chris

  • 47 Posts
  • 3 Reply Likes
Over a year and this still hasn't been resolved.

However, I'd add that guided upright has absolutely nothing to do with this.  It was probably just a new feature I happened to be playing with a lot, at the time.
(Edited)