I bought Canon PowerShot ELPH 330 HS recently. A script I have which worked with an older Canon camera isn't working with this model. Specifically, when I use SetNewValue() in Perl to try to set the MakerNotes group tags, the API reports success, but when I walk the metadata after writing the file to disk there are no MakerNotes tags. Oddly, though, using SetNewValuesFromFile() from a file (using PowerShot ELPH 330 HS), the ExifTool does copy the MakerNotes across, but then I cannot reset individual fields using SetNewValue(), which I need to do because I am transforming the file using "Imager".
I tried to decipher the Release Notes to see if this is fixed recently, but can't tell.
Specifically I am using Perl API ExifTool version 9.13.
P.S. If this camera type is not yet supported and you need access to some example photo files, I'd be happy to supply.
P.P.S. The fact that the API reports success when it hasn't actually written the tag wasted a lot of my time debugging, but I forgive since this is free!! :)
The WriteInfo() call should return 1 if the file was written and something was changed, or 2 if nothing was changed. Being free is not an excuse for poor software.
I'll need a more specific example about what you can't write. The ELPH 330 HS should be supported, although I don't have a sample yet so I can't test this. (You can mail me one if you want: philharvey66 at gmail.com)
Do you get any warning messages?
- Phil
Sorry, I was out walking. Just saw reply.
The WriteInfo() call returns 2, and there are no Warning or Error tags.
I'll send you the files via e-mail.
Cheers,
Jonathan
Hi Jonathan,
This will happen if there are no tags set that ExifTool can write to the file.
What tags did you set with SetNewValue() ?
- Phil
It's all in the e-mail. I set every tag in the MakerNotes group of the original file.
BTW, e-mail is being sent, but is ~12 MB, so let me know if it never arrives and I'll reduce the size or post files onto a web page.
Just did some more testing. I used an old backup copy of my script from January, and ran it against an older file which I had run it against before I(it's from an older model of Canon camera), and that also now fails to write out MakerNotes, even though it used to work fine (I have a copy of the converted file from July 2012 which is when that photo was converted).
What has changed since July 2012 is that I am using a new computer, new version of perl (but still perl 5, v5.16.2), and a new version of ExifTool. I'll boot up my old computer (XP) and check what it has loaded in terms of versions.
My Old PC is WinXP and uses ActivePerl, but on my new PC I use Strawberry Perl.
Version on old PC is:
v5.8.7 built for MSWin32-x86-multi-thread
Binary build 813 [148120] provided by ActiveState http://www.ActiveState.com
That's unlikely to matter.
The ExifTool version on old PC is 5.32, so quite a lot older than the current version I am using on new PC (9.13).
Hi Jonathan,
I got the email, and I confirmed that ExifTool 9.29 writes this file fine by trying this with the "exiftool" application:
exiftool -tagsfromfile @ -makernotes:all -v3 IMG_0126.JPG
I suggest running some tests with the exiftool application to see if it works properly with your Strawberry Perl installation. I'm afraid I can't help much there. I know ExifTool did fail one test on CPAN testers (http://www.cpantesters.org/distro/I/Image-ExifTool.html), and I think it was Strawberry Perl, but it failed because the ExifTool libraries couldn't be found (I think it was just a bad installation).
- Phil
BTW, I would recommend not using Windows to update metadata because it will corrupt the maker notes. With ExifTool 9.29 you get this warning when writing to your image: "Warning: [minor] Adjusted MakerNotes base by 4148".
What is that command doing internally? Is it running SetNewValuesFromFile()? As mentioned in my initial post, SetNewValuesFromFile() is working fine (all tags copied), whereas SetNewValue() is not working (doing tag by tag in a loop).
Anyway, how do we actually know this is doing anything in the file itself? I'm assuming it's copying the file and doing writes over the top of tags that already have the same values. Anyway, I ran it at CLI and the MakerNotes are there.
But I'd rather (1) make sure it's not using SetNewValuesFromFile() equivalent, and (2) using the temporary file as the file it's writing to, because that file is "empty" of tags, so we can be sure it's really writing the tags.
So, I tried this command:
exiftool -tagsfromfile IMG_0161.JPG -makernotes:all -v3 Z-ZZZ-outputfile.jpg
The source file is another from the same camera which has never had any Windows edits done.
Here's the end of the output:
======== Z-ZZZ-outputfile.jpg
Rewriting Z-ZZZ-outputfile.jpg...
Editing tags in: APP0 APP1 CIFF ExifIFD IFD0 JFIF MakerNotes
Creating tags in:
JPEG APP0 (14 bytes):
0000: 4a 46 49 46 00 01 01 00 00 01 00 01 00 00 [JFIF..........]
Rewriting JFIF
JPEG DQT (65 bytes):
JPEG DQT (65 bytes):
JPEG SOF0:
JPEG DHT (29 bytes):
JPEG DHT (179 bytes):
JPEG DHT (29 bytes):
JPEG DHT (179 bytes):
JPEG SOS
Nothing changed in Z-ZZZ-outputfile.jpg
0 image files updated
1 image files unchanged
I notice in the log messages it says "...if tag exists", so I think I have the command wrong or something? The tag doesn't exist in Z-ZZZ-outputfile.jpg, but is in the file IMG_0161.JPG, so it should be able to copy from IMG_0161.JPG into Z-ZZZ-outputfile.jpg, but as you can see there's no change.
Could you try this command on your side? Using IMG_0126.JPG as the source of the tags, and Z-ZZZ-outputfile.jpg as the file to be written into?
Hi Jonathan,
Your command doesn't work for the reasons outlined in FAQ number 8 (https://exiftool.org/faq.html#Q8). This FAQ also gives the proper syntax for what you want to do.
You also ask in the email why ExifTool sets the values of 48 tags when calling SetNewValue('MakerNotes:WhiteBalance',$val). The reason is that there are 48 (or more) different writable MakerNotes whitebalance tags. See the Tag Name documentation (https://exiftool.org/TagNames/) for a complete list.
- Phil
FAQ says:
- ...in this case the "-makernotes:all" syntax does not work because it attempts to copy the maker note tags individually. Since maker note tags may not be created individually, they must instead be copied as a block with "-makernotes".)
Could you translate that into equivalent Perl API calls for me? Is it that I must use SetNewValuesFromFile() to force a block-copy or can I use SetNewValue('MakerNotes:*'), so long as I also call SetNewValue('Make') and SetNewValue('Model') beforehand? Should I force my loop to write the EXIF group before writing any other group?
In conclusion, I think you are saying that there's no way to do what I want to do: copy over the MakerNotes and
also modify some individual MakerNotes (specifically because I rotate the image using Imager, I want to swap all "width" and "height" tags since the image itself is now 90 degrees rotated).
At best I will end up with the EXIF tags ExifImageWidth and ExifImageHeight giving rotated values, but MakerNotes having the original (now wrong) values.
I noticed that "RelatedImageWidth" and "RelatedImageHeight" just get deleted (i.e. not copied over), whatever I do.
I'm also assuming this restriction of MakerNotes "must instead be copied as a block" was code you added since version 5.32 (when it was being allowed).
P.S. The FAQs should be translated into warning messages generated within the tool/API, so that it tells the user why it didn't do what was asked. I have written lots of commercial software, and I quickly learned that users do not read the README, Release Notes or FAQs ;-)
P.P.S. I do see the tool has a few "Unknown" outputs for this camera:
MakerNotes : LensType : Unknown (-1)
MakerNotes : CanonModelID : Unknown (0x3490000)
Composite : LensID : Unknown 4-43mmP.P.P.S. Also, the whole group MPF cannot be copied over, though I'm not caring about it as there's really only one image in the rotated file anyway, so I can't see that I need it. I read your web page about this tag group and I think that's the right decision.
You really can't call SetNewValue() to do this. You have the correct syntax for SetNewValuesFromFile(). (either "makernotes:*" or "makernotes:all" should work). But you should also set the Make and Model, like this:
$exifTool->SetNewValuesFromFile($file, 'makernotes:*', 'make', 'model');You're right. You can't do this and modify individual values in one step. To do this, you would have to go through an intermediate image, but this could be an image in memory.
$exifTool->SetNewValuesFromFile($file, 'makernotes:*', 'make', 'model');
my $image;
$exifTool->WriteInfo($srcfile, \$image);
$exifTool->SetNewValue(); # clear previous new values
$exifTool->SetNewValue( ... );
$exifTool->WriteInfo(\$image, $dstfile);RelatedImageWidth/Height are unsafe tags. You must either copy these explicitly or set "Protected => 1" in the SetNewValuesFromFile() options when copying as a group.
Quote from: jmcrowther on May 25, 2013, 12:49:43 PM
I'm also assuming this restriction of MakerNotes "must instead be copied as a block" was code you added since version 5.32 (when it was being allowed).
No. You could never create individual makernotes tags. You could write them if they already existed, but you could never create them.
QuoteP.S. The FAQs should be translated into warning messages generated within the tool/API, so that it tells the user why it didn't do what was asked. I have written lots of commercial software, and I quickly learned that users do not read the README, Release Notes or FAQs ;-)
It would not be feasible (or, I think, desirable) to add a warning for every tag that wasn't written. (You set 48 WhiteBalance tags for example. Do you want 47 warning messages if only one gets written?)
QuoteP.P.S. I do see the tool has a few "Unknown" outputs for this camera:
MakerNotes : LensType : Unknown (-1)
MakerNotes : CanonModelID : Unknown (0x3490000)
Composite : LensID : Unknown 4-43mm
This CanonModelID was added in version 9.29. The other unknowns are normal for powershot cameras.
- Phil
Edit: Fixed code: Forgot to clear previous new values.
Thanks. It'll take me a bit of time to reconfigure my script. I'll let you know how it goes.
Rather than be too clever (which might bite me later), I decided to take a simple strategy of copying over all tags in one go, and write that out. then go back and correct the tags I know need changing.
I'm already seeing an "issue".
The original file has this (an extract, not all tags):
---- EXIF ----
XResolution : 180
YResolution : 180
ResolutionUnit : inches
XResolution (1) : 180
YResolution (1) : 180
ResolutionUnit (1) : inches
The rotated image created by Imager has no EXIF group tags, but does have these tags:
---- JFIF ----
JFIFVersion : 1.01
ResolutionUnit : None
XResolution : 1
YResolution : 1
I run just these commands (excluding error checking which I am doing):
my $cleanExifTool = new Image::ExifTool;
my $infoSetByFunction = $cleanExifTool->SetNewValuesFromFile($originalFilePath);
my $rc = $cleanExifTool->WriteInfo($temporaryFilePath, $finalFilePath);
Where $originalFilePath is the original photo file and $temporaryFilePath is the Imager file.
The "final" file end up with this:
---- JFIF ----
JFIFVersion : 1.01
ResolutionUnit (1) : inches
XResolution (1) : 180
YResolution (1) : 180
---- EXIF ----
XResolution : 180
YResolution : 180
ResolutionUnit : inches
XResolution (2) : 72
YResolution (2) : 72
ResolutionUnit (2) : inches
I have no concept of why tags are repeated in the original file (i.e. two instances with the same value), but my actual concern is why did one (last) instance get changed to "72" for XResolution and YResolution?
It's a nice feature that JFIF was corrected (that was one of the things I had on my list to correct in the next iteration), but it's bad that the EXIF group now has incorrect XResolution and YResolution.
How can I avoid this problem? I would be OK with having JFIF remain "bad" (value "1") since I can zap that later, but I don't know how to correct incorrect duplicate instances in EXIF group (i.e. 180 in one instance and 72 in the other instance -- SetNewValue doesn't allow to fix/target specific instances of the same tag name as far as I can figure out).
Quote from: jmcrowther on May 26, 2013, 05:21:44 PM
I have no concept of why tags are repeated in the original file (i.e. two instances with the same value), but my actual concern is why did one (last) instance get changed to "72" for XResolution and YResolution?
I suspect the 72 dpi is the thumbnail resolution (IFD1), which is fine. Do
exiftool -a -G1 FILE to see.
[quote[It's a nice feature that JFIF was corrected (that was one of the things I had on my list to correct in the next iteration), but it's bad that the EXIF group now has incorrect XResolution and YResolution.[/quote]
I don't think this is incorrect. A 180 dpi 160x120 pixel thumbnail would be tiny.
- Phil
What thumbnail? Is your tool calculating this 72 value and discarding the source value?
I don't think the destination file has a thumbnail, or at least I didn't specifically create it unless Imager does that by default.
I know nothing of file formats, so don't know how to interpret. Here's the output for the 3 files:
Original:
[IFD1] Compression : JPEG (old-style)
[IFD1] X Resolution : 180
[IFD1] Y Resolution : 180
[IFD1] Resolution Unit : inches
[IFD1] Thumbnail Offset : 5632
[IFD1] Thumbnail Length : 4327
Imager file has no IFD1
Final file:
[IFD1] Compression : JPEG (old-style)
[IFD1] X Resolution : 72
[IFD1] Y Resolution : 72
[IFD1] Resolution Unit : inches
[IFD1] Thumbnail Offset : 4968
[IFD1] Thumbnail Length : 4327
If a thumbnail is being copied over by the SetNewValuesFromFile(), that's not a good thing because it would have the wrong orientation. Might be better to exclude it from the copy (how?). That said, maybe I don't care since nothing I use would display it anyway.
Of course, the tool is discarding the MPF group entirely. I notice it says (in the original file):
---- MPF ----
MPFVersion : 0100
NumberOfImages : 2
MPImageFlags (1) : Dependent parent image
MPImageFormat (1) : JPEG
MPImageType (1) : Baseline MP Primary Image
MPImageLength (1) : 3759050
MPImageStart (1) : 0
DependentImage1EntryNumber (1) : 2
DependentImage2EntryNumber (1) : 0
MPImageFlags : Dependent child image
MPImageFormat : JPEG
MPImageType : Large Thumbnail (full HD equivalent)
MPImageLength : 322715
MPImageStart : 3759104
DependentImage1EntryNumber : 0
DependentImage2EntryNumber : 0
Do this to exclude the thumbnail from being copied:
$cleanExifTool->SetNewValuesFromFile($originalFilePath, '-thumbnailimage');
This is the only tag with a default write group of IFD1, so if you don't write this then ExifTool will not populate the other mandatory IFD1 tags with default values.
- Phil
I restricted the groups as well, so my final command is this:
SetNewValuesFromFile($originalFilePath, '*:*', '-ThumbnailImage')
Quote from: Phil Harvey on May 25, 2013, 12:58:38 PM
You really can't call SetNewValue() to do this. You have the correct syntax for SetNewValuesFromFile(). (either "makernotes:*" or "makernotes:all" should work). But you should also set the Make and Model, like this:
Actually I've tried
makernotes:* as tag argument for
SetNewValuesFromFile() but it didn't work (Image::ExifTool v10.37). Only
makernotes works fine. Would be nice if
makernotes:* and
makernotes:all are aliases for
makernotes just for consistency.
MakerNotes:* and MakerNotes have very different functionality. MakerNotes:* copies the makernotes tags individually (and hence won't create a makernote block if it doesn't already exist), and MakerNotes copies the makernotes as a block.
- Phil