Mike Chaney's Tech Corner

Mike,

I, for the first time, modified the IPTC data on a TIF file.  The only entry I made was to the Comments field.

After doing that I noticed that some, not all, of the EXIF data was changed.  I tested some add'l files and got the same thing.

I assume that this should not happen.  I did not test on a jpeg, as I usually print from TIFFs.

John

John,
can you be specific about which data has changed.
terry

Here (jpegs below) are the data from 'Floating Text' before and after making a change to the caption.

Here is EXIF data from Irfanview.  Note that it "clobbers" quite a bit of data, including original date.

 Original (but different tiff from the original)

Filename - 2008-09-30_09-34-39-2.tif
ImageWidth - 2460
ImageLength - 1640
BitsPerSample - 8 8 8
Compression - 1 (None)
PhotometricInterpretation - 2
Make - Canon
Model - Canon EOS 5D
StripOffset - 56794
SamplesPerPixel - 3
RowsPerStrip - 1640
StripByteCount - 12103200
XResolution - 240
YResolution - 240
PlanarConfiguration - 1
ResolutionUnit - Inch
Software - Adobe Photoshop Lightroom 3.4.1
DateTime - 2011:07:09 07:45:24
Artist - John Schwaller
Copyright - ©John Schwaller
IPTC/NAA - 32892
ExifOffset - 56322
InterColorProfile - 55782
ExposureTime - 1/320 seconds
FNumber - 7.10
ExposureProgram - Normal program
ISOSpeedRatings - 400
ExifVersion - 0230
DateTimeOriginal - 2008:09:30 09:34:39
DateTimeDigitized - 2008:09:30 09:34:39
ShutterSpeedValue - 1/320 seconds
ApertureValue - F 7.10
ExposureBiasValue - 0
MaxApertureValue - F 4.00
MeteringMode - Multi-segment
Flash - Flash not fired, compulsory flash mode
FocalLength - 105 mm
FocalPlaneXResolution - 3086.93
FocalPlaneYResolution - 3091.30
FocalPlaneResolutionUnit - Inch
CustomRendered - Normal process
ExposureMode - Auto
White Balance - Auto
SceneCaptureType - Standard


Changed file:
Filename - 2008-09-30_09-34-39.tif
ImageWidth - 2460
ImageLength - 1640
BitsPerSample - 8 8 8
Compression - 1 (None)
PhotometricInterpretation - 2
Make - Canon
Model - Canon EOS 5D
StripOffset - 35080
SamplesPerPixel - 3
RowsPerStrip - 1640
StripByteCount - 12103200
XResolution - 240
YResolution - 240
PlanarConfiguration - 1
ResolutionUnit - Inch
Software - Adobe Photoshop Lightroom 3.4.1
DateTime - 2011:07:01 10:27:32
Artist - John Schwaller
Copyright - ©John Schwaller
IPTC/NAA - 11526
ExifOffset - 34608
InterColorProfile - 34068
ExposureTime - 1.2 seconds
FNumber - 233.62
ExposureProgram - Normal program
ISOSpeedRatings - 400
ExifVersion - 0230
DateTimeOriginal - ˆû~@BVLV@B
DateTimeDigitized -

i

ShutterSpeedValue - 1/1 seconds
ApertureValue - F 1.#J
ExposureBiasValue - 0.96
MaxApertureValue - F 4097.17
MeteringMode - Multi-segment
Flash - Flash not fired, compulsory flash mode
FocalLength - 105.00 mm
FocalPlaneXResolution - 0.00/0.00
FocalPlaneYResolution - 0.00/0.00
FocalPlaneResolutionUnit - Inch
CustomRendered - Normal process
ExposureMode - Auto
White Balance - Auto
SceneCaptureType - Standard

Hi John,
I want to see if I can replicate what you get.
So far, I cannot.
I would like to have your steps.
I right clicked on a TIF thumb, selected EDIT IPTC info.
Then I typed in TEST in two places; Description and Caption.
I saved it.
I opened the image in Irfanview and read the EXIF info and the IPTC info.
I don't see any change or damage.
I am using a Canon 20D Raw to Tif image
I'll try it with the original Raw only.
Am I doing something differently from your test?
I just dug out my EXIF tool program and there's no changes other than the Modified date. It goes to the time the Data was added.

Fred

I basically did the same thing.  Got the same result with 3 different TIF files.

I only added a change to the Caption IPTC.

TIFFs were 8-bit.  Don't remember right now if they were created, in Lightroom, directly from the RAW file or from an intermediate TIFF (result of round trip to PS).  I would not expect Qimage to alter a RAW file.

I have since made changes in LR to both the Caption and Description.  These changes did not result in any data "clobbering".

My OS is Win7 64 bit.

It will be a few days before I can do add'l testing as I have relatives visiting.

John

BTW...when you tested, what date changed.   The originaldate or createddate (can't remember) should never change and should be the date that Qimage picks up in the Floating Text or EXIF date to print.....not a last modified date.

The change noted was the date and time the IPTC caption and description were changed.

Relatives coming? 
Maybe if you supplied your email address, the entire forum could send sympathy cards via email? ;D

Make one easy test first.
Take the RAW into QU. Then Create a TIF in QU.
Now operate on the IPTC of the new TIF made by Qimage Ultimate.
See if the same thing happens.

Fred

Q created TIF (8-bit) is not corrupted with IPTC change.

LR created TIF (both 8 and 16 bit) are corrupted.

These were both created directly from RAW, not intermediate steps.  I am not sure if any compression was done on the LR files, but the LR 8 bit files were the same size as the Q files.

All this is interesting as TIF is supposed to be a documented "industry standard".

John

I guess that points the fickle finger of fate for you.

As an example that means nothing, the other day, my wife found that she could not print from any internet screen. Could not print receipts, bank statements, nada!
Same Firefox as I run 5.01. I could print it and she couldn't.
Tracked it down to a not so cute add-on placed on her computer into Firefox by Our old psychotic friend Hewlett Packard. It was a printing add on.
I disabled it, and Viola!, he computer started to print web pages again.
Oh, her directly connected printer is an HP Office 6000. The add on came in on the back of a driver install.
Had we both not had the same exact browser, it would have been easy to lay blame on Firefox.

I always like to solve the mysteries.   
Fred

I'm not sure it does.  All it says is that Qimage can modify TIFFs that it creates.....and, for some reason, has a problem with LR created TIFFs.  Q does not have any problem reading the data from the LR created TIFFs. 

I am not sure we can make any statement further than that.

John

Interesting. I was looking fir info on a lens, when I came across this.
Read a few of the Me Toos further down the page.
This might be helpful.

http://www.luminous-landscape.com/forum/index.php?topic=15867

Fred

Thanks, Fred. 

However, this post was 2007 and also seems to indicate that the output is consistent with the TIFF specs.

I don't know enough about this to understand what the cause is.  I would really appreciate if Mike could look at this.  If it is Adobe, I am willing to contact Adobe and/or post on their forums requesting a fix.  If it is to "spec", it would be great if 'Q' altered to handle it.

John

Hi John

read this -   http://www.filepie.us/?title=Exif (http://www.filepie.us/?title=Exif)

You can possibly see why it is all messed up (sometimes)  :(

Best wishes,

Ray

I know TIFFs can be difficult.  If I remember correctly, back when, 'Q' didn't even provide EXIF data when creating them. (or maybe it was when creating jpegs from TIFFs  ??? )

The important point is that data integrity should be maintained.  'Q' can read the EXIFdata.  If it can only properly write to 'Q' created TIFFs....or, better said, I guess, can only be assured of properly writting to....then there should be a warning....or a test...to avoid doing this.

For me, until I here otherwise, I will do all of my TIFF modifications in LR or PS.

John

I think you are starting out with "clobbered" data to begin with and it is just getting worse with the resave.  I've found in the past that LR corrupts IPTC data under some conditions when you have it assign IPTC data on import (from say a flash card).  Take a look at your copyright in your original.  It says "©John Schwaller".  Where did the "Â" come from?  That's usually an indication of data corruption.  Even one oddball character can often be an indication that there are lower level problems in the IPTC data: bad pointers and such.  I already know from prior experience that LR creates corrupted IPTC data under some conditions.  The data gets corrupted when you set LR to add IPTC data to your images upon import.  I thought that the problem only occurred when you used special (other language) character sets but I'm finding now that the problem could be broader than that.

The fact that QU makes already-corrupted data worse isn't something I plan to look into.  The problem really needs to be corrected at the source.

Mike

Mike,  I fully understand...and agree....that you should not fix someones already corrupt file.

To make things easier to understand, I did the following test....

Rather than use LR, I used PS CS5.  I took a CR2 file and moved it into it's own directory....with no existing XMP file.  I then opened in PS, which first, of course, opened ACR.  No changes were made, I opened the file in PS.  No changes were made and the file was 'Saved as' a 16bit TIFF, ProPhoto color space.  I also did this a second time and changed the color space to DDIRGB and mode to 8bit.

In QU, I modified each of these files, adding 'Test' to the 'Caption'.  In both cases, the EXIF data totally disappeared....actually on further inspection, the files were totally unreadable by QU or LR

Below is one of the file's EXIF data before the QU IPTC change...

Filename - 2008-09-30_09-34-39.tif
ImageWidth - 4368
ImageLength - 2912
BitsPerSample - 8 8 8
Compression - 8 (Unknown)
PhotometricInterpretation - 2
Make - Canon
Model - Canon EOS 5D
StripOffset - 340
Orientation - Top left
SamplesPerPixel - 3
RowsPerStrip - 80
StripByteCount - 488
XResolution - 240.00
YResolution - 240.00
PlanarConfiguration - 1
ResolutionUnit - Inch
Software - Adobe Photoshop CS5 Windows
DateTime - 2011:07:27 18:30:17
IPTC/NAA - 22806
ExifOffset - 16813272
InterColorProfile - 30588
ExposureTime - 1/320 seconds
FNumber - 7.10
ExposureProgram - Normal program
ISOSpeedRatings - 400
ExifVersion - 0221
DateTimeOriginal - 2008:09:30 09:34:39
DateTimeDigitized - 2008:09:30 09:34:39
ShutterSpeedValue - 1/320 seconds
ApertureValue - F 7.10
ExposureBiasValue - 0
MaxApertureValue - F 4.00
MeteringMode - Multi-segment
Flash - Flash not fired, compulsory flash mode
FocalLength - 105 mm
ColorSpace - Unknown (0xFFFFFFFF)
ExifImageWidth - 4368
ExifImageHeight - 2912
FocalPlaneXResolution - 3086.93
FocalPlaneYResolution - 3091.30
FocalPlaneResolutionUnit - Inch
CustomRendered - Normal process
ExposureMode - Auto
White Balance - Auto
SceneCaptureType - Standard

It would not be the first time that Adobe had an "aw shucks", but...seems to be curious as QU can see all the EXIF data properly in the original files.

John

EDIT:  BTW....the funny character before the copyright symbol seems to be a function of how the symbol is displayed in Irfanview (and in PhotoMe).  I changed the import prest to have my name without the symbol and no funny character.

Hi
I think this may have something to do with the encoding mode - see this:

http://www.openphotographyforums.com/forums/showthread.php?p=97681 (http://www.openphotographyforums.com/forums/showthread.php?p=97681)

I've read all the posts but I didn't understand a word of it  :-[ :-[, but it may be relevant.

Brian

www.secalis.co.uk (http://www.secalis.co.uk)

I repeated your test with a 5D CR2 and what I found is that it worked perfectly unless "byte order" on the TIFF save options was set to "Macintosh".  As soon as you set the byte order to "IBM PC" it works fine.  Can you confirm that's the case on your system as well?  Not sure why Adobe would set "Macintosh" as the default when they know their software is installed on a Windows system, but it does seem to have the wrong default.  I may have to disable IPTC if Mac byte order is selected if I can't find an update to the third party IPTC tool I'm using that will allow Mac TIFF's.

Mike

I can confirm that MAC byte order was checked....and seems to be the default.    I will test PC later today.

In the post Fred sent me to http://www.luminous-landscape.com/forum/index.php?topic=15867  Our "favorite friend", Schewe, states that byte order should not matter (Reply #11)  Good thing he has never been wrong :-)

John

EDIT...as you know, PS allows the option to select 'PC'.  It does not appear that LR provides any choice.

Byte order doesn't seem to matter for the image itself.  Not sure why it makes IPTC a problem for QU.  I'd have to look into it further, but I do know that Adobe does some non-standard things with IPTC.  Last time something similar happened I caught Adobe putting Unicode text into IPTC data.  Fine for them maybe... but it (badly) breaks the IPTC standard by inserting what amount to non-ascii control codes.  They seem to be fine with arbitrarily "redefining" standards.  I guess they figure everyone will follow.  But again, I'm just guessing at this point from what I've seen in the past.  I'd have to look into it when I have more time.  Right now, I'm busy with QU 2012 which is due out by the third or fourth week in August.  :)

Mike

No problem, Mike.  My current plan is to make all my IPTC updates in LR.  When you get a chance to look into it in QU, the option for last minute changes will be great.

John

referring to http://www.iptc.org/cms/site/photometadatasupportlist.html?channel=CH0101#70 (http://www.iptc.org/cms/site/photometadatasupportlist.html?channel=CH0101#70) and other pages on iptc.org, you can see how various software packages comply? with the so called standard. iptc have based much of what they do on what Adobe does, so of course Adobe can behave more or less as a law unto themselves, the rest have to play 'catch-up'. :(

Best wishes,

Ray