How to prevent propagating faces regions from masters to versions?

[Schmidtze]

Hi,

I'm using new Lightroom Version 6 for tagging my RAW files with faces. They will be stored in XMP data. When cropping an image in the development module of Lightroom and then exporting it to a JPEG file, the face regions will be adjusted correctly by Lightroom. Because of the cropping, the region values are different in the JPEG version compared to the master RAW file. But then in IMatch, where I manage the RAW files and also the JPEG version files, the faces regions will be propagated from the RAWs to their versions, and so the correct regions in cropped JPEG files will be overwritten with wrong values.

Does anybody have an advice what to setup for propagation? Now I have "XMP without Camera Raw data" and "Don't copy XMP orientation" enabled. What I need to be propagated are ratings, colour labels and of course keywords. Do I maybe not need the XMP propagation? But how to propagate the keywords then? As I see they only will be propagated when I have the XMP propagation enabled. Or do I miss maybe something?

Many thanks in advance
Friedemann

[Schmidtze]

As I found out by now, in my opinion a new propagation option "Don't copy XMP anotations" (or something like this) is needed, similar to "Don't copy XMP orientation". As far as I know, annotations are always regions in the image, which may be completely different in master and version files, because of cropping, rotation etc.

Best regards
Friedemann

[Mario]

Sigh. That's (yet another) a very specific situation. Face regions (and other regions) are part of the standard XMP data, and thus are migrated with the rest of XMP. There is currently no feature to propagate all XMP but leave out face regions, or pet regions or any of the other region types.

Regions are resolution independent, which means that they can be copied from a larger file to a smaller file. That you are copying them from a larger file to a differently cropped and smaller copy of that file is not supported.

We already added exceptions for the crop records (produced mostly by Adobe) and the Adobe camera RAW data (produced only by Adobe). I'm reluctant to start adding yet more exceptions for face regions, or pet regions or any of the other region types. Or only when the target version is cropped differently (impossible to tell).

Piling options on top of option sin IMatch is probably not the right way to handle all this. And then I will start hearing again about "Too many options" and "Too steep learning curve". I would happily rip out 80% of all the metadata-related options because that would simplify my life. And IMatch would still be more flexible than any Adobe or Apple product when it comes to metadata handling.

Let's hear what other users say. Probably you should add a feature request so other users can discuss this and Like your idea.

(If you can, send me a couple of sample files with face data produced by Adobe LR 6 I'd be grateful. I've had some info that they are not entirely XMP/MWG compliant and I would like to have a check). You have my email.

[Mario]

I could handle this with a small change in one of the configuration files of IMatch.
Thankfully I anticipated such things and made this configurable via the central metadata configuration. We now have a "Don't copy XMP Regions", which skips the xmp-mwg-rs namespace when propagating. It works well with my sample files, but I have no idea if Adobe sticks to the standard in LR. Send me some sample files please.

Still, making changes and adding more options to IMatch all the time cannot be it. First the "non XMP LR data" then "non Adobe CRS data", now "non region data", ... 

[Schmidtze]

Hi Mario,

you are right, the regions are resolution independent. But it's normal to crop, resize and change aspect ratio of images when developing RAW files. And at the moment, the regions will be destroyed by IMatch. So in my opinion, without any doubt, soemthing have to be changed ;-)

> And then I will start hearing again about "Too many options"


yes, I agree. And honestly I also think that there are too many options. All the options are technical, talking about XMP, IPTC etc. Yes, I understand the problem, it's very difficult to provide a solution which covers all circumstances without any options. But for this case, it's absolutely necessary to change the behaviour. If with a new option or simply by never propagate regions (without an option), I don't know...

After saving metadata to a RAW file or exporting to a JPEG file in Lightroom it looks like this

   <mwg-rs:Regions rdf:parseType="Resource">
    <mwg-rs:AppliedToDimensions
     stDim:w="4608"
     stDim:h="3072"
     stDim:unit="pixel"/>
    <mwg-rs:RegionList>
     <rdf:Bag>
      <rdf:li>
       <rdf:Description
        mwg-rs:Rotation="-0.02090"
        mwg-rs:Name="Friedemann Schmidt"
        mwg-rs:Type="Face">
       <mwg-rs:Area
        stArea:h="0.07643"
        stArea:w="0.05732"
        stArea:x="0.24025"
        stArea:y="0.16293"/>
       </rdf:Description>
      </rdf:li>
     </rdf:Bag>
    </mwg-rs:RegionList>
   </mwg-rs:Regions>

