exiftool/exiftool

ExifTool meta information reader/writer

exiftool's Issues

the format of GPS/IMU CSV-format files

in 11.5.54 added support for geotagging from GPS/IMU CSV-format files. but what's the format of the csv file?

thanks.

ExifTool trips over SHORT-typed StripOffsets values in TIFF files

Hi,

ExifTool 12.00 seems to have a problem with StripOffsets pointers in TIFF files if they have type SHORT instead of LONG (both are permitted by the TIFF 6.0 spec).

Consider the attached files:

• stripoffsets-short-0.tif has three StripOffsets values of type SHORT (source)
• stripoffsets-long-0.tif is the same file with exactly one difference: the three StripOffsets values have type LONG

Writing some tag to these files (I used exiftool -ISO=42) results in these files:

• stripoffsets-short-1.tif is damaged, it has three StripByteCounts values (0 16448 8100, first one is zero?!) but only two StripOffsets values (248 8348); the file cannot be displayed by various viewers and exiftool -validate -warning -a issues matching warnings:
  • Wrong number of values in IFD0 0x0111 StripOffsets
  • Oversized IFD0 StripByteCounts (24548 bytes, but expected 24300)
• stripoffsets-long-1.tif is OK though

Any idea what's going wrong here?

Thanks,
Martin

Compacting XMP data

exiftool writes metadata to PNG and JPEG files in separate RDF objects grouped by their namespaces. Is there a historical reason for writing it in this format?

E.g. -rdf-ns1:tag1=Value1 -rdf-ns2:tag2=Value2 outputs something like this;

<rdf:RDF about="https://example.com/photo" xmlns:ns1="https://example.net/#">
  <ns1:tag1>Value1</ns1:tag1>
</rdf:RDF>
<rdf:RDF about="https://example.com/photo" xmlns:ns2="https://example.org/#">
  <ns2:tag2>Value2</ns2:tag2>
</rdf:RDF>

Would it be possible to switch to a compacted format instead?

<rdf:RDF about="https://example.com/photo"  xmlns:ns1="https://example.net/#" xmlns:ns2="https://example.org/#">
  <ns1:tag1>Value1</ns1:tag1>
  <ns2:tag2>Value2</ns2:tag2>
</rdf:RDF>

The two representations are technically identical but one adds less weight to the output files. The XMP specification uses the more compact form in almost all examples.

Add XMP crs:AutoTone tag

Would it be possible to add this undocumented tag?

It shows up in standalone XMP files used as Lightroom presets (created through this screen, or similar).

I'm putting the following in my .ExifTool_config:

%Image::ExifTool::UserDefined = (
    'Image::ExifTool::XMP::crs' => {
        AutoTone  => { Writable => 'boolean' },
    },
);

I would do a PR, but I'm not sure I know everything that needs to be updated (documentation, tests).

Thanks!

Writeable GPS tags in QuickTime MOV files

Consider this a feature request. It would be great to have write-able GPS tags for MOV files. I have ~500 phone videos that lost their original GPS metadata; I'd like to recreate.

I'll just subscribe to this issue on the off-chance you add this feature and close. Thank you!

https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/QuickTime.html

Trying to understand how this composite Lens ID field is formed

Hello

Someone edited a JPEG and set the lens manually, and asked a question about why RawTherapee shows an array of possible lens names whereas other programs/websites show only the lens he set.

RawTherapee derives its lens identification from ExifTool, and ExifTool shows the same composite Lens ID:

$ exiftool -G0 DSC00074-1.jpg | grep -ai lens
[EXIF]          Lens Make                       : Nikon
[EXIF]          Lens Model                      : Series E 100mm 1:2.8
[MakerNotes]    Lens Format                     : Unknown
[MakerNotes]    Lens Mount                      : Unknown
[MakerNotes]    Lens Zoom Position              : 0%
[MakerNotes]    Lens Type                       : E-Mount, T-Mount, Other Lens or no lens
[XMP]           Lens                            : Series E 100mm 1:2.8
[Composite]     Lens ID                         : Sony FE 100mm F2.8 STF GM OSS or Sony FE 70-200mm F2.8 GM OSS or Sony FE 70-200mm F2.8 GM OSS + 1.4X Teleconverter or Sony FE 70-200mm F2.8 GM OSS + 2X Teleconverter or Sigma 70-200mm F2.8 DG OS HSM | S

Could you help me understand how this composite is formed?

If it's based on a bunch of possible numerical lens ID values, how do I see those values?

Looking at /lib/Image/ExifTool/Sony.pm, the lenses in the composite ID map to:

• 32819
• 32830
• 33072
• 33073
• 50512
  Why are there so many hits, how does that work?

Thank you

Add write support for custom SlantRange 3px XMP tags

Cannot edit MicaSense Altum XMP tags because a config file for the custom XMP tags is not yet defined. I have attached a zipped single channel (green) tiff collected by the SlantRange 3px.

I need to edit these EXIF tags:

• Make
• Model

and these custom XMP tags:

• BandName
• CentralWavelength
• WavelengthFWHM
• RigName
• RigCameraIndex

SlantRangeTiff.zip

Writing metadata to .djvu files

I am trying to modify metadata for some books (lots of them) and currently, I am using ExifTool to handle all the pdf. However, I see that write capability to Djvu files is limited. I request for a write capability for DjVu files. I haven't used Perl, so I can help you with the testing part.

No notification of ExifTool releases

By the way, do you know why I do not get any notifications for exiftool releases despite watching the github project for "releases only"? I do that for dozens of projects and have never missed a notification. For exiftool I do not get any. Are you maybe suppressing notifications when adding new releases? (I doubt that, but I want to be sure...)

Originally posted by @bersbersbers in #9 (comment)

Hexadecimal number > 0xffffffff non-portable at Image-ExifTool-11.26/lib/Image/ExifTool/Writer.pl line 3223.

