I wanted to build an awesome place for people to discuss module specific issues, but I don't have any more time for this, and there are much better places to discuss Perl-related issues. I'd recommend asking your question on Stack Overflow or on Perl Monks.
If you are looking for a Perl tutorial or Perl-related news, I hope these links will serve you well.
Image-ExifTool
Posted on 2009-03-06 14:06:05-08 by igor77 in response to 10126
Re: batch change previews in RAW-files
Hi!

I'll try to answer by steps
> then you should embed new (modified) thumbnal instead of existing one.
And I do it - I use thumbnail from new jpeg, which is similar to the big jpeg file. And moreover it has proper orientation after rotation jpeg file by nConvert.

> two different thumbnails inside CR2 file
To be honest, I can't find second preview which is embedded into preview (jpg) image. It exists there after changing preview (with whole metadata), but if I extract embedded preview from initial file (just from camera) - I can't find preview there.
Also I know about 160x120 thumbnail of CR2, and 168x112 thumbnail of JPG, but I find the second preview only in JPEG which I receive from DPP. And after embedding this 168x112 thumbnail to CR2 I didn't find any problems in other programs, in spite of different size.

> DPP does opposite: it only uses CanonVRD tag
Not "only". Yes, it uses CanonVRD to write, but to read (and show image correctly) it uses also EXIF information if CanonVRD is empty. If we save "receipt" to the CR2 file, even if we do not rotate image in DPP, it writes to CanonVRD:rotation tag the value according to EXIF information. It always writes rotation tag according to how we see image on screen - if we do not rotate image in DPP, it writes just EXIF value. And the next time it use already CanonVRD tag.
Of course I agree about using only EXIF information by other viewers.

I think we may segregate this issue into three cases:
1. If we use only DPP to converting. This case we have to look to CanonVRD tags and if they are empty - to EXIF. I am still sure that this is correct algorithm.
2. If we use another converter. Here we have to look to EXIF and sometimes to additional XMP-file (after Adobe converters).
Both this cases (1 and 2) it is important that we must not rotate images after converting. So we may be sure about proper orientation.
3. If we do rotate images after converting and in all other cases we may only guess how to lay down vertical JPEG, or we may tell to program, how was camera oriented - like you have realized in GUI.
I suppose, for universal use you may ask user additional question :)

Best regards,
Igor
Direct Responses: 10128 | Write a response