But I now also have this version (maybe saved by IMatch?):

<rdf:Description rdf:about=''
  xmlns:mwg-rs='http://www.metadataworkinggroup.com/schemas/regions/'
  xmlns:stArea='http://ns.adobe.com/xmp/sType/Area#'
  xmlns:stDim='http://ns.adobe.com/xap/1.0/sType/Dimensions#'>
  <mwg-rs:Regions rdf:parseType='Resource'>
   <mwg-rs:AppliedToDimensions rdf:parseType='Resource'>
    <stDim:h>3072</stDim:h>
    <stDim:unit>pixel</stDim:unit>
    <stDim:w>4608</stDim:w>
   </mwg-rs:AppliedToDimensions>
   <mwg-rs:RegionList>
    <rdf:Bag>
     <rdf:li rdf:parseType='Resource'>
      <mwg-rs:Area rdf:parseType='Resource'>
       <stArea:h>0.07643</stArea:h>
       <stArea:w>0.05732</stArea:w>
       <stArea:x>0.24025</stArea:x>
       <stArea:y>0.16293</stArea:y>
      </mwg-rs:Area>
      <mwg-rs:Name>Friedemann Schmidt</mwg-rs:Name>
      <mwg-rs:Type>Face</mwg-rs:Type>
     </rdf:li>
    </rdf:Bag>
  </mwg-rs:RegionList>
  </mwg-rs:Regions>
</rdf:Description>

I just implemented both in a beta version of my application GeoSetter. I think Lightroom do not use a special format, the use the same method than Picasa does (see also here http://www.nilsmosbach.de/2012/google-picasa-faces-in-windows-live-fotogallerie-ubernehmen/.

Here you can find 2 examples, a DNG and a developed image (changed aspect ratio, cropped and rotated): https://www.dropbox.com/sh/i7anzwcpn150mna/AABF7bQNDxd36G-xIZFtmy6Sa?dl=0

Best regards
Friedemann

[Mario]

you are right, the regions are resolution independent. But it's normal to crop, resize and change aspect ratio of images when developing RAW files.

Yes. And the application in which you crop and change the aspect ratio is supposed to adjust the regions as needed. But I don't think that understanding what you did in LR to produce the versions and then adapting the XMP data contained in your files to handle all this should be a task for a DAM.

And at the moment, the regions will be destroyed by IMatch. So in my opinion, without any doubt, soemthing have to be changed ;-)

IMatch does not destroy anything. Where does this come from?

Here you can find 2 examples, a DNG and a developed image (changed aspect ratio, cropped and rotated): https://www.dropbox.com/sh/i7anzwcpn150mna/AABF7bQNDxd36G-xIZFtmy6Sa?dl=0

When you tell IMatch to copy XMP data from your master files to your versions, it will do exactly that. And because regions are part of the XMP record, they will be copied. Just like that. A bit common sense is to be expected here, frankly. Copying metadata between files is not really part of a DAM, especially not on the  level detail we talk about here. Adjusting regions when cropping, resizing and rotating a file is the job of the image editor, not your backend DAM.

"Leave out Adobe CRS data", "Leave out Adobe LR data", "Leave out XMP regions", "Leave out this and that" but in no way add more options. Impossible. And for my taste, IMatch has too many options already. They complicate the UI and the code I have to maintain.

Frankly, I could easily rip out 80% of the metadata options and still be fully compliant with XMP and the recommendations of the Metadata Working Group. Happy days  But then a large share of the IMatch user base would be left hanging, because they need all these options to tame the data produced by LR, CS or other RAW processors, and to be able to make their workflow,eh, work.

All this options have been added because users need them. And I better not tell you what I think when users start to complain about "too many options".