When running exiftool-11.26, fixing/redoing some jpegs, exitool (or rather perl on it's behalf) sometimes spews this warning:

Hexadecimal number > 0xffffffff non-portable at Image-ExifTool-11.26/lib/Image/ExifTool/Writer.pl line 3223.

In my case, it seems to be a minor cosmetic annoyance (only a warning in 64-bit perl), however I suspect on 32-bit systems it might be an actual problem.

I'm using perl on Ubuntu 18.04 with the official version retrieved from the exiftool homepage.

This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-linux-gnu-thread-multi
(with 67 registered patches, see perl -V for more detail)

The command line I was running (fix, remove thumbnail(s), properly set the exif serial numbers, if any, rewrite all + icc; based on the faqs on exiftool):

./exiftool -F -ifd1:all= -PreviewImage= '-exif:SerialNumber<SerialNumber' -overwrite_original -all= -tagsfromfile @ -all:all -unsafe -icc_profile  -ext jpg -r -q -q $HOME/cam-repair

Everything, besides those warning, seems to be fine.

DICOM string tags have a extra white space (and have even length)

Hi,
exiftool is awesome! One thing that I have noticed, however, is that DICOM tags often have a trailing space. Here's how to see that:

• Download ttfm.dcm from https://medistim.com/dicom/ (http://medistim.com/wp-content/uploads/2016/07/ttfm.dcm)
• Run exiftool.exe -php ttfm.dcm

This is what I am getting:

Array(Array(
  "SourceFile" => "C:/Users/me/Downloads/ttfm.dcm",
  "ExifToolVersion" => 11.26,
  "FileName" => "ttfm.dcm",
  "Directory" => "C:/Users/me/Downloads",
  "FileSize" => "341 kB",
  "FileModifyDate" => "2019:02:14 13:57:42+01:00",
  "FileAccessDate" => "2019:02:14 13:57:41+01:00",
  "FileCreateDate" => "2019:02:14 13:57:41+01:00",
  "FilePermissions" => "rw-rw-rw-",
  "FileType" => "DICOM",
  "FileTypeExtension" => "dcm",
  "MIMEType" => "application/dicom",
  "FileMetaInfoGroupLength" => 158,
  "FileMetaInfoVersion" => "0 1",
  "MediaStorageSOPClassUID" => "Ultrasound Multi-frame Image Storage",
  "MediaStorageSOPInstanceUID" => "2.16.840.1.114488.0.4.123489834087.1330071425.2",
  "TransferSyntaxUID" => "JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14-1)",
  "ImplementationClassUID" => "1.2.840.114236",
  "SpecificCharacterSet" => "ISO_IR 100",
  "ImageType" => "\\SECONDARY\\INTRAOPERATIVE ",
  "SOPClassUID" => "Ultrasound Multi-frame Image Storage",
  "SOPInstanceUID" => "2.16.840.1.114488.0.4.123489834087.1330071425.2",
  "StudyDate" => "2011:08:24",
  "SeriesDate" => "2011:08:24",
  "ContentDate" => "2011:08:24",
  "StudyTime" => "09:48:36.214743984",
  "SeriesTime" => "09:48:36.214743984",
  "ContentTime" => "10:04:51.214743816",
  "AccessionNumber" => "",
  "Modality" => "US",
  "Manufacturer" => "Medistim",
  "InstitutionName" => "Hospital Name ",
  "InstitutionAddress" => "Hospital Address or Department",
  "ReferringPhysicianName" => "",
  "StationName" => "VERIQ ",
  "StudyDescription" => "",
  "PerformingPhysicianName" => "CA Prof. Debus",
  "ManufacturersModelName" => "VeriQ C ",
  "RecommendedDisplayFrameRate" => "1 ",
  "PatientName" => "Femoral trombenarterectomy^Case Report: ",
  "PatientID" => "Case Report 1 ",
  "PatientBirthDate" => "",
  "PatientSex" => "M ",
  "PatientSize" => "0 ",
  "PatientWeight" => "0 ",
  "PatientComments" => "See case report on www.medistim.com ",
  "CineRate" => "1 ",
  "EffectiveDuration" => "1 ",
  "DeviceSerialNumber" => "0 ",
  "SoftwareVersion" => "3.3.0 RC0 built 02/23/12  09:50:45",
  "FrameTime" => 1000,
  "PreferredPlaybackSequencing" => 0,
  "SequenceOfUltrasoundRegions" => "",
  "StudyInstanceUID" => "2.16.840.1.114488.0.4.123489834087.1330071425.0",
  "SeriesInstanceUID" => "2.16.840.1.114488.0.4.123489834087.1330071425.1",
  "StudyID" => "",
  "SeriesNumber" => "1 ",
  "InstanceNumber" => "1 ",
  "PatientOrientation" => "",
  "Laterality" => "",
  "ImageComments" => "",
  "SamplesPerPixel" => 3,
  "PhotometricInterpretation" => "RGB ",
  "PlanarConfiguration" => 0,
  "NumberOfFrames" => " 1",
  "FrameIncrementPointer" => "0018,1063",
  "Rows" => 768,
  "Columns" => 1024,
  "BitsAllocated" => 8,
  "BitsStored" => 8,
  "HighBit" => 7,
  "PixelRepresentation" => "Unsigned",
  "LossyImageCompression" => "00",
  "PixelData" => "(Binary data 0 bytes, use -b option to extract)",
  "StartOfItem" => "(Binary data 347414 bytes, use -b option to extract)",
  "EndOfSequence" => ""
));

Take an extra-close look at this section:

  "PerformingPhysicianName" => "CA Prof. Debus",
  "ManufacturersModelName" => "VeriQ C ",
  "RecommendedDisplayFrameRate" => "1 ",
  "PatientName" => "Femoral trombenarterectomy^Case Report: ",
  "PatientID" => "Case Report 1 ",

It is remarkable that all of these strings have an even number of characters due to the extra space. Is that a coincidence?

Either way, the manual says

that trailing spaces are removed from extracted values for most output text formats,

so I believe this should be fixed.

Pentax AutoBracketing decoding on K-5, K-1

Using

$ ./exiftool -ver
11.38

on Debian 9, Pentax AutoBracketing is incorrectly decoded for Pentax K-5 and K-1, which both encode it consistently as below.

Setting exposure steps to 1/3EV, the value recorded by the camera is 8192 + number of EV steps, e.g. 8196 for 1.3EV bracketing. K-5 example output for 1/3EV setting, 1.3EV steps (example including extended bracketing, which is correctly decoded):

$ ./exiftool -v  /media/jens/K-5/DCIM/126_2504 IMGS9879.JPG |grep AutoBracketing  | | | 17) AutoBracketing = 8196 259
$ ./exiftool -G0 -AutoBracketing -ExposureBracketStepSize /media/jens/K-5/DCIM/126_2504/IMGS9879.JPG 
[MakerNotes]    Auto Bracketing                 : 8186.5 EV, WB-BA+3
[MakerNotes]    Exposure Bracket Step Size      : 1.3

Setting exposure steps to 1/2EV, the value recorded by the camera is 4096 + number of EV steps, e.g. 4099 for 1.5EV bracketing:

$ ./exiftool -v  /media/jens/K-1/DCIM/113_2504/IMGC2093.DNG |grep AutoBracket
  | | 17) AutoBracketing = 4099 0
