Exiv2

Hi Paul,

No that shouldn't happen. But it is possible to cripple a TIFF file when writing to it. Can you provide a sample image and show what you're doing with it?

Andreas

Andreas Huggel wrote:

No that shouldn't happen. But it is possible to cripple a TIFF file when writing to it. Can you provide a sample image and show what you're doing with it?

I just followed the sample program, really - it happens with any TIFF I write out using libtiff:

@Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open(path);
if (image.get()) {
image->setExifData(exif_data_i_got_from_another_file);
image->writeMetadata();
}
@

Hi Paul,

setExifData replaces all existing Exif data in the target with those of the source. This is fine if the target image has metadata which is clearly separated from the image structure. TIFF-like formats don't do that and this operation potentially wipes out the image tags.

There was an issue in the exiv2 command line tool related to this, #602. It was fixed in 0.18.2, see note 4 and r1759, in particular the changes in actions.cpp - you may want to do something similar in your code.

Andreas

Ooh, that explains the troubles I was having too.

Could we get a "tiff-safe" setExifData variant in exiv2, instead of copying the special exceptions into every applications?

- Mike

Yeah there is a fair bit of special-purpose code there - it would be nice if the TIFF implementation of setExifData() would just "do the right thing", so we don't need to worry about which format we're dealing with. I've reverted to 0.16 for the time being since I had to get a quick update put out.

Yes, I agree that should be added to the library. Especially also as exiv2 will sooner or later be able to write to TIFF-like RAW formats. I can think of a few ways to achieve this:

1. Variant: Leave Image::setExifData (and Image::setMetadata) as they are and add a new function, e.g., Image::copyExifData (and Image::copyMetadata). Applications that want to use it may currently be using setExifData and will have to change.
2. Modify: Change Image::setExifData (and Image::setMetadata). Instead of being a simple setter function, for TIFF images, it now has the necessary logic. That way the change is transparent for apps which need that functionality. But unless we add another simple setter function, it wouldn't be possible to write all TIFF tags anymore. (E.g., to compose a TIFF image from scratch). And those are usually called set*.
3. Add something like the metacopy() function from actions.cpp to the library (possibly taking a source and target Image instead of paths).

Now after typing all of this, I like 1 best. What do you think?

Andreas

1 would work for me - but instead of naming it "copy" how about "merge"? So it would take the incoming tags and "merge" them with whatever necessary TIFF tags are already there?

As an aside: I'm talking theory here and not advocating doing #2, but it seems to me there are a certain set of necessary TIFF tags that a TIFF file needs to make the image "work", and then there are other "exif" data tags that are meta-data and "optional", and that setExifData() should NOT overwrite any "necessary" tags but simply insert the meta-data information. This is how I thought it worked when I was attempting to use it the same way I write my JPEG tags. It's current behavior seems to be exposing implementation details about the underlying format.

Paul Miller wrote:

1 would work for me - but instead of naming it "copy" how about "merge"? So it would take the incoming tags and "merge" them with whatever necessary TIFF tags are already there?

Or using a flag, similar to that in metacopy(), for the caller to indicate if existing "unnecessary" tags in the target should be preserved or not.

Andreas

I have the same problem with setExifData/writeMetadata for TIFF files on Win32. It's corrupts file.

This has become issue #668 and it's on the roadmap for the next release. (It happens on any platform.)

#668 is almost done, the "special-purpose code" has been removed from the command-line tool. The logic to take care of "image tags" is now part of the library. The interface remains the same. So please test again, throw any metadata at your TIFFs and see if you can harm them. Or simply truncate it all (exiv2 -da img.tif) and see if the image remains intact as it should. (TIFFs only for now, DNGs and TIFF-like RAW images are not quite as robust yet.)

Andreas

Just so I understand - you've gone with choice "2. Modify", and setExifData should "just work"?

- Mike

Just so I understand - you've gone with choice "2. Modify", and setExifData should "just work"?

Yes, setExifData should "just work" and the API hasn't changed. The approach is different from that proposed above though, as it turned out that it is necessary to implement this in the lower-level TIFF serialization code (in the the TIFF parser, setExifData itself is unchanged). See issue #668 for details.

Andreas