- Welcome to ExifTool Forum.
ExifTool Forum
"Metadata R Us"
News:
2024-11-12: ExifTool 13.03 is now available
Recent posts
#51
Newbies / Re: If and or not condition no...
Last post by StarGeek - November 20, 2024, 12:07:27 PMYou'll get this error on other misnamed files. For example, a quick test resulted in
So the fact that exiftool can't write to AllDates safely has more priority than the rename command.
One option would be to separate them into two separate commands. One to make sure the extensions are all correct and another to write the time stamp. This would be the solution that doesn't require any manual input, though it would take longer if you were running it on a lot of files.
Or you could use -efile option which would result in a list of these problem files. Then you could use the two separate commands on just these files, passing the error file back to exiftool with the -@ (Argfile) option. Though this does break down in part three, as after the rename, the error list no longer has the correct names.
Highly edited example of the latter
Thinking about it, you could then edit the ErrorList.txt by removing all the extensions and replacing them with an asterisk. Example, file.jpg is actually a PNG. This gets listed in ErrorList.txt as file.jpg. Run the rename, and now it is file.png. Open the text file, search/replace ".jpg" with ".*". Now run the AllDates command.
Thinking further, the third step could be automated by using a command line Search/Replace like sed. On Windows, it looks like there's a PowerShell command to do this, or a sed port (see Msys2), or third party program such as Find And Replace Text <insert Beavis and Butt-Head laugh here>
Code Select
Error: Not a valid PNG (looks more like a JPEG)So the fact that exiftool can't write to AllDates safely has more priority than the rename command.
One option would be to separate them into two separate commands. One to make sure the extensions are all correct and another to write the time stamp. This would be the solution that doesn't require any manual input, though it would take longer if you were running it on a lot of files.
Or you could use -efile option which would result in a list of these problem files. Then you could use the two separate commands on just these files, passing the error file back to exiftool with the -@ (Argfile) option. Though this does break down in part three, as after the rename, the error list no longer has the correct names.
Highly edited example of the latter
Code Select
exiftool -efile ErrorList.txt '-FileName<FileModifyDate.$FileTypeExtension' '-AllDates<FileModifyDate#' /path/to/files/
exiftool '-FileName<FileModifyDate.$FileTypeExtension' -@ ErrorList.txt Thinking about it, you could then edit the ErrorList.txt by removing all the extensions and replacing them with an asterisk. Example, file.jpg is actually a PNG. This gets listed in ErrorList.txt as file.jpg. Run the rename, and now it is file.png. Open the text file, search/replace ".jpg" with ".*". Now run the AllDates command.
Thinking further, the third step could be automated by using a command line Search/Replace like sed. On Windows, it looks like there's a PowerShell command to do this, or a sed port (see Msys2), or third party program such as Find And Replace Text <insert Beavis and Butt-Head laugh here>
#52
Newbies / Matryoshka delete all metadata...
Last post by wohpt - November 20, 2024, 11:57:34 AMI see the commandline help offers no write support for Matryoshka (mkv). What other windows10 options are there from deleting all safe-to-delete metadata?
I started here with the delete all
https://exiftool.org/forum/index.php?topic=10479.0
I started here with the delete all
https://exiftool.org/forum/index.php?topic=10479.0
#53
The "exiftool" Application / Re: Understanding the htmlDump...
Last post by StarGeek - November 20, 2024, 11:33:43 AMPhil will have to respond, but I believe this paragraph from the Problems with current Metadata Standards-Tiff 6.0 is part of it
QuoteA significant problem of the 1992 TIFF 6.0 specification is that there is no way to distinguish an IFD (image file directory) offset from a simple integer value. As a result, new IFD's may not be created without risking corruption of the files by unaware software. This is not only a problem for proprietary maker notes which commonly use a TIFF IFD structure, but is also a problem for extensibility of TIFF-based RAW image formats (as demonstrated by the DNG 1.3 specification -- see below).
#54
The "exiftool" Application / Re: Problems setting Windows "...
Last post by StarGeek - November 20, 2024, 11:25:42 AMAnd here I was busy typing up a long response involving the intricacies of video UTC time vs local time.
If I had just looked a little closer I would have seen that problem.
Glad you figured it out.
If I had just looked a little closer I would have seen that problem.
Glad you figured it out.
#55
The "exiftool" Application / Re: Problems setting Windows "...
Last post by dpcran0119 - November 20, 2024, 11:09:49 AMI solved this. Syntax. Rookie mistake...
exiftool "-quicktime:CreateDate<FileCreateDate" "-quicktime:ModifyDate<FileCreateDate" "-filemodifydate<FileCreateDate" -api QuickTimeUTC -ext .mp4 -r
problem was with -apiQuickTimeUTC
had to change it to -api QuickTimeUTC
exiftool "-quicktime:CreateDate<FileCreateDate" "-quicktime:ModifyDate<FileCreateDate" "-filemodifydate<FileCreateDate" -api QuickTimeUTC -ext .mp4 -r
problem was with -apiQuickTimeUTC
had to change it to -api QuickTimeUTC
#56
The "exiftool" Application / Re: partial support of metadat...
Last post by StarGeek - November 20, 2024, 11:05:43 AMAre your keywords in IPTC:Keywords or in XMP:Subject?
Keywords can't be copied because JXL doesn't support the old IPTC IIM standard. You have to copy them from IPTC:Keywords into XMP:Subject. This can be done with the iptc2xmp.args args file (see arg files on Github).
If the keywords are in XMP:Subject, they should have been copied and that is what happened in my quick test.
As for City, it seems to me that it should be copied over, as it has the same name in XMP as it does in IPTC. But looking at the -v3 (-verbose3) output, it says
If it is in XMP:City, it isn't copied and gives the same message.
Using -All:All instead of -All will copy the City tag if it is in XMP. This relates to FAQ #9, "The tag locations change when I use -tagsfromfile to copy information".
Phil is currently away, so it will be about a week before he can respond to this. But the above args file will correctly copy City from the IPTC to the XMP tag.
Keywords can't be copied because JXL doesn't support the old IPTC IIM standard. You have to copy them from IPTC:Keywords into XMP:Subject. This can be done with the iptc2xmp.args args file (see arg files on Github).
If the keywords are in XMP:Subject, they should have been copied and that is what happened in my quick test.
As for City, it seems to me that it should be copied over, as it has the same name in XMP as it does in IPTC. But looking at the -v3 (-verbose3) output, it says
Code Select
Writing XMP-photoshop:City if tag exists.If it is in XMP:City, it isn't copied and gives the same message.
Using -All:All instead of -All will copy the City tag if it is in XMP. This relates to FAQ #9, "The tag locations change when I use -tagsfromfile to copy information".
Phil is currently away, so it will be about a week before he can respond to this. But the above args file will correctly copy City from the IPTC to the XMP tag.
#57
Developers / Re: Switches staying active us...
Last post by greybeard - November 20, 2024, 10:24:55 AMThanks - thats what I guessed - its not something that bothers me now I know how it works but took a long time to figure out
#58
Developers / Re: Switches staying active us...
Last post by StarGeek - November 20, 2024, 10:22:39 AMPhil is currently away until next week, so there will be a delay in responding to this.
#59
The "exiftool" Application / Problems setting Windows "Date...
Last post by dpcran0119 - November 20, 2024, 09:55:03 AMNot sure how to embed the photos into this body area..
I am running into problems with modifying the CreateDate and ModifyDate and setting them to the FileCreateDate on MP4 files that have been run through Handbrake or XMediaRecode. They are not straight out of a camera, but still reflect timezone info when I run
Goal is for create date, modifydate to equal filecreatedate as those drive the Windows field called "Date"/
In this test, Date = 11/19/2024 5:11PM
exiftool -time:all -api QuicktimeUTC -g1 -a -s M:\_Temp
This yields the difference in times for the file.
exiftool "-CreateDate<FileCreateDate" "-ModifyDate<FileCreateDate" "-filemodifydate<FileCreateDate" -timezone="-04:00" -apiQuickTimeUTC -ext .mp4 -r M:\_Temp
And I would expect the results to reflect the updated time to equal the FileCreateDate value for CreateDate and ModifyDate. But it is not.
also attempted were the following. First had same effect as above. Last, failed and no records were changed.
exiftool "-quicktime:CreateDate<FileCreateDate" "-quicktime:ModifyDate<FileCreateDate" "-filemodifydate<FileCreateDate" -apiQuickTimeUTC -ext .mp4 -r M:\_Temp
exiftool -P -wm w "-quicktime:time:all#<$FileCreateDate" -apiQuickTimeUTC -ext .mp4 -r M:\_Temp
I am not sure where these are going wrong. I am on Win11.
I am running into problems with modifying the CreateDate and ModifyDate and setting them to the FileCreateDate on MP4 files that have been run through Handbrake or XMediaRecode. They are not straight out of a camera, but still reflect timezone info when I run
Goal is for create date, modifydate to equal filecreatedate as those drive the Windows field called "Date"/
In this test, Date = 11/19/2024 5:11PM
exiftool -time:all -api QuicktimeUTC -g1 -a -s M:\_Temp
This yields the difference in times for the file.
exiftool "-CreateDate<FileCreateDate" "-ModifyDate<FileCreateDate" "-filemodifydate<FileCreateDate" -timezone="-04:00" -apiQuickTimeUTC -ext .mp4 -r M:\_Temp
And I would expect the results to reflect the updated time to equal the FileCreateDate value for CreateDate and ModifyDate. But it is not.
also attempted were the following. First had same effect as above. Last, failed and no records were changed.
exiftool "-quicktime:CreateDate<FileCreateDate" "-quicktime:ModifyDate<FileCreateDate" "-filemodifydate<FileCreateDate" -apiQuickTimeUTC -ext .mp4 -r M:\_Temp
exiftool -P -wm w "-quicktime:time:all#<$FileCreateDate" -apiQuickTimeUTC -ext .mp4 -r M:\_Temp
I am not sure where these are going wrong. I am on Win11.
#60
The "exiftool" Application / Understanding the htmlDump opt...
Last post by greybeard - November 20, 2024, 09:50:02 AMThe htmlDump option is potentially one of the most helpful ways of digging into image file metadata and showing the details of the EXIF and JPEG metadata.
When a tag for which the actual value data does not fit within the original 12 byte tag block is selected (highlighted in blue or purple when displayed by a suitable browser) this shows the group, group sequence, tag name, tag ID (in hex), format, size, value and up to 4 offsets (in hex).
Can someone explain the exact meaning of the offsets and how they relate to the value location within the image file?
The offsets are named: Value Offset, Actual Offset, Offset Base and File Offset and the number of offsets included varies depending on which type of image file is being viewed (such as jpg, raf, cr3, arw etc.)
JPG files and Canon cr3 files have Value Offset and File Offset. The Value Offset appears to show the offset from the TIFF header and the File Offset shows the offset from the start of the file.
Sony arw and Leica dng files have a single offset (Value Offset) and this shows the offset from the TIFF header which is also the offset from the start of the file.
Nikon nef files have blue highlighted tags which match the standard used for Leica dng and Sony arw but also have purple tags with Value Offset, Actual Offset and Offset Base. The Actual Offset is the sum of the Value Offset and Offset Base fields and indicates the value location within the file.
FujiFilm RAF files have blue and purple tags and all four offsets: Value Offset, Actual Offset, Offset Base and File Offset but I can't figure out a consistent way of using them to calculate the offset of the value within the image file.
I have only looked at a single image file from each type and haven't yet looked at variations from other cameras.
Is there an algorithm for using these offsets to locate the value within the file regardless of image file format?
When a tag for which the actual value data does not fit within the original 12 byte tag block is selected (highlighted in blue or purple when displayed by a suitable browser) this shows the group, group sequence, tag name, tag ID (in hex), format, size, value and up to 4 offsets (in hex).
Can someone explain the exact meaning of the offsets and how they relate to the value location within the image file?
The offsets are named: Value Offset, Actual Offset, Offset Base and File Offset and the number of offsets included varies depending on which type of image file is being viewed (such as jpg, raf, cr3, arw etc.)
JPG files and Canon cr3 files have Value Offset and File Offset. The Value Offset appears to show the offset from the TIFF header and the File Offset shows the offset from the start of the file.
Sony arw and Leica dng files have a single offset (Value Offset) and this shows the offset from the TIFF header which is also the offset from the start of the file.
Nikon nef files have blue highlighted tags which match the standard used for Leica dng and Sony arw but also have purple tags with Value Offset, Actual Offset and Offset Base. The Actual Offset is the sum of the Value Offset and Offset Base fields and indicates the value location within the file.
FujiFilm RAF files have blue and purple tags and all four offsets: Value Offset, Actual Offset, Offset Base and File Offset but I can't figure out a consistent way of using them to calculate the offset of the value within the image file.
I have only looked at a single image file from each type and haven't yet looked at variations from other cameras.
Is there an algorithm for using these offsets to locate the value within the file regardless of image file format?