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

[chain569]

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.

[Rikk Flohr: Photography]

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?

[chain569]

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.)

[John R Ellis]

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).  

[chain569]

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

[Victoria Bampton LR Queen]

> 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.

[chain569]

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.

[Rikk Flohr: Photography]

Chris, is it a specific Brush Preset, a specific set of settings or do both change with time?

[chain569]

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.)

[Rikk Flohr: Photography]

I cannot download the file you placed in Box. It says it is either no longer there or not accessible to me. 

[chain569]

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.

[chain569]

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.  😃

[FeedbackCommunityMember]

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!

[chain569]

When you say you erase the XMP, I'm thinking that you're just deleting the sidecars for proprietary raws.  If that's the case, then I think LR should still have the problematic brushing (if it's the same cause here) held in the catalog.  So only by ridding both the current settings AND any snapshots that contain the problematic brushings, will it allow it to report as saved.  .... That is - if we're talking about the same causes, here.  To diagnose, make sure to delete ANY brushings within ALL areas - grad, radial, and adjustment brush - and make sure no snapshots contain them, either.

And to Rikk:
I've also just had this problem present itself from brushing out areas within a graduated filter.  However in this case, it resolved itself by simply resetting the brushing..  I didn't have to also delete the pin, like I did with the adjustment brush.

[Rikk Flohr: Photography]

If you create a fresh Test Catalog, does the problem manifest there as well?

[chain569]

Yep..  I even tried both routes:  Both 'export as catalog' and secondly, a completely fresh 'New Catalog' and then imported as 'add in-place'.
With either, it still won't register the saving.

The file above, at Google Drive, will now very likely show it happening.  And of course, you have my permission to send it off to the engineers in the hopes that it could help them discover the issue.  In that file's case, it's an adjustment brush - so you can remove ALL the brush settings, and even completely erase the brushings from the entire image, and it will still have a problem - only removing the pin will resolve it (and making sure that snapshot 01 doesn't have it, either).

[Rikk Flohr: Photography]

Chris, you are correct. The file doesn't show a problem. Here's what I need. Take that file that is causing the issue with the edits/metadata flag, and select it. Export that Single file as a catalog including the Negative and any previews. The resulting folder needs to be Zipped and shared as a single file like you did before.  I will try and reproduce from your single-image catalog copy. 

[chain569]

OK, here's the link:
https://drive.google.com/file/d/0B9w405O3QdgydzNnS0J4b2NPWlE/view?usp=sharing
Thanks so much for looking into this!

[Rikk Flohr: Photography]

Do you have Automatically Write Changes to XMP enabled in your Catalog Settings?

[chain569]

No.  I do it manually after a session.

[Rikk Flohr: Photography]

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?

[chain569]

Windows 10, on gateway NV75S02u -- AMD A8-3500M APU w/on-board Radeon 6620--512MB graphics using shared 8GB (maxed out) memory

[Rikk Flohr: Photography]

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. 

[John R Ellis]

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.

[Rikk Flohr: Photography]

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!

[chain569]

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.  😕