Bug #1148

XMP Rights field padded with spaces

Added by John Huggins almost 2 years ago. Updated almost 2 years ago.

Status:ClosedStart date:08 Jan 2016
Priority:NormalDue date:
Assignee:Robin Mills% Done:

100%

Category:xmpEstimated time:10.00 hours
Target version:0.26

Description

I have a jpg file 2014-2.jpg (attached) where the XMP "Rights" value is

<dc:rights>
<rdf:Alt>
<rdf:li xml:lang="x-default">2014 John Scot Huggins, All Rights Reserved</rdf:li>
</rdf:Alt>
</dc:rights>

If I run exiv2 -pa 2014-2.jpg I get this in the relevant line (some spaces removed for clarity)...

Xmp.dc.rights   LangAlt 1 lang="x-default" 2014 John Scot Huggins, All Rights Reserved

Great.

If I run exiv2 -ex 2014-2.jpg I find this in the 2014-2.exv file...

&lt;dc:rights&gt; &lt;rdf:Alt&gt; &lt;rdf:li xml:lang="x-default"&gt;2014 John Scot Huggins, All Rights Reserved&lt;/rdf:li&gt; &lt;/rdf:Alt&gt; &lt;/dc:rights&gt;

Also great.

If I run exiv2 -eX 2014-2.jpg I find this in the 2014-2.xmp file (some spaces removed)...

&lt;dc:rights&gt;
&lt;rdf:Alt&gt;
&lt;rdf:li xml:lang="x-default"&gt; &lt;/rdf:li&gt;
&lt;/rdf:Alt&gt;
&lt;/dc:rights&gt;

...but not the spaces between the li tags which seem to be spaced padding for what should be the copyright message.

All the other fields appear to be moving through the translations fine, but the one containing copyright information from the original embedded XML tag seems to have turned to spaces.

Might I be doing something wrong?

I am using 0.25 on Ubuntu, compiled from fresh source, but the older 0.19 version that came with my install of Ubuntu does the same thing.

2014-2.jpg - Picture with the XMP in question (7.7 MB) John Huggins, 08 Jan 2016 02:07

phst.png - Desired workflow flowchart (145 KB) John Huggins, 08 Jan 2016 15:19


Related issues

Related to Exiv2 - Feature #1057: Implement target/modifier - (stdin/stdout) for exiv2 opti... Closed 17 Apr 2015

Associated revisions

Revision 4174
Added by Robin Mills almost 2 years ago

#1148. Fixed formatting error in jpgimage/-pS code.

Revision 4175
Added by Robin Mills almost 2 years ago

#1148 Fixed Todo: Should use XMP packet if there are no XMP modification commands

Revision 4176
Added by Robin Mills almost 2 years ago

#1148 Correction to r4175 to fix test suite breaker. We can only use the -pX short cut when option -eXx is used.

Revision 4220
Added by Robin Mills over 1 year ago

#1057, #1064, #922, #1148. Work in progress. This is a composite patch of several matters in development. None are totally complete at this time.

History

#1 Updated by John Huggins almost 2 years ago

Obviously I didn't format the carets correctly, but the problem is reasonably apparent even with the lt gt stuff. Sorry about that.

#2 Updated by Robin Mills almost 2 years ago

  • Status changed from New to Assigned
  • Assignee set to Robin Mills
  • Priority changed from High to Normal
  • Target version set to 0.26

John

Can I ask you to fix the carets to help me understand the issue. Can I also ask you to use -pX which extracts the XMP from the image. -pX is "raw". It locates the XMP and copies it to stdout verbatim.

#3 Updated by Robin Mills almost 2 years ago

I have a jpg file 2014-2.jpg (attached) where the XMP "Rights" value is:

<dc:rights>
<rdf:Alt>
  <rdf:li xml:lang="x-default">2014 John Scot Huggins, All Rights Reserved</rdf:li>
</rdf:Alt>
</dc:rights>
If I run exiv2 -pa 2014-2.jpg I get this in the relevant line (some spaces removed for clarity)...

Xmp.dc.rights   LangAlt 1 lang="x-default" 2014 John Scot Huggins, All Rights Reserved

