Problem copying tags

[Jossie]

Hello,

for a long time I used a macro, which invokes EXIFtool without problems but now suddenly it does no longer work. It boils down to the fact that tags are no longer deleted / copied as was the case previously.

Just in brief, what I am doing:

I have TIF files from my scanner, which come with two or three images (full resolution, optional reduced resolution, and transparency mask). I use imagemagick to separate these images into separate TIF files. Then I use imageJ to optimize the transparency mask. Finally I use imagemagick again to re-assemble the images as they were before to be treated by the scanner software. Then I use the following EXIFtool commands to restore the original tags in the new output file to "fool" the scanner software in order not to detect my manipulation of the transparency mask:

Code Select Expand


   exiftool -overwrite_original -all:all= output.tif
   exiftool -overwrite_original -tagsfromfile input.tif -all:all -icc_profile output.tif
   exiftool -overwrite_original output.tif -ifd0:subfiletype="Full-resolution Image" -ifd1:subfiletype="Transparency mask" -ifd0:ImageHistory="Test"


However, as I said, this worked previously, but no longer. The outputfile can no longer be processed with the scanner software, as used to be the case some time ago. I append two textfiles, created with EXIFtoolGUI  with the tags of the input and the output file for comparison.

What is going on / what am I doing wrong here?

Many thanks in advance for every hint!

Hermann-Josef

[StarGeek]

I see you're using the newest version of exiftool.  Do you know the version that you previous used when it still worked?  Did you also update ImageMagick?  If so, what version were you using and are now using?

What is the name of the scanner software that you're using?

From my quick reading of your text files (differences via DiffChecker), I see that the file has become a multi-page tiff.  Also some of the tags that were binary data now are not.  All the tags that exiftool can copy are copied, but many of the tags that are different are related to the format of the TIF file, not metadata that can be copied.

If you go back to an earlier version of exiftool, are you able to get it to work?  If you need to download an older version, the link is https://exiftool.org/exiftool-11.65.zip  Just replace 11.65 with an older version number.  It's always in the ##.## format.

If reverting to an older version works, then the problem might be something in exiftool and Phil can take a look at it.  But he's currently on vacation until late September, so it will be a while.  If you can post the above info and especially if you could post and example scan, say, a 100x100 pixel quick scan with before and after processing versions, that would be very helpful.

I'd suggest hitting the "Notify" button in the upper right corner of the page in order to get an email when there's a response.

[Jossie]

Thanks for the fast reply!

I had not updated EXIFtool for quite a while and did so only before posting my problem. I found some older processed files, which worked to compare the tags that were then copied successfully. I attach the file here for comparison. Please note that the EXIFtool version specified there is not the version used to create the file but the one for extracting the metadata now.

I had noted that some binary tags were now real numbers. Does this mean anything with respect to the problem? I did not update imagemagick in between (as far as I can tell).

Scannersoftware is SilverFast HDR.

Reverting to an older EXIFtool version is not the issue, I guess, since I encountered the problem before I updated to the latest version, unfortunately.

Hermann-Josef

[Hayo Baan]

I'm not sure what's going on, but if you could share the original, the split, and the merged again images together with the commands used to generate them, I can try to reproduce.

[Jossie]

Good morning Hayo,

thank you very much indeed for your offer to look into this problem.

In the meantime I made some progress. I found out that the procedure works as expected, if the input image contains 3 images: RGB (full resolution), RGB (reduced resolution = preview) and IR-image. This is the default setting in SilverFast. The procedure fails, however, if the reduced resolution image is omitted. Although, as far as I can tell, both cases are treated the same way as far as the tags is concerned.

Since in the past I had used the standard setup with 3 images, where the procedure works, and only recently omitted the preview image, I had thought that something with EXIFtool has changed. But this is not the case, as I just found out.

The output images look okay in both cases, but SilverFast can only handle the case with three images correctly. My conclusion is, that somehow the tags, which SilverFast needs for a correct interpretation of the input image, are not correctly copied by my procedure.

I have streamlined the two DOS-batches which handle the separation of the images and the reassembly for easier overview. The procedure I use to treat the IR image is irrelevant, since the reassembled file looks okay as far as the images is concerned. So the problem must be in the handling of the tags.

All files are copied to my Adobe "fog" and may be found here. The names of the TIF-images should be self-explanatory, with "opt" referring to the output images.

One way out would be to create in my macro a low-resolution image also for the case with no low-resolution image present. But this is not the ideal solution, only a workaround.

Many thanks again!

Hermann-Josef

[Hayo Baan]

I had a look at your "fog" files (nice name for cloud by the way) and my guess is that your scanner software needs the information that is contained in the metadata "around" the second image (i.e. in EXIF:IFD0), specifically the XMP metadata (there's a lot of scanner info to be found there). You could try using exiftool to copy the info back, but my guess is that it will then go to the wrong places, still making the scanner software fail.

Conclusion: don't strip the preview.

(and, no, your suggestion of adding a preview yourself won't work; it won't carry the metadata you require for the scanner software to work)

[Jossie]

Hello Hayo,

thanks for looking at my files.

The long tag with scanner info is not vital and it can be safely ignored (it is only for a special mode in the software, which I do not use and forgot to turn off. I did delete this tag in the past without any problems). There must be another reason for SilverFast not recognizing the IR-channel properly if the preview image is not embedded. I compared all tags and compared this to the case with preview embedded and could not detect any tag difference, which made me think this could be it.

In the meantime I appended in my macro a part which creates the preview if it is not present. It works as expected. However, as I said, this is only a crude workaround and I would like to understand the problem and solve it.

Best wishes

Hermann-Josef

[Hayo Baan]

Well, if the scanner info is not required, then it simply must be the fact that the software is written to expect the file to have a certain structure, with certain images in specific locations (wouldn't surprise me since that makes parsing the file a lot easier). So then yes, providing a placeholder/dummy preview will work