[Schmidtze]

Hi Mario,

are you angry now because of my comments? It seems so 

> But I don't think that understanding what you did in LR to produce the versions and then
> adapting the XMP data contained in your files to handle all this should be a task for a DAM.

I don't understand this sentence... Do you think it's not normal to crop and rotate an image file?

> IMatch does not destroy anything. Where does this come from?

From me  Yes, ok, I switched on an option which causes this behaviour. But I HAVE to switch it on for propagating the keywords. And fact is, IMatch replaces image data with data which do not fit to the image in most cases! Cropping and rotating IS normal. And as far as I understood by now, IMatch is for managing RAW files and their developed versions. Honestly I don't understand why you have all these XMP options, I told you already. These options come from the technical side, but the user is not interested in XMP and IPTC. He only wants to propagate ratings, labels, comments, keywords etc. (or he doesn't want to). That's all. The user don't have to know about XMP, it's only you who have to know. But I don't want to fight about this!!! So please excuse me! 

> All this options have been added because users need them.

Yes, yes, yes! I understand, I know this also from GeoSetter. And maybe my point of view described above is for my purposes, but software should cover a lot of purposes. But as I said, without changing the behaviour with the faces, IMatch is very restricted now. I have to decide between 2 things: Do I want to propagate keywords (and destroy(!) the correct regions) or do I want to keep the correct regions created by Lightroom, but without propagating keywords. Then the whole mechanism of propagating is not usable for me anymore. For me keywords are the main focus when using the propagation feature. But of course I don't want to lose other information in the images, like faces. I cant' tell you how to handle this, by using a new option or whatever. But you have to agree, that the situation now is very awkward. You have to agree when standing on the user's side. And there's no need to be angry about this...

Best regards
Friedemann

[Mario]

Thanks for the sample files.
It seems that LR is omitting the UNIT element of the rs:Area in the face regions. From what I can tell from the MWG spec, the UNIT is not optional. The MWG docs say:

stArea:unit
Open Choice
In the context of this document, only "normalized" is being specified for handling image regions.
However, for compatibility with the XMP specification and future extensibility, the list will be kept open so that absolute coordinates could be added later-on.

It's not marked as optional. At least to my understanding.
IMatch falls for this and rejects the face regions in your files because it cannot determine the unit in which the area parameters are specified.
I can handle that easily by assuming "normalized" but I'm not sure if this is valid...

[Mario]

He only wants to propagate ratings, labels, comments, keywords etc. (or he doesn't want to).

Yeah, and then he copies XMP data from an  image processed with LR to a DNG file, and the JPEG file does not show the corp he expectss, or shows one. Or the colors are off. Or the image looks all weird when he opens in in another Adobe product, because of the LR CRS namespace or the ACR data in XMP which he may or may not wanted to copy.

Geez, don't get me started. My blood pressure has already risen to unhealthy heights by this post.

Do I want to propagate keywords (and destroy(!) the correct regions) or do I want to keep the correct regions created by Lightroom, but without propagating keywords.

Why don't you just use "Save as JPEG" in LR and let it do all the work? Why do you need to propagate metadata in IMatch after the fact? Just asking, I'm curious.

PS. The metadata you show above is as ExifTool write it, compliant to MWG as far as I can tell.

[Schmidtze]

> IMatch falls for this and rejects the face regions in your files because it cannot determine the
> unit in which the area parameters are specified.

do you mean that's why I don't see the regions in IMatch. Ok, I noticed this for myself. But if IMatch falls over this, then it shouldn't overwrite it (yes I know, I've set the option to do so)...

[Schmidtze]

>  Geez, don't get me started. My blood pressure has already risen to unhealthy heights by this post

you are joking now, don't you?

> Why do you need to propagate metadata in IMatch after the fact? Just asking, I'm curious.

Mario, are you really serious asking this? Hmm... I'm using IMatch for maintaining all the keywords, moving them in a tree structure etc. A question from me: Why did you build in this feature for propagating? Which workflows should be covered by it?

Honestly I'm really really suprised by your reaction!

