Convert.exe: transferring ITPC and EXIF data

[mikea]

Searching through the documentation supplied with the Win version of IM, and searching through messages here, I haven't yet found information telling me if I can transfer EXIF and IPTC data when I use Convert.exe.

I'm using Convert to read large TIFF image files and convert them to web-sized 72 ppi images. In nearly all cases they have IPTC data and for sure in all cases there's EXIF data to transfer. In the script that's driving these conversions, I could certainly add a step that launches ExifTool and uses its "tagsfromfile" switch to transfer the information, but it would be handier if it could be done in the Convert.exe step. Is there a Convert switch+argument that would do this? Suggestions much appreciated as to the correct syntax...

[Bonzo]

If you are resizing with -resize the image will retain EXIF data but I am not sure about IPTC data.
If you use -thumbnail the information will be stripped.

[mikea]

If you are resizing with -resize the image will retain EXIF data but I am not sure about IPTC data.
If you use -thumbnail the information will be stripped.

I'm using -resize. Some of the documentation is a bit on the minimalist side and I haven't fully deciphered the purpose of -thumbnail or why it works the way it does. Well, no other replies to this one, so I have the feeling Convert.exe isn't the way to go. Strange -- I'd have thought it would have explicit options for these things -- seems like the ideal "place" to have them. No problem. I've added an Exiftool "-tagsfromfile" step to the process. It increases the processing time (but not by much) and does the job right for sure.

[anthony]

Minimalist!!!! Minimalist!!!!

I just spend month's going into over detail on documenting resize!!!!
You just didn't look in the right place!

http://imagemagick.org/Usage/resize/

-resize should not touch profiles at all! though -thumbnail calls -strip to remove all profiles.

[mikea]

Minimalist!!!! Minimalist!!!! :shock:

I just spend month's going into over detail on documenting resize!!!!
You just didn't look in the right place!

http://imagemagick.org/Usage/resize/

-resize should not touch profiles at all! though -thumbnail calls -strip to remove all profiles.

Well clearly you're right -- not looking in the right place. I was referring to what's supplied with the program. I haven't yet learned about all the places to go for additional documentation (I'm aware that there's at least one ImageMagick book, but I would imagine the programs are in such flux all the time that any given book will be quickly out of date!).

In my experience so far, -resize is either removing or just not copying IPTC data. But if you think that is not the expected/typical result, I'll have to do some more testing to find out if this is user error or if I'm being deceived by some condition in the source files.

I notice that different camera-raw converters write differing "amounts" of EXIF data, and so I'm wondering if there is variation in how they store IPTC data...enough variation to confuse other programs "downstream" from the raw-conversion process.

An interesting little "thing" about this...I've been following up resizing/resampling via Convert.exe by running Exiftool with its "-tagsfromfile" switch, to add the original file's full EXIF and IPTC data back into the output file (a JPEG; the source is a TIFF file). Then I found that (well, of course!) Exiftool is writing the original resolution data ("XResolution" and "YResolution") into the JPEGs -- and that's 240x240. But the resample option I'm using with Convert.exe is 72x72! On realizing this I updated the Exiftool command line to include "--XResolution" and "--YResolution" to keep from copying that particular data to Convert.exe's output file.

So what does Photoshop display? I tried this both ways -- with and without those "--" Exiftool command-line arguments. Well, no matter which file I display within Photoshop, in "actual pixels" mode the two images display as exactly the same size. That, I wasn't expecting. Tentatively I have to guess that Photoshop is ignoring the metadata in these cases and looking at the actual pixels. But I wonder what it'll do with that 240x240 (nominal) ppi image if I save it within PS -- then close it and re-open it with PS. I would expect that the 240x240 ppi image, given the same pixel dimensions, would display a whole lot smaller than the 72x72 image! Note to self: try the save/reopen thing, or you'll never get to sleep tonight worrying about it. :-).

Thanks.

[anthony]

Photoshop does not use the normal JPEG resolution if its own profile data is present. On the other hand IM doesn't handle photoshop profile data, and just passed it through unless you specifically strip it.

If you need photoshop to us ethe jpeg resolution, strip the profile.

