Reading and Writing RSRC fork on MacOSX

[Archive]

[Originally posted by msbc on 2006-06-08 08:57:16-07]

Phil,

It's my understanding that ExifTool does not read/write IPTC data stored in the RSRC fork of images on MacOSX? I use iView MediaPro for my DAM and it writes IPTC data to the RSRC fork for RAW files e.g. CR2. Any chance this functionality could be added - maybe via a switch to indicate using the RSRC fork instead of the data fork?

Thanks,
Mark

[Archive]

[Originally posted by exiftool on 2006-06-08 11:25:10-07]

Hi Mark,

You are correct.  ExifTool does not process the resource fork.

If there was some way to do this using standard Perl, I would do it.  But as far as I know, resource forks can not be accessed via any of the standard Perl modules.

So at a minimum, the user would likely be required to install additional libraries to enable this functionality.  I have spent a bit of time looking for how to do this, and haven't yet found a solution.  I'll do some more looking though.

- Phil

[Archive]

[Originally posted by msbc on 2006-06-08 12:15:58-07]

Phil,

Have you looked at http://search.cpan.org/dist/MacOSX-File/" target="_blank">http://search.cpan.org/dist/MacOSX-File/

Mark

[Archive]

[Originally posted by exiftool on 2006-06-08 12:56:00-07]

I hadn't looked at this module, but I don't think it does what we need. (ie. allow access to resource fork data)

The Mac::Carbon module may be able to do this, but not in a simple way (it just provides access to the old toolbox routines).  Besides, a native OSX solution would be preferable because with Apple's track record, they could drop Carbon support at any time.

[Archive]

[Originally posted by msbc on 2006-06-17 01:35:00-07]

Phil,

iView have just released 3.1.1 of MediaPro which now writes to the data fork for CR2, NEF and DCR formats. So, RSRC reading and writing would olny be needed for CRW.

I did notice in the version history that ExifTool build 6.21 "Changed CR2 identification logic to properly identify CR2 images which have been edited by PhotoMechanic". Is this something you would look at also to handle iView 3.1.1 annotated CR2s?

I'd be interested in any info you can provide around the 'safety' of using both iView and ExifTool interchangably to edit CR2 images.

Thanks,

Mark

[Archive]

[Originally posted by exiftool on 2006-06-17 10:39:54-07]

I need a sample image which has been edited with iView to comment on this.  CR2 is TIFF-based, and if iView is using the standard TIFF method of adding information then there is no problem.  Utilities which do things like adding proprietary-format information to the end of the file cause headaches.  (This is how Canon's own DPP stores information.)

The conflict with PhotoMechanic was simply that it moved the main TIFF IFD to the end of the file.  It was using the standard TIFF format, but ExifTool was using the IFD location as part of the logic to identify a CR2 image.  I have since relaxed this constraint, and now only test the 4-byte "magic number" in the header of the file.  The problem is that if the image isn't properly identified and is edited as a standard TIFF, there are 2 pieces of information that are lost: 1) The 4-byte CR2 "magic number" in the header, and 2) the DPP trailer if edited by Canon's utilities.

BTW.  What version of OS X are you running?  Is there still a problem with the Apple utilities reading CR2 images that have been edited by ExifTool?  I have heard a rumour that Apple fixed this, but I would like to know for sure.  I'm stuck on 10.3.9 so I can't test this myself.