$ ./exiftool -G0 -AutoBracketing -ExposureBracketStepSize /media/jens/K-1/DCIM/113_2504/IMGC2093.DNG
[MakerNotes]    Auto Bracketing                 : 4089.5 EV, No Extended Bracket

Btw., the K-1 doesn't have the Exposure Bracket Step Size nor Bracket Shot Number (which I was looking for in the first place) in the same place as previous models, nor could I identify any likely candidates.

Let me know if you need any examples.

DICOM IS (integer strings) are not parsed as integers

In DICOM, "InstanceNumber" => "1 " should probably be "InstanceNumber" => 1 (as an integer, not as a string).

Compare #9 for example data.

Some DICOM IS values still not parsed as integers

The fix for #10 is almost complete, seemingly parsing all-digit strings as integers now that trailing spaces are removed. However, the example data from #9 (http://medistim.com/wp-content/uploads/2016/07/ttfm.dcm) still has another edge case: "NumberOfFrames" => " 1",

This value is represented the same way by dcmdump:
(0028,0008) IS [ 1] # 2, 1 NumberOfFrames

Note that this is perfectly OK with the DICOM standard:

IS: A string of characters representing an Integer in base-10 (decimal), shall contain only the characters 0 - 9, with an optional leading "+" or "-". It may be padded with leading and/or trailing spaces. Embedded spaces are not allowed.

My interpretation is that " 1" should be converted to integer 1, too. I am not sure whether all leading spaces should be removed from all strings: one could for value representations such as IS or CS ("A string of characters with leading or trailing spaces (20H) being non-significant."), but one cannot for others such as ST ("It may be padded with trailing spaces, which may be ignored, but leading spaces are considered to be significant.").

http://dicom.nema.org/dicom/2013/output/chtml/part05/sect_6.2.html

Does exiftool have a dictionary of value representations for all tags?

exiftool switches height and width values

Running exiftool on a directory with tif images will rotate them counter clockwise, basically switching width and height.

exiftool -tagsfromfile profile.xmp -ext tif test_data/TIFF/

Before I forget, I am on a linux box running Ubuntu 18.

Add PDF 2.0 support

Since PDF 2.0 is now a thing I have been getting a bunch of errors in my processes using exiftool:

Detail: Error: Can't yet write PDF version 2.0

PDF 2.0 test files can be found here:
https://github.com/pdf-association/pdf20examples

Thanks for the great software!
~Skylar

PGP signature for application

Thank you Phil, and to all contributors, for providing and maintaining this incredibly useful tool!

My primary use of Exiftool is to strip out metadata of files that I will be putting online. Given how brilliantly your tool does this, I'm sure there must be other people who do the same!

I was just wondering whether you would be able to provide a pgp signature of the application for the security/privacy minded user?

Thanks Again! 👍

Why MPF data is readable but not writable?

I am trying to do something with Facebook 3D Photos and while I can extract the data with Exiftool I can't add it. MPF tag seems to be read only. Is there any reason for this limitation?

Warning: Bad IFD0 directory in HEIF/HEIC file

HI,

I am learning about Exif and HEIF files and I came a cross a file in the heif_conformance suite from Nokia that should contain Exif data but gives an error in exiftools:

$ exiftool -ver
11.94
$ exiftool -Exif:all C034.heic 
substr outside of string at /usr/share/perl5/Image/ExifTool.pm line 7054.
Warning: Bad IFD0 directory - C034.heic

The test file can be retrieved from here: https://github.com/nokiatech/heif_conformance/blob/master/conformance_files/C034.heic

Is the file wrong? Or is exiftool missing something?

Thanks, Antonio

unicode error in keywords option

when add unicode character in option keywords, exiftool will appear an error:

Warning: Some character(s) could not be encoded in Latin

for example:

exiftool -keywords="测试, hello" sample.jpg

Warning: Can't create EXIF. No primary item reference

Hello,

I'm trying to create HEIC files with FFMPEG and MP4Box and then update the metadata with ExifTool, but I'm getting Warning: Can't create EXIF. No primary item reference. This seems very similar to the issue you fixed in #37 (I was actually getting that issue first until I updated to the latest ExifTool).

Here are the commands I'm using to generate my HEIC file:
ffmpeg -i input.tif -vf "crop=trunc(iw/2)*2:trunc(ih/2)*2" -pix_fmt yuv420p -f hevc tmp.hvc
MP4Box -add-image tmp.hvc -ab heic -new output.heic

Based on your response in #37, I'll go ahead and email you a sample file.

And by the way, thanks a lot for the incredible software! I've enjoyed using exiftool for many many years.

Thank you!

Ability to update preview images in raw files

I had raised a query in exiv2 (#48) a few years ago asking if this was supported but they said no.

Does exiftool have any support to change/replace embedded previews in raw files like .nef files?

The discontinued Nikon capture nx2 was the only thing I was aware of that supported this and wonder if this can be supported or technically possible

Some video (AVI, MP4) and audio (MP3) metadata edition support

Hi! I would like to know why some format editing is not supported (AVI, MP4, MP3). Which are the obstacles to develop?

Thank you

ComponentsConfiguration tag in TIFF ExifIFD

Hi Phil,

I have a question regarding mandatory tags that "may be added automatically with default values when creating a new IFD" according to the ExifTool docs, particularly the ComponentsConfiguration tag in the TIFF ExifIFD.

Using ExifTool 12.01 I used exiftool -ISO=42 on an uncompressed TIFF file (see attached file uncompressed-0.tif, source) and on the same file with LZW compression applied (compressed-0.tif, created with ImageMagick convert -compress LZW), resulting in uncompressed-1.tif and compressed-1.tif, respectively.

Adding the ISO tag results in this newly created ExifIFD (same in uncompressed and compressed files):

[EXIF:ExifIFD]  ISO                             : 42
[EXIF:ExifIFD]  ExifVersion                     : 0232
[EXIF:ExifIFD]  ComponentsConfiguration         : Y, Cb, Cr, -
[EXIF:ExifIFD]  FlashpixVersion                 : 0100
[EXIF:ExifIFD]  ColorSpace                      : Uncalibrated

I am a little confused by the ComponentsConfiguration tag.

1. Should this tag really be included in the uncompressed TIFF file? If I am not mistaken the Exif 2.32 specification, page 83 reads like this tag is mandatory for compressed images but not allowed for uncompressed images. (On the other hand, the same spec, page 44 defines a default value for "RGB uncompressed" of R, G, B, -. So this is weird anyway.)
2. Is the default value Y, Cb, Cr, - appropriate? The files use PhotometricInterpretation "RGB" which made me wonder: I thought RGB and YCbCr are two different color models, so wouldn't R, G, B, - be preferable in this case? But I don't know much about color stuff, so I may be totally lost here. Grateful for any clarification! ;-)
3. ExifTool validation (exiftool -validate -warning -a) issues warnings for both uncompressed and compressed files: "ExifIFD tag 0x9101 ComponentsConfiguration is not allowed in TIFF". Huh?