That is the only hints I have about this at this time.

[mikea]

Photoshop does not use the normal JPEG resolution if its own profile data is present. On the other hand IM doesn't handle photoshop profile data, and just passed it through unless you specifically strip it.

If you need photoshop to us ethe jpeg resolution, strip the profile.

Clearly I'll have to find the documentation about stripping that info specifically. Now basically confirming what you've just said...here again is the Convert.exe command I've used so far (with the input TIFF and output JPEG filenames omitted here):

• -resample 72x72
  -filter Lanczos
  -quality 85
  -profile "C:\WINDOWS\SYSTEM32\SPOOL\DRIVERS\COLOR\sRGB Color Space Profile.icm"
  -resize 800x800

Result:

• o The JPEG contains no EXIF data (unless I post-process with ExifTool).
  o The IPTC data is preserved (with or without ExifTool post-processing).
  o The JPEG, displayed in either IrfanView or FastStone Viewer, appears to have a nominal resolution of 72 PPI -- with dimensions of 623x800 pixels. Opened directly into a browser (either FireFox or IE), the image displays at the same size seen in IrfanView and FS Viewer.
  o The JPEG is shown in Photoshop CS2 as having a nominal resolution of 240 PPI, not 72 -- though it's shown as having the same pixel dimensions. Of course when it is displayed at "print size" in Photoshop, it's much smaller than its "actual size" display in either IrfanView and FS Viewer.
  o When the photo is uploaded to a hosting site, it does display at the size I asked for -- the desired result, Photoshop notwithstanding.

So ... who's "right" here? Photoshop, or the two image viewers? Did the resampling to 72 ppi actually take place? Two programs and the browsers appear to say Yes and Photoshop appears to say No (consistent with your earlier advice).

I found by accident that if the "resize" switch and its argument are placed on the command line preceding "resample", "resize" seems to be ignored: the output file's pixel dimensions are now 160x240 -- as opposed to the result of 623x800 when the switches are as they appear in the original command. So clearly the order in which the switches appear matters (perhaps a bit more subtlety syntax-wise than one needs, but so it goes :-).

Thanks again for your feedback.

[anthony]

I found by accident that if the "resize" switch and its argument are placed on the command line preceding "resample", "resize" seems to be ignored: the output file's pixel dimensions are now 160x240 -- as opposed to the result of 623x800 when the switches are as they appear in the original command. So clearly the order in which the switches appear matters (perhaps a bit more subtlety syntax-wise than one needs, but so it goes .

it isn't that the resize is ignored. BOTH operators are basically different forms of resize.
The -resample operator resizes the image to preserve the current 'physical' size while changing the number of actual pixels to match the new density you give and it also defines.
See IM Examples, Resize Images, resample

Photoshop is the culprit. It is the one that does not follow the 'standard', prefering to do it's own thing.
If photoshop saves the image as a 'www image' then it junks its own special profile.

[mikea]

Photoshop is the culprit. It is the one that does not follow the 'standard', prefering to do it's own thing.
If photoshop saves the image as a 'www image' then it junks its own special profile.

Yes, I've noticed that its save-for-web routine does things a person just doesn't appreciate. It was one of the reasons I began looking for other save-for-web apps. I ran across a couple of them. Neither could convert to sRGB! I finally found one (IDBatcher, from the guy who makes IDImager) that can do all of the right things -- resize, resample, convert to sRGB, even sharpen if you want -- but it's a GUI app and has a somewhat odd UI (don't they all?). Where O where was the command-line tool that would do it? Then I found out about ImageMagick, which suggests to me that there might yet be hope for humanity. :-)

Now interestingly, someone I know who writes PS plug-ins believes that IrfanView and FS Viewer might be making incorrect assumptions about the files but Photoshop itself is doing the right thing in how it displays the image properties (he and I weren't talking about PS's own save-for-web feature, though).

Then to my surprise yet another test of this script started producing JPEGs that do appear as 72 ppi images at the asked-for pixel dimensions, within Photoshop, and damned if I know what I did to suddenly start producing this (correct) result after all. Either I had too much coffee today, or not enough...