To put it in a nutshell: For the user keywords have NOTHING to do with faces. On the technical side they have one common characteristic: Both are saved into the same data area called XMP. But that's not for interest for the user, it's only for interest for you, for the programmer.

I really do not understand which parts of my comments will rise your blood pressure. But of course I don't want to risk your health. So I will stop it here from my side. As I said, I'm a little bit confused now...

Regards
Friedemann

[Mario]

People want to copy titles, descriptions, copyright data, location data and usually keywords from masters to versions. All good and fair. And they don't care what metadata is, or what IPTC, EXIF, XMP are. So you say and you may be right.

So when you enable the option to copy all metadata from master to version, IMatch does that. It copies IPTC, EXIF, GPS, XMP.

But wait. Copying EXIF data can be harmful. Yet stills some users want it because they want to see the shooting data of the master also in the version. Some don't, because copying EXIF data may damage the version.

Legacy IPTC data is no more. Still, many stock photo agencies and magazines require it. So IMatch copies it when you set the "no brainer" "Copy all metadata". But gives you options to not copy it. Because some users require this.

Regions are part of XMP metadata. Faces are regions. If a user wants to copy titles, descriptions, copyright info, location data and keywords (short: Copy XMP) IMatch copies the entire XMP record. Which includes regions.

Should IMatch always skip regions when copying metadata? That would surely be wrong in many scenarios, where the version has the same size and rotation as the master - e.g. in the typical case of a JPEG or DNG version of a RAW master. In your case, copying regions is wrong. But how should IMatch know what you consider 'right' without giving you an option to turn off copying regions?

Or what about Adobe's CRS namespace (camera raw data) which is stored as part of the XMP record as well. When IMatch copies XMP, it copes the entire XMP record in the file, including all proprietary data that has been included in XMP.

But copying CRS data from one file to another can be wrong, because this data is aimed at one specific version of the file. Adding it to a DNG produced from RAW may cause the DNG look wrong, have the wrong crop data etc. So we need an option to suppress copying Adobe CRS data when copying XMP. Again, impossible without telling the user.

When you crop a RAW in LR, Adobe adds a crop record into XMP.
But when you create an already cropped version of the RAW file in JPEG format, LR copies the entire XMP record, including the crop data. But the crop data is wrong for the JPEG, because it has already been cropped! Adobe should not copy the crop record, or at least disable it.
To handle this better, we have an option to copy XMP, but disable the existing crop record.  Again, options added to IMatch because of real-life requirements.

A user who is intimidated by all this should stick to the IMatch defaults for metadata (which are MWG compliance, XMP-only) and if he really must use advanced concepts like versioning and propagation should stick to the simple "copy XMP data option".  Unless the XMP data he deals with has proprietary Adobe data, Or face regions, Or crop data which should not be copied...

[sinus]