Maybe you can enlighten me a little?

Thanks,
Martin

Missing TIFF tags flagged as required despite having default values

ExifTool version: 11.99

Running exiftool -validate -warning -a on the attached file (source) raises two warnings:

• Missing required TIFF IFD0 tag 0x0102 BitsPerSample
• Missing required TIFF IFD0 tag 0x0128 ResolutionUnit

However, this is a very simple bilevel (black/white) TIFF file where the default values for BitsPerSample (1) and ResolutionUnit (2 = inch) given in the TIFF 6.0 specification are appropriate. According to the spec (pages 21, 26) in this case it is permitted to omit these tags.

What do you think? Are these tags really required for (bilevel) TIFF files?

Thanks,
Martin

Nikon NEF MakerNote: D4 Crop information

These raw Nikon NEF files: https://www.photographyblog.com/reviews/nikon_d4_review/sample_images have resolution of 4992 x 3292, but need to be cropped to 4928 x 3280, the area is located 8 pixels form the left and 6 pixels form the top.

ExifTool can not detect this cropping information yet. Is there anybody, who could look into it and find this information in the file? I tried to look for it in all MakerNote entries, as both Big and Little-endian Uint16, but did not find it, so maybe it is encrypted somehow.

Writing of MPG files is not yet supported

I am using the tool to shift the create timestamp metadata of some .MPG files, but getting the following error;

======== MOV05461.MPG
Rewriting MOV05461.MPG...
  Error = Writing of MPG files is not yet supported
Error: Writing of MPG files is not yet supported - MOV05461.MPG

The command I am using is very simple;

./exiftool.exe "-AllDates+=0:0:445 13:06:00" -verbose *.MPG

Will the write feature be added soon? What other options do I have to achieve what I want?
Thanks

Lens Distortion info