Great. If I run exiv2 -ex 2014-2.jpg I find this in the 2014-2.exv file...

 <dc:rights> <rdf:Alt> <rdf:li xml:lang="x-default">2014 John Scot Huggins, All Rights Reserved</rdf:li> </rdf:Alt> </dc:rights>
Also great. If I run exiv2 -eX 2014-2.jpg I find this in the 2014-2.xmp file (some spaces removed)...
<dc:rights>
   <rdf:Alt>
    <rdf:li xml:lang="x-default">                                                      </rdf:li>
   </rdf:Alt>
  </dc:rights>
...but not the spaces between the li tags which seem to be spaced padding for what should be the copyright message.

All the other fields appear to be moving through the translations fine, but the one containing copyright information from the original embedded XML tag seems to have turned to spaces. Might I be doing something wrong?

I am using 0.25 on Ubuntu, compiled from fresh source, but the older 0.19 version that came with my install of Ubuntu does the same thing.

#4 Updated by Robin Mills almost 2 years ago

  • % Done changed from 0 to 10
  • Estimated time set to 10.00

I may discuss this with Alan Pater, our XMP Engineer, as I'm wondering if the xml lang="x-default" is somehow implicated. I'm surprised by this behaviour and instantly think bug. I'll have to crawl through the code to see what's going on. Let's ignore -pa as you are happy with that. Here's my way of looking at this in pure XML.

1) Extract and reformat the 'raw' XML:

$ exiv2 -pX ~/Downloads/2014-2.jpg | xmllint --pretty 1 - > ~/temp/raw.xmp
2) Extract XML with -eX:
$ exiv2 -eX --force --verbose ~/Downloads/2014-2.jpg ; xmllint --pretty 1 ~/Downloads/2014-2.xmp > ~/temp/eX.xmp
They are not the same!
$ ls -alt ~/temp/*.xmp
-rw-r--r--+ 1 rmills  staff  4854  8 Jan 11:09 /Users/rmills/temp/eX.xmp
-rw-r--r--+ 1 rmills  staff  4178  8 Jan 10:56 /Users/rmills/temp/raw.xmp
$ 
3) Extract the Xmp section from the image into a .exv, and then extract the XML from the .exv:
$ exiv2 -ex --force --verbose ~/Downloads/2014-2.jpg 
File 1/1: /Users/rmills/Downloads/2014-2.jpg
Writing XMP data from /Users/rmills/Downloads/2014-2.jpg to /Users/rmills/Downloads/2014-2.exv
$ exiv2 -pX ~/Downloads/2014-2.exv | xmllint --pretty 1 - > ~/temp/exv.xmp
$ ls -alt ~/temp/*.xmp
-rw-r--r--+ 1 rmills  staff  3332  8 Jan 11:15 /Users/rmills/temp/exv.xmp
-rw-r--r--+ 1 rmills  staff  4854  8 Jan 11:09 /Users/rmills/temp/eX.xmp
-rw-r--r--+ 1 rmills  staff  4178  8 Jan 10:56 /Users/rmills/temp/raw.xmp
$ 
Oh dear, different again. There's something to investigate here.

I'm very familiar with -pX because I wrote it! I was a little surprised that it worked on the .exv file, because -pX is documented to only work on JPG, TIFF and PNG. So, I inspected the structure of the .exv file with -pS:

$ exiv2 -pS ~/Downloads/2014-2.exv
STRUCTURE OF JPEG FILE: /Users/rmills/Downloads/2014-2.exv
 address | marker     | length  | data
       2 | 0x1        |       0 
       9 | 0xe1 APP1  |    5000 | http://ns.adobe.com/xap/1.0/.<?x
    5011 | 0xd9 EOI  
$ 
Ah yes, a .exv file is a JPG with no image - only metadata. Good.

However, I didn't write -eX (extract to .xmp) or -ex (extract xmp to .exv), so I will to have to investigate. The quick fix it to re-engineer the -eX and -ex code to use -pX. However, I'm going to investigate how/why the three extracts are different and believe the XMPsdk which is compiled into exiv2 is responsible. With -pX, the XMP is extracted directly from the image file without using XMPsdk. For both -ex and -eX, the XMP is fed to XMPsdk and subsequently extracted. When this happens, namespaces may be correctly added/removed and the formatting may be quite different. For example, the ordering of xml attributes can be different. However, the integrity of your data should be perfect.

There is an English-English expression Great Scott which is something like Eureka (a reference to Scott of Antarctic, I believe). When I use the command "grep Scott" on the xmp files, I get:

$ grep Scot ~/temp/*.xmp
/Users/rmills/temp/eX.xmp:    <rdf:Description xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/" 
...
exif:SubjectDistanceRange="0" exif:GPSVersionID="2.3.0.0">
/Users/rmills/temp/eX.xmp:          <rdf:li>John Scott Huggins</rdf:li>

/Users/rmills/temp/exv.xmp:    <rdf:Description xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/" 
...
...
MicrosoftPhoto:Rating="99">
/Users/rmills/temp/exv.xmp:          <rdf:li>John Scott Huggins</rdf:li>
/Users/rmills/temp/exv.xmp:          <rdf:li xml:lang="x-default">2014 John Scot Huggins, All Rights Reserved</rdf:li>

/Users/rmills/temp/raw.xmp:      <photoshop:Credit>John Scott Huggins</photoshop:Credit>
/Users/rmills/temp/raw.xmp:      <photoshop:CaptionWriter>John Scott Huggins</photoshop:CaptionWriter>
/Users/rmills/temp/raw.xmp:          <rdf:li>John Scott Huggins</rdf:li>
/Users/rmills/temp/raw.xmp:          <rdf:li xml:lang="x-default">2014 John Scot Huggins, All Rights Reserved</rdf:li>
$
Incidentally, I'm surprised to see that your name is occasionally spelt Scot and mostly Scott.

You'll be aware that I set the priority of this issue to "Normal" as I usually deal with issues within a couple of days. If you urgently need a fix, I can easily modify the code for -eX and -ex to use -pX and thereby all three versions will be identical and free of artefacts from XMPsdk. However as this issue has been in the code for years, it doesn't feel urgent to me and I would prefer to investigate why they are different and then decide on a remedy. If you have a very urgent need to have this fixed, please let me know.

#5 Updated by John Huggins almost 2 years ago

Thanks for the attention gents. My middle name is actually Scott, but I changed the spelling to 'Scot' only in the XMP sidecar file for the "Copyright" value managed by Photo Mechanic in my photo archive to help track what is going where.

To get a sense of the desired workflow, see attached phst.png. The online photo system upload procedure (with the yellow background) has a convenient two step process during the picture upload process. The image files are in limbo between upload and actual importation into the photo archive. As the online photo system thus far only understands IPTC, but everything else in my process is comfortably in the XMP camp, I am using the limbo step to perform a little meta tag manipulation (with green background) before the final importation process.

Really the whole goal here is to get what Photo Mechanic manages as the term "Copyright" in its meta information management system to be the thing that shows up on the web site under the term "Copyright." I almost have this working well, but, of course, the one bug I find is with the value copyright in the XMP context.

Thanks for your help.

John

#6 Updated by Robin Mills almost 2 years ago

John

Your message arrived when I was about push 'Submit'. I read'll your message (and look at your drawing) in a moment.


OK. A bit more analysis:

1) Extract the 'raw' XML and inspect it:

$ exiv2 -pX 2014-2.jpg | xmllint --pretty 1 -
The xml is good with 43 bytes:
      <dc:rights>
        <rdf:Alt>
          <rdf:li xml:lang="x-default">2014 John Scot Huggins, All Rights Reserved</rdf:li>
        </rdf:Alt>
      </dc:rights>
2) Extract with -eX and inspect it:
$ exiv2 -eX --force --verbose 2014-2.jpg  
File 1/1: 2014-2.jpg
Writing Exif data from 2014-2.jpg to ./2014-2.xmp
Writing XMP data from 2014-2.jpg to ./2014-2.xmp
$
The XML is bad with 37 bytes:
    <dc:rights>
    <rdf:Alt>
     <rdf:li xml:lang="x-default">                                                      </rdf:li>
    </rdf:Alt>
   </dc:rights>
3) Extract with -ex (or -ea) to .exv, extract the XML from .exv with -pX:
$ exiv2 -ex --force --verbose 2014-2.jpg
File 1/1: 2014-2.jpg
Writing XMP data from 2014-2.jpg to ./2014-2.exv
$ exiv2 -pX 2014-2.exv | xmllint --pretty 1 -
The xml is good with 43 bytes:
      <dc:rights>
        <rdf:Alt>
          <rdf:li xml:lang="x-default">2014 John Scot Huggins, All Rights Reserved</rdf:li>
        </rdf:Alt>
      </dc:rights>

Conclusions:

We are on the same page. We agree that:

1) Something is wrong with -eX that is causing the copyright to be blanked.
2) The data was successfully read from the image into XMPsdk, because it's being correctly presented by -pa :

$ exiv2 -pa 2014-2.jpg  | grep John
Exif.Image.Artist                            Ascii      19  John Scott Huggins
Xmp.photoshop.Credit                         XmpText    18  John Scott Huggins
Xmp.photoshop.CaptionWriter                  XmpText    18  John Scott Huggins
Xmp.dc.creator                               XmpSeq      1  John Scott Huggins
Xmp.dc.rights                                LangAlt     1  lang="x-default" 2014 John Scot Huggins, All Rights Reserved
$ 
It's curious that the blank string is a different length from the good string!

I'll now focus my attention on -eX. I hope I can find and fix this today. I don't think I've ever worked in that part of the code, so wish me luck!

#7 Updated by Robin Mills almost 2 years ago

Thanks for the drawing. Very nice. I can more or less follow your plot and see where exiv2 fits into the scheme of things.

There's a rule in life which English people call "jam side downwards". If a slice of bread and jam slips off the table, it will always land on the jam side to ensure the maximum mess. It might even land on the dog!

In your case, the most important metadata element is what Photo Mechanic calls "Copyright" which is XMP:

<dc:rights> .... </dc:rights>
which is (of course) field that appears to be broken when you use exiv2 -eX

You now have two work-arounds - itemised above as (1) exiv2 -pX and (3) exiv2 -ex I will investigate (2) exiv2 -eX and let you know what I discover (and hopefully fix).

I think you'll find that (1) exiv2 -pX is a good solution as the XMP/xml can be piped directly from the image to any file of your choosing. When you use exiv2 -ex and exiv2 -eX, there is an intermediate file which may (or may not) be convenient.


Incidentally, there is a feature to be added in v0.26 to redirect extract/import data to/from stdout/stdin #1074. I haven't implemented this yet, however it's intended to work as follows:

$ exiv2 -eX- foo.jpg
will not write to foo.xmp, instead it will write to stdout. And a command such as:
$ exiv2 -iX- foo.jpg
will not import from foo.xmp, instead it will read from stdin. My intended use case for this is to selectively copy metadata from one image to another. For example, to copy the ICC profile from one image to another, the command will be:
$ exiv2 -eC- foo.jpg | exiv2 -iC- another.tiff
The command to copy the ICC profile from one image to many images will be the following beautiful and elegant command:
$ exiv2 -eC- foo.jpg | exiv2 -iCi a.tiff b.png c.jpg ...

Thank You for using Exiv2.

#8 Updated by John Huggins almost 2 years ago

The stdin/stdout capability is precisely what I was hoping for. Not finding an way to do this at the moment, I do the steps in the green box of my flow chart using bash managing a temporary 2014-2.xmp file. Right now I just copy the 2014-2.xmp to several files matching the derivative file names and then use exiv2 to insert data into each with full control of what each file gets with an exiv2 command with specific options for each. A little clunky, but then again bash makes this a reasonable process.

While the stdin/stdout aspect is certainly the way to go, I need to be sure the appropriate 'translation' occurs when writing XMP data to both XMP and IPTC of the original file. I think I read in the docs when using the .xmp file as source, a proper translation to IPTC occurs when adding to a file.

#9 Updated by Alan Pater almost 2 years ago

Looks like you guys have got it figured out for the most part!

I'll just step in and ask if a request has been submitted to PhotoStore asking them to follow the MWG guidelines?

http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf#page=42

#10 Updated by Robin Mills almost 2 years ago

I really like bash. The syntax is ugly because bash scripting was layered on top of the unix command shell. However it is polished, robust and omni-present tool. Every Engineer should learn bash thoroughly.

Alan Pater is our XMP Engineer. Alan's not a C++ guy, he's a work-flow/metadata Engineer and understands the mysterious IPTC<->Exif<->XMP conversions. He has something very big and important happening in his life/business, so let's only consult him when/if we are stuck.

Alan: I've just realised that you've been reading this. Thanks for getting involved. I think we'll get this one fixed today.

#11 Updated by John Huggins almost 2 years ago

Alan Pater wrote:

Looks like you guys have got it figured out for the most part!

I'll just step in and ask if a request has been submitted to PhotoStore asking them to follow the MWG guidelines?

http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf#page=42

Thanks much for this. I should try to follow this standard myself to make sure my goals are not unrealistic and because standards are "good." A request to read XMP has been forwarded to Ktools, but I'm glad to see someone made a document with solid suggestions on how to survive in the new age, especially when more than one format (IPTC, XML, etc.) exist at the same moment within an image. It's like the old saying... If you have one clock, you know what time it is, where if you have more than one, you are never sure.

In Ktools' defense, I did find some commented out XML parsing code in their files that is clearly a hint of the future of decoding XMP directly so I know they have been thinking about it. Photostore is a pretty old program (2004 or so birth), but is still in development... and precisely what I desire in a stock photo online presence.

In more defense of Ktools Photostore, I will say despite their inability to handle XMP natively (for whatever reason - probably just haven't caught up with the modern ways), they have a large body of well polished PHP code that works astonishingly well. Thus the reason I'm bothering to iron out a few wrinkles (based on my own personal requirements) with the back-end scripting with exiv2. It's kind of amazing they left this nice processing-gap between upload and import providing the opportunity to tweak the files. Life doesn't usually work that way.

In the end, I hope to have a solution that allows me to tag my main archive just once, and only once, with my preferred tools, and have that data flow to various targets automatically. Thanks to exiv2 and this bug tracking system, I am likely less than a week away from meta data nirvana... until the standards change again of course... or I, knowing my luck thus far, stumble on a bug in bash or something :|

Cheers

#12 Updated by Robin Mills almost 2 years ago

John

It's been a long day. It's 8:23pm here in England. We're building/remodelling our house and I've had to spend quite a lot of time on that today. Time for some beer. I'll continue on your issue tomorrow. http://clanmills.com/Homepages/2015/Christmas.shtml

You might find a bug in bash. I'll be surprised. I recently found a bug in grep. Unbelievable - but true. #1105 http://dev.exiv2.org/issues/1105

Standards are a good thing. However the computer industry prefers competition. Why do we need Exif, XMP, IPTC, ICC and on and on. Oh, ascii data representation: XML and JSON. Unix shells - bash, csh, ksh. Data containers: TIFF, PDF and many others. The fattest book on my book shelf is "Graphics File Formats" - 1500 pages of duplication, quirkiness and overlapping nonsense. As the saying goes "I love Standards - there are so many to choose from!".

In the Exiv2 project, our aim is to provide a "one stop shop for metadata". We have XMP/IPTC/Exif under one roof on Mac/Linux/Windows. We're adding some ICC and PDF support in v0.26. If the engineers from Adobe, Apple, Google and Microsoft joined Exiv2, we could have a wonderful metadata engine. We could all do less work and achieve more!

#13 Updated by Robin Mills almost 2 years ago

  • % Done changed from 10 to 50

#14 Updated by Robin Mills almost 2 years ago

  • % Done changed from 50 to 60

John

Mostly good news. I've got a partial fix (explained below).

I read your original email to Andreas about the server being down and you said something about:

While trying to find out if I can apply the meta information from a
single template XML file to several jpg images with noncorresponding
file names ...

Are you aware of the -mfilename syntax? This enables you to use a file to store commands. So, if you have a file "template.cmd" with your copyright notice, you could apply it to every tiff in a directory with:

$ exiv2 -mtemplate.cmd *.tiff
To every file in a tree:
$ find . -name "*.tiff" -exec exiv2 -m{$PWD}/template.cmd {} \;

I recently modified:-mfilename to respect -m- meaning stdin And added option -pV which is almost identical to -pv and adds 'set ' in front. http://dev.exiv2.org/boards/3/topics/2329 and #1137 You could use this to extract metadata from a file and push it to another. In the discussion with Nick (the user in that discussion), he wanted to copy GPS data and here's the example that is now in our test suite:

$ exiv2 -PkV --grep GPSL http://dev.exiv2.org/attachments/download/805/DSC_7154.jpg | exiv2 -m- foo.jpg

You might find those features useful on your journey to Metadata Nirvana wherever that might be ! Be sure to send me a Post Card when you get there as I'm due a vacation to celebrate my 65th birthday on Monday week (January 18). I'm pinned down with the construction project at home.


Partial Fix submitted: r4175. Would you believe it, there was a comment in the code:

//Todo: Should use XMP packet if there are no XMP modification commands
So, I changed that to:
            // #1148 use XMP packet if there are no XMP modification commands
            if ( Params::instance().modifyCmds_.size() == 0 ) {
                // http://www.cplusplus.com/reference/ostream/ostream/ostream/
                std::filebuf fb;
                fb.open (target,std::ios::out);
                std::ostream os(&fb);
                sourceImage->printStructure(os,Exiv2::kpsXMP);
                fb.close();
                return 0;
            } else {
                targetImage->setXmpData(sourceImage->xmpData());
            }
And that makes good on my promise above:

The quick fix is to re-engineer the -eX code to use -pX

However, I'm not done for a couple of reasons:

1) The test suite has thrown lots of exceptions which I will have to investigate
Most will be the format of the code in the side-car
However there are messages about "Exiv2 exception in insert action". Ummm. Got to investigate, although I'm almost certain I know what has caused that and how to fix it. Hopefully that will be cleaned up this morning.

2) This fix doesn't address the issue that <dc:rights>...<dc:rights>has been blanked out. This fix does not change -eX when there are modification commands in addition to -eX.

#15 Updated by Robin Mills almost 2 years ago

  • % Done changed from 60 to 80

First the Good News: I've fixed the test suite: r4176.

Even Better News: I know why the copyright is being blanked out. You have it in the Exif and Xmp metadata:

599 rmills@rmillsmbp:~/gnu/exiv2/trunk $ exiv2 -pa --grep right/i 2014-2.jpg 
Exif.Image.Copyright                         Ascii      55                                                        
Exif.NikonPc.Brightness                      Byte        1  Normal
Xmp.xmpRights.Marked                         XmpText     4  True
Xmp.xmpRights.WebStatement                   XmpText    27  http://huggins.photography/
Xmp.xmpRights.UsageTerms                     LangAlt     1  lang="x-default" For consideration only, no reproduction without prior permission.
Xmp.dc.rights                                LangAlt     1  lang="x-default" 2014 John Scot Huggins, All Rights Reserved
$ 
When you open that file, the library populates the XMPsdk from the file. Then, it performs mysterious conversions. Exif.Image.Copyright -> dc:rights. Then you write out a side car with the blanks. The fix is to remove Exif.Image.Copyright and all will be well.
$ exiv2 -M'del Exif.Image.Copyright' foo.jpg; exiv2 -eXx foo.jpg

And now a little unhappy news: We cannot only use the code in $ exiv2 -pX foo.jpg as a substitute for the command:

$ exiv2 -eXx file ...
And the reason is documented in man (1) exiv2. The -eX option says:
X  :  Insert  metadata  from an XMP sidecar file <file>.xmp. The
      remaining insert targets determine what metadata to insert  from
      the  sidecar  file.  Possible  are  Exif,  IPTC  and XMP and the
      default is all of these. Note that the inserted  XMP  properties
      include those converted to Exif and IPTC.
Worse we cannot use the -pX code an alternative to -eXx.

The -pX code reads the XMP directly from the image.
The -eXx code reads the XMP and the Exif and IPTC data from the image. Does various conversions IPTC->XMP and Exif->XMP. Then it writes a XMP sidecar which contains all those conversions.

To avoid all this Exif/IPTC conversion code, I will a new tgt modifier X, so the command:

$ exiv2 -eXX
Will extract the raw XMP from the image and write it to the sidecar. I'm going to have lunch and go the movies this afternoon with my wife. I'll add the -eXX option this evening and we're done on this one.

#16 Updated by John Huggins almost 2 years ago

Understood on all counts. Thanks for your time.

#17 Updated by John Huggins almost 2 years ago

Some success to report given all I've learned on this thread. This script...

#!/bin/bash

# obtain XML meta tags from primary imaage and store in .xmp sidecar file
/usr/local/bin/exiv2 -pX $1.jpg > $1.xmp

# copy the xmp file to the derivative file root names.xmp
cp $1.xmp icon_$1.xmp
cp $1.xmp sample_$1.xmp
cp $1.xmp thumb_$1.xmp

# strip the tags from the primary and derivative images
/usr/local/bin/exiv2 -d a $1.jpg
/usr/local/bin/exiv2 -d a icon_$1.jpg
/usr/local/bin/exiv2 -d a sample_$1.jpg
/usr/local/bin/exiv2 -d a thumb_$1.jpg

# insert XML back into primary image along with the IPTC for Ktools to use
/usr/local/bin/exiv2 -iixX $1.jpg

# insert only XML into the derivative images
/usr/local/bin/exiv2 -ixX icon_$1.jpg
/usr/local/bin/exiv2 -ixX sample_$1.jpg
/usr/local/bin/exiv2 -ixX thumb_$1.jpg

# delet the xmp sidecar files
rm *$1.xmp

...is now performing my goals quite well as can be seen in the final (temporary) web display of this handsome beast...

http://huggins.photography/media.details.php?mediaID=104

The appropriate data is stored in the Photostore database and the various derivative images are tagged precisely the way I want them to be. The only caveat is the original image has both IPTC and XMP data (just so Photostore can read them), but now they are totally in sync (with IPTC a copy of the primary XMP data).

So the meat and potatoes works. Now I just have to figure out how to get Photostore to run the script after upload, but that's not a problem with exiv2.

There are probably 100 better ways of doing this, but it's nice to have something that works.

#18 Updated by Robin Mills almost 2 years ago

This is good news. Well done, John. There's more than one way to do anything. And for sure, getting code to work is step 1 in a process of refinement. For example, I'd use loops to shorten your code. Something like:

for i in "$1.jpg" "icon_$1.jpg" "sample_$1.jpg" "thumb_$1.jpg"; do
    /usr/local/bin/exiv2 -d a "$i" 
done

Here's the bill for help you have been given. I'd like you to visit OpenHub.net and register (it's free).
On the Exiv2 page, click I use this. Give the Exiv2 project a great rating and/or a review and/or give me kudos.

Exiv2: https://www.openhub.net/p/exiv2
Clanmills: https://www.openhub.net/p/exiv2/contributors/60065117754297

I'm not going to submit the code for -eXX today. I've written it and surprised that it is more complicated than expected. It's 9:51pm. I'll sleep on this and do something about it tomorrow.

I'm not sure I understand why you have to run code on Photostore. Does their uploader remove metadata? Anyway, if it's not the concern of exiv2, I don't need to know.

#19 Updated by John Huggins almost 2 years ago

Robin Mills wrote:

Here's the bill for help you have been given. I'd like you to visit OpenHub.net and register (it's free).
On the Exiv2 page, click I use this. Give the Exiv2 project a great rating and/or a review and/or give me kudos.

Exiv2: https://www.openhub.net/p/exiv2
Clanmills: https://www.openhub.net/p/exiv2/contributors/60065117754297

Will do as soon as I figure out a way to get an account without verification via phone or github.

I'm not going to submit the code for -eXX today. I've written it and surprised that it is more complicated than expected. It's 9:51pm. I'll sleep on this and do something about it tomorrow.

I'm not sure I understand why you have to run code on Photostore. Does their uploader remove metadata? Anyway, if it's not the concern of exiv2, I don't need to know.

The photostore upload process leaves the original file intact, but does strip metadata from the three derivative files it generates for thumbs, samples, etc. The second step of the process is to import them into the gallery structure. It is here the meta tags in the original file are examined to populate the details of the photo. As of today, it appears photostore only reads IPTC. With the exiv2 script I have now, my orginal and the derivative images are tagged with XMP and have IPTC copy added to the original file (just so photostore gets the information into its database.

Convoluted? Yes. Ideal? No, but it seems to work.

John

#20 Updated by Robin Mills almost 2 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 80 to 100

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux