For those without the software, DPP allows colour alterations using curves as
well as other histogram based alterations, cropping, simple dust retouching and the like,
but it does this non-destructively on the RAW file by applying what Canon term
a 'Recipe' to the .CR2 file. DPP computes a changed preview thumbnail for viewing within
the main app browser window but applies the steps in the recipe to the original
file before allowing more edits. The changes can then be applied in batch elsewhere,
but again all changes are non-destructive with respect to the original data.

If I add an IPTC tag before retouching, then everything is fine.
If I retouch and then add a tag, DPP looses the changes and thinks the file is fresh from the camera.
A quick glance at the file sizes shows that a far chunk of information (500KB or so)
has been removed in this process, but DPP still understands the file and nothing crashes.

This makes me think that the extra information applied by DPP is done so in a sane fashion
that is correctly tagged in terms of size etc., but what are the next steps I can take
in order to find out the essential header data to allow ExitTool to leave the DPP block intact ?

I'm pretty happy at the command line and perl doesn't scare me (although my code may scare others !)
but if anyone has some pointers for how to go about investigating this then I'd be most grateful.
If others wish to look then I can provide any number of example images
(but they are all aorund 8MB in size).
TTFN,
--
Ian Spray

Posted on 2005-09-27 16:32:22-07 by exiftool in response to 1055

Ouch! You're right!
I happen to have DPP here so I just tried this out and the editing information is lost as you said.

CR2 is basically a TIFF format, and ExifTool will copy over any information even
if it doesn't recognize it, as long as it is properly referenced in a TIFF image file directory (IFD).

Unfortunately, this extra information is not referenced directly from any TIFF IFD (bad Canon!),
so it is not copied to the new file. I will do some more investigating to see if I can figure
out how this extra information is referenced.

Posted on 2005-09-27 18:21:59-07 by exiftool in response to 1056

I now understand what DPP is doing. It is simply appending a block of data to the end
of the file without otherwise modifying the file at all.
This makes a certain amount of sense, and explains why the data isn't referenced from within the
TIFF structure. But this is a bit of a pain to say the least because TIFF is not a sequential format,
so it is not as easy as just copying everything after then end of the TIFF image because
you can't easily tell where the TIFF image ends.
I'll keep working on it and hopefully I can come up with a solution, but it may take a few days.

Posted on 2005-09-27 19:43:21-07 by minimal in response to 1058

Hmm, like you say it sort of makes sense, at least as far as image integrity goes but it's hardly friendly.
Thanks for taking the time to have a look at it: I expect you'll get there faster than I would !
Recipe's can also be saved out as stand-alone files from DPP, so I'll have a look to see
if the data is the same in each case, and then try to see if there's anything helpfully
unique about the block that you might be able to use.
--
Ian

Posted on 2005-09-27 20:03:36-07 by exiftool in response to 1059

The block begins with the character sequence "CANON OPTIONAL DATA".
However, this is of limited use because it would slow things down too much to search for this string.

However, I think I may have found a solution which doesn't slow things down too much.
I have added some code to keep track of the last data block read from the TIFF, and simply
copy anything found after this to the new file. I don't like polluting my general
TIFF writer code to copy this non-TIFF information, but it seemed to be the simplest way.

I have modified the 5.64 pre-release version with this change (OK, so I was a bit quicker than I thought),
and if you want to test it out you can download it from
http://owl.phy.queensu.ca/~phil/exiftool/Image-ExifTool-5.64.tar.gz.
I still want to do more testing to be sure this is doing what I want before
I release this version officially.

Posted on 2005-09-27 20:13:17-07 by minimal in response to 1059

Just in case this helps: it doesn't appear to be exactly the same data embedded
into the .CR2 as that which can be exported as a stand-alone recipe (a .VRD file),
but it does appear to be wrapped in exactly the same text string, namely:
CANON OPTIONAL DATA

After a check of another couple of hundred untouched files it appears that the camera
never appends this string. Obviously, it's possible that this might come up inside a free-form text tag,
but if it's possible to examine the portion of the file between the last declared block
and the fsize idea of the file length (hmm, showing too much C there: sorry), then looking for
those strings and keeping the data in between ought to be fairly safe. ie: only accept the string
as a block delimiter outside of the TIFF structure.

HTH,
--
Ian.

Posted on 2005-09-27 20:15:20-07 by minimal in response to 1060

Gah - spent so long getting the formatting right our posts overlapped !
Thanks for that very speedy work: I'll try it out and see if I can break it :)
--
Ian.

Posted on 2005-09-28 13:30:19-07 by exiftool in response to 1062

After running some more tests, I managed to break it myself! :P
When running in batch mode (editing a number of pictures at once), the editing information
isn't always copied over for files after the first. I had forgotten to reset a necessary
variable between files. This is now fixed and the pre-release has been updated.

Also, I discovered an 8-byte block of information at the start of the file that wasn't being
referenced from the TIFF IFD either. This block exists in all of my CR2 sample images
(from the 350D, 20D and 1DmkII). It is a small header with a pointer to the IFD containing the
RAW data -- possibly used in camera, but not used by any of any of the Canon utilities or dcraw
as far as I can tell. But just to be safe I also added the code to generate this header
when rewriting a file.
So thanks for pointing out the original problem with the DPP information.
I think we now have a better CR2 writer.
I should be making an official release of version 5.64 within a few days.

Posted on 2005-09-28 13:45:01-07 by minimal in response to 1064

Excellent news! Thanks very much for sorting it all out for me - I hadn't found any of those issues,
but I was trying much simpler stuff (set an option, edit it lots in DPP, check and set another one etc.)
which was mainly trying to find a point where either DPP or ExifTool got upset.

They didn't.

I look forward to the official release, but I'm off to play with this one some more now.
TTFN,
--
Ian.

Posted on 2005-09-28 14:57:58-07 by exiftool in response to 1065

Oops. I had left some debugging code enabled when I did the last update.
I have fixed this and added a CR2 test to the test suite, and updated the pre-release on my web site
Sorry for any inconvenience.