Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3
Latest posts of: hneuhaus
The DAM Forum
Welcome, Guest. Please login or register.
October 31, 2020, 08:59:58 AM

Login with username, password and session length
Search:     Advanced search
28033 Posts in 5147 Topics by 2903 Members
Latest Member: kbroch
* Home Help Search Login Register
  Show Posts
Pages: [1]
1  Software Discussions / ImageIngester and ImageVerifier / Re: Exiftool error duplicaet XMP property on: August 17, 2010, 11:48:06 AM
Ian,

thank you very much for the detailed answer.

Having read your reply, I started to track down where the two entries might come from. I was pretty sure that I hadn't applied ACR development settings at all.

It turns out, that the very new version of II I used has both entries in its XMP template (at the end of the XMP file it says where it took the template from), while the template of the previous version had only the iview-multimedia section. From your explanation ("breaking XMP rules"), this might be a bug. I guess this is what you can end up with using deliberately a version with maturity marked as "low" :-).

As a solution, I could switch back to an old II version (which I wouldn't really like) or I could adapt the new II XMP template to only contain one of these sections.

If I do so which one should I keep ?
I am neither using ExpressionMedia nor Iview, just Bridge ?

BR,
Holger
2  Software Discussions / ImageIngester and ImageVerifier / Exiftool error duplicaet XMP property on: August 16, 2010, 01:19:09 PM
Hi all,

I am currently trying to figure out how to get II and Geosetter up and running.
I am using II 3.4.10 on Windows XP SP3 and Geosetter 3.3.60 with Exiftool 8.28.

During my test runs, I ingested with II, where I did renaming and bulk metadata additions. I used some jpegs and some NEF raw files, I did not do any GPS stuff in II. Then I started Geosetter and experimented with pinpointing a location on the map, then assigning that location to, say, a NEF image.

When I hit the save-changes button, Exiftool (invoked from within Geosetter) brought up the following error message:
Code:
Duplicate XMP property: mediapro:CatalogSets/rdf:Bag/rdf:li 10 - K:/tmp/playground/test_raw_dev/ingester_out/PRV/test_raw_dev_multi/1899-1910/hnhs_090911_1908.xmp
I had a closer look at the XMP file created by II:
It seems to me that Exiftool does not like that the file had the following two entries:
Code:
<rdf:Description rdf:about=""
            xmlns:mediapro="http://ns.microsoft.com/expressionmedia/1.0/">
         <mediapro:Status></mediapro:Status>
         <mediapro:Event></mediapro:Event>
         <mediapro:People>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </mediapro:People>
         <mediapro:CatalogSets>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </mediapro:CatalogSets>
      </rdf:Description>
<rdf:Description rdf:about=""
            xmlns:mediapro="http://ns.iview-multimedia.com/mediapro/1.0/">
        <mediapro:Status></mediapro:Status>
         <mediapro:Event></mediapro:Event>
        <mediapro:People>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </mediapro:People>
       <mediapro:CatalogSets>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </mediapro:CatalogSets>
      </rdf:Description>

When I set Exiftool options to "ignore minor errors", it would update the xmp sidecar, but only one of the two mediapro sections would be in the new xmp (in fact the expressionmedia entry).

Now my question here would be:
1) Are the two mediapro sections created by II a bug or intentionally ?
2) Is there any way two keep both entries when using Geosetter ?
3) What would be the consequences of having just one left after Geosetter invocation ?

I am not really the XMP expert so I hope you can help me here.

BR,
Holger
3  Software Discussions / ImageIngester and ImageVerifier / Re: How to get the new filename into the Title field in Multi-Camera on: August 16, 2010, 01:03:24 PM
Hmmm ... to get this straight ...

Peter, I understand from your reply that you do apply metadata during first ingestion - which means that for RAW files an XMP sidecar would be created - but leave the title field blank. Then intend to fill this title field in the existing XMP sidecar on the second multicamera ingestion.

But in the User Manual V3.2 on page 45 I found:
Quote
If the image to be ingested already has a sidecar, it stays with the image, being
renamed as necessary to keep it connected with the image, and a new sidecar isnít
generated by II. II will not update an existing sidecar.
This to my mind does mean that whenever a sidecar does already exist, it is not changed at all. So not even XMP fields left blank during the first run could be updated during a second run, because existing sidecars are not touched.

Did I understand this wrong ?

BR,
Holger
4  Software Discussions / ImageIngester and ImageVerifier / Re: How to get the new filename into the Title field in Multi-Camera on: August 16, 2010, 02:20:49 AM
I am currently trying to understand how to best do multi camera import. I am not 100% sure but the issue here might simply be that II will not change an existing xmp (that is at least what I understood from the user guide). So if you ingest raw files with a "regular" first ingestion and assign them bulk metadata etc, and then reingest for multicamera ingestion II does not update the xmp it created in the first run.
A solution might be to change the suggested multicamera ingestion scheme so that in the first ingestion you do just a pure copy to camera specific folderson your hardisk - no renaming and metadata change at all. Then with the second ingestion you apply all metadata etc but launch this from the multicamera window.

BR,
Holger
5  Software Discussions / ImageIngester and ImageVerifier / IIP ACR develop settings on: October 18, 2009, 04:48:35 AM
Hi.

I hope I put this in the appropriate subforum.

Peter,

in the second edition of your DAM book, in the chapter on the "Bridge/ACR workflow" under the headline of "Apply Develop Settings", you are suggesting that when IIP is configured to apply some ACR setting during ingestion it would be ok to skip this step inside of Bridge.

However, from a bit of experimenting it seems to me that the two approaches of applying a develop setting are fundamentally different. If I figured this out correctly, IIP just adds the ACR setting content to the xmp metadata (in case of raw) while Bridge / Camera Raw add the content of the chosen settings plus it takes any setting that is not in the file from the defaults. (And these defaults may still be camera, serial and ISO specific).

In your book you point out that it does make sense to apply develop settings in order to have the conversion in a defined state no matter e.g. on which computer the files are interpreted. When applying develop settings just with IIP this seems not guaranteed since e.g. when creating thumbnails or output files, then any missing development values that were not in the applied preset will be taken from the current defaults which might be totally different on two different computers.

Now one could of course argue to just create a preset with all settings included and apply that one in IIP. This however will e.g. remove the possibility to make use of applying ISO specific denoise settings. When I create a preset e.g. with just the clarity setting increased to 50 and apply this preset in Bridge to a bunch of raw files with different ISO values then Bridge/ACR would apply the clarity 50 to all files but take the ISO specific default values for all other settings. It seems to me that this is not possible with IIP.

I hope my examples were not to confusing.

I would be very thankful if somebody could confirm my findings or maybe explain to me what I understood wrong.

BR,
Holger
6  DAM Stuff / Hardware Discussions / Re: DVD-RAM for archiving on: September 02, 2007, 09:31:26 AM
Thank you very much for pointing me there.
The article was really interesting.

BR,
Holger
7  DAM Stuff / Hardware Discussions / DVD-RAM for archiving on: August 29, 2007, 02:56:04 AM
Hi all,

I'm new to the DAM forum and have not very much experience with the DAM topic.

A while ago I tried to bring some thought to my workflow and also to the archiving aspect. My conclusion at that time was to settle on DVD-RAM as archiving media for it seemed to have some advantages especially for archiving purposes. Reading through the DAM-book, I found that DVD-RAM was not recommended there but instead rather usual DVDs. However, I failed find more information on the reasoning behind that. I tried to find some background information in this forum but had no matches with my searches (maybe I was just to stupid to set the right search terms ?).

Could you guys help me to understand the reason why to use or not to use DVD-RAM ?

Best regards,
Holger
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!