Loss of preview

[Archive]

[Originally posted by hrgold on 2005-09-26 21:41:48-07]

I am using the command line version of Exiftool on Mac OS X Tiger and it generally works great.  I need to add metadata information to many .mos files from an external data source like a tab delimited file.  Have this working fine for TIFF files and JPEGs.   The .mos files are the RAW format file from a Leaf digital back.  Exiftool writes to IPTC fine but the file no longer has a preview that shows up in an image asset program.  The .mos file before writing metadata has a preview.  Any assistance is greatly appreciated!!

[Archive]

[Originally posted by exiftool on 2005-09-27 00:41:42-07]

ExifTool writes to ".mos" files?  Cool.  I didn't know that.

Do you mean the OS X preview, or a preview that is embedded in the image?  ExifTool creates a new file when you add information, and any information that was in the resource fork of the old file isn't transferred to the new file (ie. possibly an OS X preview image).  If this is the problem, I can't fix it easily.  But if we are losing a preview that is in the original file from the Leaf, then I should be able to solve the problem but I will need a sample (you can email it to me -- my address is philharvey66 at gmail.com).

Thanks

[Archive]

[Originally posted by hrgold on 2005-09-27 03:21:47-07]

Thanks for responding so quickly.  I don't know if the preview is the OS X one, though I doubt it as there is no thumbnail in the Finder or in a directory window.  So I suspect it is a built-in preview as Photoshop CS can draw the thumbnails in the File Browser.  I am using the "-overwrite_original" parameter with my command line call, as this fits the workflow I am trying to create.  Even without this parameter the problem is the same.  The files are large- 40MB+.  I will email you directions to get one via FTP.

Thanks again.

[Archive]

[Originally posted by exiftool on 2005-09-27 15:58:30-07]

Thanks for the sample.  There is indeed a 312x234 pixel preview image embedded in this .mos file.  The .mos is basically a TIFF file (that is why ExifTool can edit it).  The preview is found inside a Leaf-specific data block which is stored as tag 0x8606 in IFD0 of the TIFF image.

I'm guessing that the software you have to display the preview image (your "image asset program") understands this Leaf-specific data and is looking for at to begin at a specific location in the file.  (Is this software Leaf-specific?)  In the original you sent, this data block starts at byte 8 in the file, but after editing with ExifTool the location of this data changes.  The data is still there, and can be accessed properly through the TIFF IFD0, but if your software is looking for it to begin at byte 8, it won't find it.

I will look at this data block in more detail to see if I can extract the information from it.  As well as the preview, it contains ICC profile information as well as some Leaf-specific information such as the back type and serial number.  I'm thinking it might be nice to be able to use ExifTool to extract this additional information including the preview image, but this still won't help the problem of the preview not showing up in your image asset program.  To fix this, the TIFF writer code in ExifTool would have to be changed to force the data for tag 0x8606 to be written at offset 8 in the file, which may not be as easy as it sounds, but I'll look into this too.

[Archive]

[Originally posted by hrgold on 2005-09-29 13:32:36-07]

Hi

Just thought I would check and see if you had any more news for me.  Still have not heard back from the asset management database company either.  Will keep you in the loop.  Again, thanks for your help.

[Archive]

[Originally posted by exiftool on 2005-09-29 15:34:21-07]

Thanks for checking back.  I have been working on this.

I have managed to extract much of the Leaf information, including the preview.  The 5.64 pre-release now includes this update if you want to test it out.  There is a LOT of new Leaf-specific information that is now extracted.  I want to tidy up the code a bit before releasing this officially, so if you have any feedback let me know.

I am currently working on modifying the code to write the Leaf information at the start of the file because I think this will make it compatible with your asset management software, but haven't found a clean way to do this yet.  I'll keep working on it though, and I'll post here if I make any progress.

[Archive]

[Originally posted by exiftool on 2005-09-30 00:30:18-07]

I've done it.  ExifTool now writes the Leaf data to the start of the file.  I've updated the 5.64 pre-release with the new version.  Could you test it out to see if your image asset software can read the Leaf information now?  With any luck, this will solve the problem.  If so, you should be able to rewrite one of the files that was causing problems for your image asset software to make it work again.

[Archive]

[Originally posted by hrgold on 2005-10-01 03:43:12-07]

Tested the new version and oddly, the first time it worked fine for two out of three images.  I then started with fresh images and it did not work at all.  Very strange.  The asset database is MediaBeacon R3volution.  I am also speaking with the tech support at the company.  iView MediaPro, another asset database seems to work fine.  R3volution is network based and higher end and would suit the purposes of my client much better.

[Archive]

[Originally posted by exiftool on 2005-10-01 12:47:47-07]

OK, so the obvious solution wasn't the answer.  I'll take a closer look at the MOS format to see if I can come up with any other ideas.

[Archive]

[Originally posted by exiftool on 2005-10-02 01:56:57-07]

I did find something else by looking closely at the MOS sample you provided.  There is a Leaf-specific sub-IFD in that ExifTool was not copying to the new file.  (This sub-IFD is not part of the TIFF specification, and is actually written using an incorrect format code!)  Missing this IFD could possibly have caused problems for Leaf-savvy readers.  I have verified that all the rest of the data in the original file is getting copied over properly.

I've prepared a pre-release of version 5.65 which properly copies this Leaf sub-IFD.

I'm hoping this solves the problem, because otherwise the only differences I can see are the locations where individual data records are stored.  I was willing to concede the position of the first record in the file because it is not unreasonable that some software would look there for a quick-and-dirty extraction of information, but I have no sympathy for software that isn't properly using the IFD's to reference the remaining records.