This CR2 file stores raw data with "Lens distortion" (Rectilinear warp, Fisheye warp) - Straight lines (which don't go through the center) are not straight - https://i.imgur.com/pzErgWp.jpg.

When this CR2 image is converted into a DNG image with Adobe tool, the distortion parameters are added to the DNG file (in form of Opcode - WarpRectilinear), which allow the DNG viewer to "straighten" the image (when you convert this image to DNG and open it e.g. in Photopea.com, lines are straightened according to the Opcode - https://i.imgur.com/ZA9J4S3.png).

Do you thing such distortion parameters are present in a CR2 file (or could they be computed from the present parameters)? Or an extra database of lenses and their parameters is needed?

JSON keys not escaped

I noticed that when running exiftool on json files with -j -struct, the keys will not be escaped in the output which can create invalid JSON output.

Example:

test.json

{
  "transform": {
    "\\.\"": "\\.\""
  }
}

Exiftool produces:

> .\exiftool.exe test.json -j -struct
[{
  "SourceFile": "test.json",
  "ExifToolVersion": 11.80,
  "FileName": "test.json",
  "Directory": ".",
  "FileSize": "46 bytes",
  "FileModifyDate": "2019:12:21 22:15:20+01:00",
  "FileAccessDate": "2019:12:21 22:15:20+01:00",
  "FileCreateDate": "2019:12:21 21:56:09+01:00",
  "FilePermissions": "rw-rw-rw-",
  "FileType": "JSON",
  "FileTypeExtension": "json",
  "MIMEType": "application/json",
  "Transform": {
    "\."": "\\.\""
  }
}]

As you can see "\."" is invalid JSON as both \ and " are not escaped.

Sony lenses missing

Hey

RawTherapee uses ExifTool and I noticed that some Sony lenses are no longer identified correctly.

Sample raw file:
http://rawtherapee.com/shared/test_images/chicken.arw

The lens is identified correctly when I use ExifTool 11.55, 11.56 and current master (12.01) from the command line:

~/programs/code-exiftool $ git checkout 11.55
HEAD is now at 3574005 Update to 11.55
~/programs/code-exiftool $ ./exiftool ~/downloads/chicken.arw | grep "Sony FE 70-200mm F4 G OSS"
Lens Type 3                     : Sony FE 70-200mm F4 G OSS
Lens Type 2                     : Sony FE 70-200mm F4 G OSS
Lens ID                         : Sony FE 70-200mm F4 G OSS
~/programs/code-exiftool $ git checkout 11.56
Previous HEAD position was 3574005 Update to 11.55
HEAD is now at ce3280c Update to 11.56
~/programs/code-exiftool $ ./exiftool ~/downloads/chicken.arw | grep "Sony FE 70-200mm F4 G OSS"
Lens Type 3                     : Sony FE 70-200mm F4 G OSS
Lens Type 2                     : Sony FE 70-200mm F4 G OSS
Lens ID                         : Sony FE 70-200mm F4 G OSS
~/programs/code-exiftool $ git checkout master
Previous HEAD position was ce3280c Update to 11.56
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
~/programs/code-exiftool $ ./exiftool ~/downloads/chicken.arw | grep "Sony FE 70-200mm F4 G OSS"
Lens Type 3                     : Sony FE 70-200mm F4 G OSS
Lens Type 2                     : Sony FE 70-200mm F4 G OSS
Lens ID                         : Sony FE 70-200mm F4 G OSS

I found that the XML dump from ExifTool 11.55 has these lenses, while they are missing from 11.56 onward:

~/programs/code-exiftool $ git checkout 11.55
HEAD is now at 3574005 Update to 11.55
~/programs/code-exiftool $ xmlstarlet sel -T -t -m "taginfo/table/tag[@name='LensType']/values/key" -v "concat(@id,'       ',val)" -n < <(~/programs/code-exiftool/exiftool -listx -sony:all) | sort -fuV | grep -i "Sony FE 70-200mm F4 G OSS"
6553.25 Sony FE 70-200mm F4 G OSS
65535.25        Sony FE 70-200mm F4 G OSS
~/programs/code-exiftool $ git checkout 11.56
Previous HEAD position was 3574005 Update to 11.55
HEAD is now at ce3280c Update to 11.56
~/programs/code-exiftool $ xmlstarlet sel -T -t -m "taginfo/table/tag[@name='LensType']/values/key" -v "concat(@id,'       ',val)" -n < <(~/programs/code-exiftool/exiftool -listx -sony:all) | sort -fuV | grep -i "Sony FE 70-200mm F4 G OSS"
~/programs/code-exiftool $ git checkout master
Previous HEAD position was ce3280c Update to 11.56
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
~/programs/code-exiftool $ xmlstarlet sel -T -t -m "taginfo/table/tag[@name='LensType']/values/key" -v "concat(@id,'       ',val)" -n < <(~/programs/code-exiftool/exiftool -listx -sony:all) | sort -fuV | grep -i "Sony FE 70-200mm F4 G OSS"

LensType2 and LensType3 in master still list the lens but with a different ID: 32810 instead of 6553.25 or 65535.25.

Some source code grepping:

git checkout 11.55
HEAD is now at 3574005 Update to 11.55
grep -rni "sony fe 70-200mm f4" *
html/TagNames/Sony.html:1654:</tr><tr><td>6553.25</td><td>= Sony FE 70-200mm F4 G OSS</td>
html/TagNames/Sony.html:1896:</tr><tr><td>65535.25</td><td>= Sony FE 70-200mm F4 G OSS</td>
html/TagNames/Sony.html:4977:</tr><tr><td>32810</td><td>= Sony FE 70-200mm F4 G OSS</td>
html/TagNames/Minolta.html:609:</tr><tr><td>65535.25</td><td>= Sony FE 70-200mm F4 G OSS</td>
lib/Image/ExifTool/Sony.pm:111:    32810 => 'Sony FE 70-200mm F4 G OSS', #JR   # VX9126
lib/Image/ExifTool/Minolta.pm:569:   '65535.25' => 'Sony FE 70-200mm F4 G OSS',       #JR (32810 - SEL70200G)

git checkout 11.56
Previous HEAD position was 3574005 Update to 11.55
HEAD is now at ce3280c Update to 11.56
grep -rni "sony fe 70-200mm f4" *
html/TagNames/Sony.html:4762:</tr><tr><td>32810</td><td>= Sony FE 70-200mm F4 G OSS</td>
lib/Image/ExifTool/Sony.pm:111:    32810 => 'Sony FE 70-200mm F4 G OSS', #JR   # VX9126

Could someone shed some light on what's going on?

exiftool does not read full metadata from WebP

Doing some testing with WebP files converted using ImageMagick, I note that exiftool will not read all the same metadata that imagemagick will.

$ exiftool imgh.webp 
ExifTool Version Number         : 11.97
File Name                       : imgh.webp
Directory                       : .
File Size                       : 2.1 MB
File Modification Date/Time     : 2020:04:24 16:02:30-07:00
File Access Date/Time           : 2020:04:28 09:52:38-07:00
File Inode Change Date/Time     : 2020:04:28 09:54:18-07:00
File Permissions                : rw-r--r--
File Type                       : WEBP
File Type Extension             : webp
MIME Type                       : image/webp
VP8 Version                     : 0 (bicubic reconstruction, normal loop)
Image Width                     : 3024
Horizontal Scale                : 0
Image Height                    : 4032
Vertical Scale                  : 0
Image Size                      : 3024x4032
Megapixels                      : 12.2

$ identify -verbose imgh.webp
Image: imgh.webp
  Format: WEBP (WebP Image Format)
  Mime type: image/webp
  Class: DirectClass
  Geometry: 3024x4032+0+0
  Resolution: 72x72
  Print size: 42x56
  Units: PixelsPerInch
  Colorspace: sRGB
  Type: TrueColor
  Base type: Undefined
  Endianess: Undefined
  Depth: 8-bit
  Channel depth:
    Red: 8-bit
    Green: 8-bit
    Blue: 8-bit
  Channel statistics:
    Pixels: 12192768
    Red:
      min: 0  (0)
      max: 255 (1)
      mean: 134.928 (0.529131)
      standard deviation: 66.8698 (0.262235)
      kurtosis: -1.13706
      skewness: -0.104765
      entropy: 0.989812
    Green:
      min: 0  (0)
      max: 255 (1)
      mean: 121.977 (0.478343)
      standard deviation: 62.1632 (0.243777)
      kurtosis: -0.827437
      skewness: 0.0323675
      entropy: 0.986513
    Blue:
      min: 0  (0)
      max: 255 (1)
      mean: 101.862 (0.399457)
      standard deviation: 65.3561 (0.256299)
      kurtosis: -0.800568
      skewness: 0.33422
      entropy: 0.980652
  Image statistics:
    Overall:
      min: 0  (0)
      max: 255 (1)
      mean: 119.589 (0.468977)
      standard deviation: 64.7964 (0.254103)
      kurtosis: -0.991201
      skewness: 0.0849857
      entropy: 0.985659
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
    red primary: (0.64,0.33)
    green primary: (0.3,0.6)
    blue primary: (0.15,0.06)
    white point: (0.3127,0.329)
  Matte color: grey74
  Background color: white
  Border color: srgb(223,223,223)
  Transparent color: none
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 3024x4032+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: Undefined
  Orientation: TopLeft
  Convex hull: 0,0 3023,0 3023,4030 3022,4031 0,4031 0,0 
  Minimum bounding box: 3023,0 3023,4031 4.54747e-13,4031 2.0792e-13,0 
  Profiles:
    Profile-exif: 2320 bytes
  Properties:
    date:create: 2020-04-28T16:54:18+00:00
    date:modify: 2020-04-24T23:02:30+00:00
    exif:ApertureValue: 54823/32325
    exif:BrightnessValue: 59452/8295
    exif:ColorSpace: 65535
    exif:ComponentsConfiguration: 1, 2, 3, 0
    exif:DateTime: 2020:04:19 10:30:34
    exif:DateTimeDigitized: 2020:04:19 10:30:34
    exif:DateTimeOriginal: 2020:04:19 10:30:34
    exif:ExifOffset: 210
    exif:ExifVersion: 48, 50, 51, 49
    exif:ExposureBiasValue: 0/1
    exif:ExposureMode: 0
    exif:ExposureProgram: 2
    exif:ExposureTime: 1/312
    exif:Flash: 24
    exif:FlashPixVersion: 48, 49, 48, 48
    exif:FNumber: 9/5
    exif:FocalLength: 17/4
    exif:FocalLengthIn35mmFilm: 26
    exif:GPSAltitude: 277808/5225
    exif:GPSAltitudeRef: 0
    exif:GPSDateStamp: 2020:04:19
    exif:GPSDestBearing: 227042/3261
    exif:GPSDestBearingRef: M
    exif:GPSHPositioningError: 177928/8353
    exif:GPSImgDirection: 227042/3261
    exif:GPSImgDirectionRef: M
    exif:GPSInfo: 2038
    exif:GPSLatitude: 45/1, 32/1, 1499/100
    exif:GPSLatitudeRef: N
    exif:GPSLongitude: 122/1, 38/1, 2221/100
    exif:GPSLongitudeRef: W
    exif:GPSSpeed: 35602/14013
    exif:GPSSpeedRef: K
    exif:LensMake: Apple
    exif:LensModel: iPhone 11 Pro back triple camera 4.25mm f/1.8
    exif:LensSpecification: 807365/524263, 6/1, 9/5, 12/5
    exif:Make: Apple
    exif:MakerNote: 65, 112, 112, 108, 101, 32, 105, 79, 83, 0, 0, 1, 77, 77, 0, 26, 0, 1, 0, 9, 0, 0, 0, 1, 0, 0, 0, 11, 0, 2, 0, 7, 0, 0, 2, 46, 0, 0, 1, 76, 0, 3, 0, 7, 0, 0, 0, 104, 0, 0, 3, 122, 0, 4, 0, 9, 0, 0, 0, 1, 0, 0, 0, 1, 0, 5, 0, 9, 0, 0, 0, 1, 0, 0, 0, 177, 0, 6, 0, 9, 0, 0, 0, 1, 0, 0, 0, 175, 0, 7, 0, 9, 0, 0, 0, 1, 0, 0, 0, 1, 0, 8, 0, 10, 0, 0, 0, 3, 0, 0, 3, 226, 0, 12, 0, 10, 0, 0, 0, 2, 0, 0, 3, 250, 0, 13, 0, 9, 0, 0, 0, 1, 0, 0, 0, 21, 0, 14, 0, 9, 0, 0, 0, 1, 0, 0, 0, 4, 0, 16, 0, 9, 0, 0, 0, 1, 0, 0, 0, 1, 0, 17, 0, 2, 0, 0, 0, 37, 0, 0, 4, 10, 0, 20, 0, 9, 0, 0, 0, 1, 0, 0, 0, 10, 0, 23, 0, 9, 0, 0, 0, 1, 2, 80, 32, 0, 0, 25, 0, 9, 0, 0, 0, 1, 0, 0, 0, 2, 0, 26, 0, 2, 0, 0, 0, 6, 0, 0, 4, 48, 0, 31, 0, 9, 0, 0, 0, 1, 0, 0, 0, 0, 0, 32, 0, 2, 0, 0, 0, 37, 0, 0, 4, 54, 0, 33, 0, 10, 0, 0, 0, 1, 0, 0, 4, 92, 0, 35, 0, 9, 0, 0, 0, 2, 0, 0, 4, 100, 0, 37, 0, 9, 0, 0, 0, 1, 0, 0, 0, 134, 0, 38, 0, 9, 0, 0, 0, 1, 0, 0, 0, 3, 0, 39, 0, 10, 0, 0, 0, 1, 0, 0, 4, 108, 0, 40, 0, 9, 0, 0, 0, 1, 0, 0, 0, 1, 0, 43, 0, 2, 0, 0, 0, 37, 0, 0, 4, 116, 0, 0, 0, 0, 98, 112, 108, 105, 115, 116, 48, 48, 79, 17, 2, 0, 50, 1, 240, 0, 101, 1, 226, 1, 179, 0, 147, 0, 152, 0, 231, 0, 35, 1, 5, 1, 240, 1, 214, 1, 24, 2, 143, 2, 95, 2, 71, 2, 107, 1, 249, 0, 4, 1, 48, 1, 147, 0, 173, 0, 192, 0, 220, 0, 60, 1, 72, 1, 28, 2, 216, 1, 225, 1, 56, 2, 83, 2, 198, 1, 57, 1, 216, 0, 201, 0, 174, 0, 104, 0, 251, 0, 165, 0, 194, 0, 117, 1, 136, 1, 59, 2, 249, 1, 239, 1, 206, 1, 166, 1, 43, 1, 222, 0, 215, 0, 187, 0, 112, 0, 200, 0, 150, 0, 156, 0, 194, 0, 17, 1, 106, 1, 222, 1, 203, 1, 208, 1, 96, 1, 230, 0, 103, 0, 46, 1, 214, 0, 171, 0, 174, 0, 154, 0, 185, 0, 183, 0, 193, 0, 175, 0, 235, 0, 63, 1, 71, 1, 14, 1, 208, 0, 101, 0, 98, 0, 219, 0, 151, 0, 129, 0, 207, 0, 246, 0, 176, 0, 200, 0, 152, 0, 165, 0, 94, 0, 166, 0, 218, 0, 254, 0, 29, 1, 153, 0, 116, 0, 9, 1, 152, 0, 144, 0, 176, 0, 153, 0, 150, 0, 159, 0, 155, 0, 193, 0, 108, 0, 148, 0, 172, 0, 173, 0, 229, 0, 149, 0, 86, 0, 209, 0, 126, 0, 151, 0, 124, 0, 107, 0, 148, 0, 115, 0, 165, 0, 193, 0, 129, 0, 139, 0, 169, 0, 178, 0, 243, 0, 105, 0, 69, 0, 206, 0, 119, 0, 119, 0, 117, 0, 111, 0, 134, 0, 109, 0, 140, 0, 178, 0, 151, 0, 124, 0, 160, 0, 172, 0, 233, 0, 102, 0, 59, 0, 239, 0, 156, 0, 133, 0, 124, 0, 137, 0, 136, 0, 115, 0, 117, 0, 140, 0, 179, 0, 113, 0, 151, 0, 161, 0, 218, 0, 96, 0, 63, 0, 179, 0, 166, 0, 149, 0, 124, 0, 129, 0, 112, 0, 139, 0, 139, 0, 102, 0, 200, 0, 173, 0, 255, 0, 25, 1, 5, 1, 81, 0, 65, 0, 90, 0, 141, 0, 143, 0, 114, 0, 107, 0, 77, 0, 143, 0, 115, 0, 92, 0, 194, 0, 141, 0, 91, 0, 96, 0, 104, 0, 74, 0, 72, 0, 92, 0, 164, 0, 149, 0, 118, 0, 87, 0, 106, 0, 118, 0, 101, 0, 92, 0, 173, 0, 154, 0, 63, 0, 61, 0, 68, 0, 66, 0, 87, 0, 164, 0, 169, 0, 157, 0, 134, 0, 86, 0, 130, 0, 195, 0, 91, 0, 78, 0, 130, 0, 187, 0, 74, 0, 145, 0, 60, 2, 69, 1, 56, 1, 178, 0, 80, 0, 240, 0, 86, 0, 66, 0, 113, 0, 137, 0, 62, 0, 60, 0, 88, 0, 124, 0, 77, 0, 58, 1, 206, 3, 13, 3, 12, 2, 103, 0, 128, 0, 233, 0, 80, 0, 68, 0, 149, 0, 71, 0, 66, 0, 60, 0, 52, 0, 42, 0, 43, 0, 183, 1, 171, 3, 244, 2, 250, 2, 0, 8, 0, 0, 0, 0, 0, 0, 2, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 12, 98, 112, 108, 105, 115, 116, 48, 48, 212, 1, 2, 3, 4, 5, 6, 7, 8, 85, 102, 108, 97, 103, 115, 85, 118, 97, 108, 117, 101, 89, 116, 105, 109, 101, 115, 99, 97, 108, 101, 85, 101, 112, 111, 99, 104, 16, 1, 19, 0, 4, 126, 194, 2, 65, 229, 238, 18, 59, 154, 202, 0, 16, 0, 8, 17, 23, 29, 39, 45, 47, 56, 61, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 63, 255, 255, 211, 219, 0, 2, 76, 10, 255, 255, 192, 35, 0, 0, 71, 251, 255, 255, 201, 139, 0, 0, 119, 2, 0, 0, 15, 191, 0, 0, 1, 0, 0, 0, 37, 39, 0, 0, 1, 0, 57, 51, 55, 49, 68, 57, 68, 53, 45, 67, 57, 54, 55, 45, 52, 66, 51, 68, 45, 57, 52, 54, 55, 45, 68, 65, 65, 51, 55, 70, 52, 70, 69, 57, 54, 54, 0, 0, 113, 57, 48, 48, 110, 0, 69, 66, 69, 54, 48, 53, 50, 52, 45, 68, 49, 56, 51, 45, 52, 65, 53, 48, 45, 56, 49, 69, 66, 45, 69, 49, 68, 52, 51, 67, 50, 53, 66, 66, 67, 66, 0, 0, 0, 0, 114, 53, 0, 0,
    exif:MeteringMode: 5
    exif:Model: iPhone 11 Pro
    exif:OffsetTime: -07:00
    exif:OffsetTimeDigitized: -07:00
    exif:OffsetTimeOriginal: -07:00
    exif:PhotographicSensitivity: 32
    exif:PixelXDimension: 4032
    exif:PixelYDimension: 3024
    exif:SceneCaptureType: 0
    exif:SceneType: 1
    exif:SensingMethod: 2
    exif:ShutterSpeedValue: 159911/19296
    exif:Software: 13.3.1
    exif:SubjectArea: 2002, 1505, 2213, 1324
    exif:SubSecTimeDigitized: 199
    exif:SubSecTimeOriginal: 199
    exif:WhiteBalance: 0
    exif:YCbCrPositioning: 1
    minimum-bounding-box:_p: 0,0
    minimum-bounding-box:_q: 3023,0
    minimum-bounding-box:_v: 3022,4031
    minimum-bounding-box:angle: 0
    minimum-bounding-box:area: 1.21857e+07
    minimum-bounding-box:height: 3023
    minimum-bounding-box:unrotate: -0
    minimum-bounding-box:width: 4031
    signature: ef114da02fdd8fd7e4e96c5c914fde7805520175774043201c16940a2238259c
    unknown: 2
  Artifacts:
    verbose: true
  Tainted: False
  Filesize: 2.11137MiB
  Number pixels: 12.1928M
  Pixels per second: 47.0556MP
  User time: 0.260u
  Elapsed time: 0:01.259
  Version: ImageMagick 7.0.10-7 Q16 x86_64 2020-04-20 https://imagemagick.org

imgh.webp.zip

Add write support for custom MicaSense Altum XMP tags

Cannot edit MicaSense Altum XMP tags because a config file for the custom XMP tags is not yet defined.

Running exiftool with the subprocess module

The problem is when I pass the newly created path instead of the original image path to the get_embedded function. But I need of new path, I don't know what to do, any suggestion? Thanks ;)

Code:

import io
from PIL import Image
import subprocess
import pathlib
import cv2

im1 = Image.open(pathlib.Path('input/FLIR2705.jpg'))  

im1 = im1.save('geeks.jpg')
print(im1)

def get_embedded(path):

    img_bytes = subprocess.check_output([
        "exiftool", "-EmbeddedImage", "-b", path
    ])

    print(type(img_bytes))

    img_stream = io.BytesIO(img_bytes)

    #print(img_stream.read())
    img = Image.open(img_stream)

    print(img)
    return img

get_embedded('geeks.jpg')

Error:

Traceback (most recent call last):
  File "/home/helena/Documents/LAR_Celesc/robocelesc_backend/w.py", line 39, in <module>
    get_embedded('geeks.jpg')
  File "/home/helena/Documents/LAR_Celesc/robocelesc_backend/w.py", line 34, in get_embedded
    img = Image.open(img_stream)
  File "/home/helena/Documents/LAR_Celesc/robocelesc_backend/fenv/lib/python3.7/site-packages/PIL/Image.py", line 2590, in open
    % (filename if filename else fp))
OSError: cannot identify image file <_io.BytesIO object at 0x7f28a1f23f50>

Support for WAV

Is it planned to be able to tag WAV audio files in the future? That would be a very good feature, since there seems to be no library that supports the correct and error-free tagging of wav files via CLI.

Exiftool does nothing

Hello,
I have downloaded "exiftool-11.37.zip" from this page and extracted file "exiftool(-k).exe"
but when I execute the exiftool(-k).exe, it does nothing. After execution, it returns immediatelly
(edit: the console closes immediatelly too).
Older versions have the same behaviour (tested on version from 6.9.2012)
Behaviour seems to be independed of command line parameters (it seems something goes to wrong before cmdline processing).
Errorlevel is not set.
Windows version: Win 7 Enterprise SP1 64bit.

-TagsFromFile -Description inserts zTXt data after IDAT

Im currently trying to automate the process of copying a zTXt chunk from one file to another file.
For this im using the command:

exiftool.exe -z -TagsFromFile D:\path\to\file\areas.dmi -Description D:\path\to\file\areas.dmi.new

This results in the zTXt being copied to the new file but after the IDAT chunks.

.dmi is format used by a old game engine called Byond but its literally just a png file with zTXt Keyword "Description" being used to associate the image data with sprites in game.
However if the zTXt chunk comes after the IDAT chunks the game engine fails to read the file.

Original file seen by the programm TweakPNG:

My modified file to which I want to add the zTXt tag after using the mentioned command:

The sRGB, gAMA etc. comes from me and I want the zTXt chunk somewhere between IHDR and IDAT

I read that in earlier version you had to use PNGEarlyXMP for exiftool to write the data before IDAT but apparently in newer versions this should happen automatically.

Im using exiftools version 11.62.

Copying metadata from MP4 does not seem to update target file metadata

I am trying to copy creation date from one MP4 file to another using several ways:

exiftool -tagsFromFile video.mp4 -MediaCreateDate videoNEW.mp4
exiftool -tagsFromFile video.mp4 videoNEW.mp4
exiftool -all= -tagsfromfile video.mp4 -exif:all videoNEW.mp4

I always get:

1 image files updated

However, the creation date in the target file (videoNEW.mp4) remains unchanged.
I wonder if I am doing something wrong. I read through the documentation.
Thanks for your help!

Rotation info in a NEF file

Hi, when I process the attached NEF file with exiftool, it detects a Rotation: 270. I need to programmatically extract this information form a file, but can not find it anywhere (not in Shot Info, neither in IPTC data, neither in XMP, neither in Exif 0xbc02). Where did Exiftool find it?
portrait.zip

Nikon D850 AF points data

When the focus mode is phase detect, the focus point cannot be saved by exiftool.

For example in this file: image
The PrimaryAFPoint tag value is C12. Changing this tag with ExifTool does not change the focus point by viewing in Nikon Capture NX-D so the active focus point is saved elsewhere.
I can't find AF data in any other tag, does anyone have any idea?

OOXML File Type Resolution

Context: SheetJS/sheetjs#1637

https://github.com/exiftool/exiftool/blob/master/lib/Image/ExifTool/ZIP.pm#L459

            if (not $status and $buff =~ /ContentType\s*=\s*(['"])([^"']+)\.main(\+xml)?\1/) {

This matches the first instance, which leads to false positives in files that SheetJS generates since we write the Default block first:

  <Default Extension="xml" ContentType="application/xml"/>
  <Default Extension="bin" ContentType="application/vnd.ms-excel.sheet.binary.macroEnabled.main"/>

The "right" way to do it is to look at the _rels/.rels file to determine the main xml. A mostly correct and simpler approach would scan specifically for xl/workbook.xml / word/document.xml / ppt/presentation.xml and determine type based on the ContentType of that specific entry

Fix black level detection for Canon EOS 1000D

When you open this image in ExifTool, it says, that the Black Level is 1024.

However, when I parse the picture data, it is necessary to use a Black Level 255, for the picture to make sense. Also, in this database , Canon EOS 1000D has a black level of 255.

Is it possible to make ExifTool read black level 255 from this photo?

What does "Missing expected box" mean?

I generated a HEIC file with the libheif's included heif-enc utility. When I try to copy over the meta data from the original PNG file like so...

exiftool -overwrite_original_in_place -tagsFromFile input.tif output.heic

... I get the following warning:

Warning: Can't create EXIF. Missing expected box - output.heic
    0 image files updated

I tried it with a HEIC that was generated with sips and it worked as expected. However, I want to use the 10-bit color-depth functionality of heif-enc, so using sips is not an option. What does this warning tell me? Is it a bug in exiftool or libheif?

OS: Mac OS 10.15.3
Exiftool: 11.85
Libheif: 1.6.2

Wrong MIME type of .ps files

When getting the metadata of a .ps file, it always returns application/x-font-type1 as its MIME type.
It is expected to return application/postscript, can you add support to it?

Prevent rational calculation from taking place when writing value

I'm using exiftool to annotate PDF invoices with information extracted from the documents. One of the attributes I'm writing is the Invoice Number which is supposed to be an arbitrary string. The problem happens when this value happens to be two numbers separated by a slash (e.g. 2020/0042). In this case exiftool calculates the flowing point value of the rational number and stores that in the metadata.

Is there a way to avoid this type of calculation? I tried setting the type of the attribute in the config explicitly to string but that didn't help. I also tried quoting the value or escaping the slash, but those also changed the value which I would like to avoid.

Migration to organization

It is possible to migrate the personal account to organization?
https://help.github.com/articles/converting-a-user-into-an-organization/

STDOUT vs. STDERR for "image files created" message

Hi Phil,

ExifTool (on Linux/Bash) seems to choose different output streams for messages depending on the input format.

• The command exiftool a.jpg -Subject=foo writes "1 image files created" to STDOUT.
• The command exiftool a.jpg -json=meta.json writes the same answer to STDERR. (FTR, meta.json contains [{ "Subject": "foo" }].)

Is this intentional?

Cheers,
Martin

Olympus Live Composite mode and 0x101c

Hi, I recently diffed some ORF files to find information related to the Live Composite feature (discussion here), before realizing that a recent commit had addressed this. Just thought it was worth mentioning that in the process I noticed that using Live Composite mode on my E-PL7 creates a similar value in the "Multiple Exposure Mode" tag as it does in the "Stacked Image" tag already reported:

0x101c Multiple Exposure Mode  : 1 16
0x0804 Stacked Image           : 1 16

request: implement -- (end of options)

please implement -- end of options
so exiftool can accept filenames beginning with hyphen

% exiftool -ver
11.84

% exiftool -file.jpg 
Invalid TAG name: "file.jpg"
No file specified

% exiftool -- -file.jpg 
Unknown option --

"The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character." –POSIX Specification

of course this means giving up on the following feature
(but it's not clear to me how it's useful)

"Contrary to standard practice, options may appear after 
source file names on the exiftool command line."

in any case
thanks for sharing your software!

Example/Use case: process files older than N days

I am trying to get around a conditional expression that will process files older than 30 days.

I think it is a very interesting use case that could be documented as an example. The use case is to move old photos out of the phones and send them to a photo application with the help of Syncthing.

But my perl-fu is very very weak. I am arriving to something like:

time()-302460*60 > $createDate

would something like that work? is createDate a timeStamp in seconds or a string?

In the documentation there are some date comparison samples but I suspect it is actually strings been compared, is that correct?

How could I implement this conditional with exiftool?

Save binary data as base64 to CSV

To save binary data as base64 with json one can use -b with -j. But -b and -csv are incompatible. Can't we make them compatible the way it is with json?

Alternatively, if there is some deep incompatibility I'm not aware of, perhaps there could be a way to remove all binary data from -csv, because when exporting all the data as of today, the generated csv is invalid.