Bug #717
Writing Exif.Image.ImageDescription in ORF file corrupts file
100%
Description
After using macports on snowleopard to install v0.20 I finally could add the filename into the exif information, however when doing so with:
exiv2 -k -M "set Exif.Image.ImageDescription Ascii 7252283.ORF__________________" _7152208.ORF
Changed the picture color in quicklook, a cyan cast. When opened in olympus viewer2 you only get to see the small preview.
I tried before with only the filename but that did not work so in the end I also tried keeping the length of the field the same, which did not help. I also tried with another photo but the result is the same.
Now my knowledge is severally limited into what goes wrong so I hope someone else could shine a light here.
I attached the original file and the difference of the exif info extracted with
exiv2 -u -p a _7152208.ORF >7152208.exif
and a second time after changing the imagedescription and then diff into the attached file.
If more info is needed I will try and supply it.
thnx in advance
Files
Associated revisions
History
Updated by Andreas Huggel over 11 years ago
Using the current trunk, I get minimal differences between the before and after Exif data.
I suspect this is a duplicate of #711.
Can you please test with Exiv2 from SVN and confirm?
Thanks,
Andreas
Updated by Wouter Portegijs over 11 years ago
I will try and install the svn this coming week but I am not 100% sure if I will succeed since I installed the v0.20 via macports.. And thus I need to figure out how to install from svn on a mac first.
The svn command is not a problem though .... I know that one, it is more related to the configuring and making that i have some doubt in succeeding.
Updated by Wouter Portegijs over 11 years ago
Ok made some time 2day.
I did not get it to behave with macports ... so in the end I just did the make config ./configure and make
However Does the svn version still reply v0.20 when asked exiv2 -V ?
If so I think I am using the svn version now.... Otherwise you have to explain me how after/during compiling the v0.20 exiv2 file got into the src dir.
Anyway there is an improvement? the difference between the exif info with the svn version is now this:
6c6
< Exif.Image.ImageDescription Ascii 32 OLYMPUS DIGITAL CAMERA
---Exif.Image.ImageDescription Ascii 32 7252283.ORF__________________
This we expected and wanted ;)
34c34
< Exif.Photo.MakerNote Undefined 651928 (Binary value suppressed)
---Exif.Photo.MakerNote Undefined 553310 (Binary value suppressed)
this was not intended .... I guess . Anyway the picture after the change still has the cyan cast over it.
Now I tried to change that field a couple of more times and at some point a whole bunch of fields are changed.
Updated by Andreas Huggel over 11 years ago
Yes, the version in SVN is still 0.20 and from the remaining differences it looks like you're running the SVN version now. Congratulations! :)
So in Quicklook (the Apple viewer, right?) it still has the cyan cast. I should be able to try this myself at home tonight.
Did you also check the image in Olympus viewer2? Does it still only show the thumbnail view? (I don't have this program)
Now I tried to change that field a couple of more times and at some point a whole bunch of fields are changed.
More differences are expected if you make the field larger than it was before. In this case Exiv2 will re-write the entire TIFF structure and offset-fields will change. That's expected and doesn't by itself have an impact on the metadata or the image. I would need to see the differences in order to tell if that's what happened.
Andreas
Updated by Wouter Portegijs over 11 years ago
- File difference.exif difference.exif added
So in Quicklook (the Apple viewer, right?) it still has the cyan cast. I should be able to try this myself at home tonight.
Quicklook is hitting the spacebar in the finder. Preview is the apple viewer kinda, but they have both the same behaviour
Did you also check the image in Olympus viewer2? Does it still only show the thumbnail view? (I don't have this program)
Forgot about that but I checked and it show still only the small preview.
I tried picasso also which shows the picture but in the system log this pops up
06-08-10 17:50:52 [0x0-0x317317].com.google.picasa23243 /Users/wouter/_7152208.ORF: Unexpected end of file
Now I tried to change that field a couple of more times and at some point a whole bunch of fields are changed.
More differences are expected if you make the field larger than it was before. In this case Exiv2 will re-write the entire TIFF structure and offset-fields will change. That's expected and doesn't by itself have an impact on the metadata or the image. I would need to see the differences in order to tell if that's what happened.
I did not enlarge the field I just redid the same command a couple of times... Actually I just tried again and it does not seem to happen anymore indeed only after making bigger again from 13 characters to 17 characters gives more difference. see attached diff file
./exiv2 -k -M "set Exif.Image.ImageDescription Ascii _7252283.ORF" _7152208.ORF
and again and again. Just to see what would happen.
Updated by Andreas Huggel over 11 years ago
- Category set to miscellaneous
- Status changed from New to Resolved
- Target version set to 0.21
- % Done changed from 0 to 100
Can you try again with the latest version from SVN, r2304 and confirm if that works for you as it does here and also retest with the Olympus software please?
Exiv2 changed TIFF IFD offset types to normal LONG types (which are much more common for this purpose). That is fixed, Exiv2 now leaves those types alone and on my Mac Quicklook is happy.
(And I learnt that hitting the spacebar in Finder shows a preview :)
Thanks for reporting this issue.
Updated by Wouter Portegijs over 11 years ago
I was to slow it seems like.... the svn gave me revision 2309 so tried that ;)
The cast is indeed gone and within the olympus viewer2 application the picture seems to behave as expected as well.
So thnx for fixing it.
#717: Retain TIFF IFD type when writing, removed unnecessary ValueType constructors.