These options come from the technical side, but the user is not interested in XMP and IPTC. He only wants to propagate ratings, labels, comments, keywords etc. (or he doesn't want to). That's all.
Best regards
Friedemann

It is quite late here in Switzerland and tomorrow I have a kind of control here in the agency from the state of Switzerland (phew, not funny, Mehrwertsteuerprüfung).

So my comment is for me the last today.
I wanted only to say, Schmidtze, this sentence of you I do not see so.
A lot of users may have the same opinion like you wrote, but also quite a lot of users are interested in XMP and IPTC - like me. I do not want only propagate, I wants know exactly what, xmp, iptc and so on.

IMatch is a DAM for different users. I know, there are users with easy workflows, and they do usually not want to "fight" with metadata, xmp, iptc, exif and so on.

But there are also photographers, agency owners, technicians or what ever, who are interested, what's about xmp, iptc and so on.

And finally theses broad line of users made IMatch so powerful, but because these users asked Mario for this and that and again this and that, and this special case, what is really important  and that ohter special case, what is of course also important ... and that is one reason, why IMatch is so mighty, has so many options ... but on the other hand these options are a mercy for some users, and a pain for others (sometimes including Mario, because he has to deal with this all).

That is why Mario often recomends using simply the MWG-stuff (default in IMatch, if I am not wrong) and that's it.

So I do not want make this thread longer with some postings about, what is common and what not, I staggered only over your comment about users, and so I had to post this, finallly, before I am going to sleep. 

[Ferdinand]

Friedemann

Long time readers of this forum will know that Mario has a couple of RAW nerves, and the issue discussed in this thread has hit one of them.  Perhaps it hit several of them.  I didn't read the reaction you encountered as being aimed at you, just that a raw nerve had been hit.  If the reaction was aimed at anyone it was Adobe.

As a long time propagator, I have sympathies with Mario's predicament.  The idea of propagation is simple enough but the devil is very much in the details.  Everyone wants something slightly different and there are a lot of gotchas hidden along the way. 

I wrote a propagation script to handle cases that IMatch couldn't, which is still on the script gallery.  Mario has enhanced propagation in IMatch 5 since I wrote it and mostly now it's redundant.  There is still one case where it's needed, and that's where you want to propagate keywords while keeping the existing keywords in the version files (which is a lot harder to do that you would expect).  It may well be that LR face tags are another case where something like this script is needed.

I've had effectively the same problem for some time with categories.  If you have categories for specific people, and you create cropped versions with some people missing, how do you deal with this when propagating categories?  I never found a way, but fortunately this was sufficiently rare that I ignored the problem and / or deleted the erroneous categories manually.

[Schmidtze]

Good morning,

A lot of users may have the same opinion like you wrote, but also quite a lot of users are interested in XMP and IPTC - like me. I do not want only propagate, I wants know exactly what, xmp, iptc and so on.

yes, and that's the point. The way it is now, you do NOT know what will be propagated, because you do not know which data is included in XMP area and you also do not know in which data area for example the faces tags are stored. I know that it is stored in XMP and you may know it also, but is it really important to know? I agree, there are several kind of users, some do only know terms like "keyword", "comment", "rating" etc., and others, like me and you, do also know terms like "XMP", "IPTC" etc. And by the way, XMP has got a completely other meaning than IPTC. To enable the option to propagate IPTC is absolutely ok, then you know (or have to know) which data will be propagated, because IPTC contains well defined specific data entries (which are also included in XMP!). IPTC is not a technical term in my opinion, it's a name for specific data. But XMP can contain ALL, it's not specified which data it includes, it can include everything! It's a standard HOW to save data, not WHAT the data include! That's a very very important difference! So telling the software simply to propagate XMP data can cause non expected results in many cases. You can't know the result because nobody knows what is stored in XMP!

If a user wants to copy titles, descriptions, copyright info, location data and keywords (short: Copy XMP) IMatch copies the entire XMP record.

and exactly this is absolutely wrong!  It's not "short: Copy XMP"! That's the point we disagree it seems. XMP cant contain keywords and IPTC can also contain keywords. If I want to be them propagated, I don't want to think about enabling IPTC (which should do the job my opinion) or enabling XMP or maybe enabling "XMP without rotation flag" etc. In my opinion it's wrong to offer the possibility to propagate "XMP" and then adding thousands of exceptions ("XMP without rotation", "XMP without faces", "XMP without crop" etc.). As you do not know which data is included (and will be included in future) in XMP data, it would be much much better to have only options for data which the user really wants to copy. I doubt about that there are many use cases where one really wants to propagate all XMP data. This option is still ok, but options for propagating specific data are much more important!

But ok, it seems we will not agree in this point. What a pity!  And of course I have to (and will) accept IMatch like it is.

Should IMatch always skip regions when copying metadata? That would surely be wrong in many scenarios, where the version has the same size and rotation as the master - e.g. in the typical case of a JPEG or DNG version of a RAW master.

I know, this is a dilemma! But as it's not clear what to do, it's not good to destroy data, it would be better to do nothing then, which means "do not copy regions".

And you are talking about the "typical case". I'm using an Olympus Micro Four Thirds camera which has got a 4:3 sensor. But usually I like the 3:2 format and so I will crop the image in Lightroom. The camera can be set up to do it automatically, but then the RAW is still 4:3 but the cropping area is already marked. So for all 3:2 MFT images, the faces areas will be wrong after handling them in IMatch.

Maybe I'm the only one who concerns about the existing propagation options. Honestly I had my problems with them from the beginning on. For example I destroyed the rotation flags in the past on thousands of images. Ok, my fault, because I didn't use the right options. But in my opinion it could be much more easier, as I said, by having options for copying specific data instead for copying all data with some exceptions. I suppose that there will be problems again and again in future, which will cost you a lot of work to support them, by answering again and again the same arguments.

I started this thread because of the unwanted propagation of faces (I don't want to say "destroying faces"). I really didn't want a debate on principles. At the moment my problem is only the propagation of the faces regions. But I hope it's ok to talk also about the behaviour in general.

Best regards
Friedemann

[Mario]

XMP cant contain keywords and IPTC can also contain keywords. If I want to be them propagated, I don't want to think about enabling IPTC (which should do the job my opinion) or enabling XMP

Yes. But here it starts already. When you say IPTC, do you mean legacy (IIM) IPTC data or the IPTCCore and IPTCExt data which is part of XMP? Or both? Do you need your versions to contain legacy IPTC data because you upload them to Flickr or a stock photo agency? Or do you don't care? Or are you not allowing to propagate legacy IPTC even if it's in the original file, but allow IPTC which is part of XMP?

So for all 3:2 MFT images, the faces areas will be wrong after handling them in IMatch.

I don't understand.
You process the files in LR and also add the face tags. So LR will add the face tags to the cropped version of image, no?
Of course when you copy region data from the uncropped origial with coordinates relative to the uncropped version to a cropped version of the file, the regions will be off. This cannot be handled by IMatch, except for the option which I already added to not propagate face data.

For all else you say in your post: Please add a feature request. If you want to be able to check each tag individually you want to propagate, add this as a FR. I can implement this more or less easy by just making the list used in the "what to propagate" longer.

[Schmidtze]

I don't understand.
You process the files in LR and also add the face tags. So LR will add the face tags to the cropped version of image, no?

yes, LR will add the face tags to the cropped versions correctly. But by now, these tags will be changed by IMatch to the tags of the master files. But maybe I didn't notice or understand correctly: You will change something now, so the faces regions will not be changed anymore? That would solve the problem 

Thanks Mario!

Best regards
Friedemann

[Mario]

As I wrote above in one of my replies, I have added two changes:

1. An option to not propagating XMP regions (analog to not propagating rating or label)

2. A work-around for the missing unit attribute LR does not write. From what I can tell from the MWG spec and what I have seen so far (e.g. Google Picasa), a region area must include X,Y,Width, Height and the unit of these measures. Adobe LR does not write the unit tag (!) so the regions they write could be measured in bananas or yards.

The current version of IMatch thus rejects these unit-less regions as invalid. The work-around I've added to the 5.4.10 now assumes that the unit is 'normalized' when no unit is given in the region. This should be safe to do. But Adobe should maybe re-read their own specification and implement it correctly.

That's was what I meant when I wrote that I had info about the regions not being standard/valid and why I wanted some sample files. IMatch does not just store the regions, it also converts them into face annotations, and for that I need a proper measurement with a unit. IMatch annotations don't support bananas...

[Schmidtze]

As I wrote above in one of my replies, I have added two changes

I didn't notice that and I can't find this now also. You wrote that you "could" do the changes. Then you complained about too many changes. That's why I didn't expect that you will do the changes. Or do I perhaps miss something?

By the way: I'm not very lucky with LR 6. There are many minor things I noticed by now which do not work as expected.

[ubacher]

Just a technical comment - just popped into my head:

Could we add to the versioning rules an optional script to run  which the user could specify.
( Probably needs the option of Run script only/before/after.)

Then, when more odd requests are made Mario could just say: Write a script to handle the situation.

[Schmidtze]

Then, when more odd requests are made

You are not talking about me, do you? 

[Carlo Didier]

Just a technical comment - just popped into my head:

Could we add to the versioning rules an optional script to run  which the user could specify.
( Probably needs the option of Run script only/before/after.)

Then, when more odd requests are made Mario could just say: Write a script to handle the situation.

Very interesting idea!