ExifTool corrupts transparency of webps

Started by ww408, January 23, 2025, 01:57:08 AM

Previous topic - Next topic

ww408

I just added a title to a webp and it converted the transparency to black. Interestingly, while it shows black in the file mgr. thumbnail and embedded in a forum post, in feh, it's still transparent ("half-corrupt"?).

Phil Harvey

#1
Can you provide the original sample with a transparency, plus give the exact command-line and ExifTool version you are using?

- Phil

Edit: Never mind.  I've been able to reproduce this with samples from here and this command line:

exiftool -title=test FILE

Interestingly, the effect only occurs for the lossless-compressed image, not the lossy one (using the dice images).
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Phil Harvey

I've found and fixed this issue, and ExifTool 13.15 (just released) should solve the problem.

The issue occurs only when adding metadata to a non-extended lossless WebP image which uses an alpha mask.  The problem is that some rendering software (I use FireFox, and luckily it showed this effect) seems to ignore the alpha mask embedded in the lossless image data if the alpha flag isn't set in the extended header (which ExifTool must create when adding metadata to a non-extended WebP).  The solution was to set the alpha mask in the VP8X header according to the alpha-is-used hint in the VP8L lossless-image data stream.

You can repair any affected images by deleting the metadata that you wrote, then writing it back again using ExifTool 13.15.

Thanks for reporting this.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

ww408

You're welcome. I wasn't able to get to 3.15 using apt upgrade, so I downloaded the tarball. Your installation instructions are missing a critical step: getting the extracted ExifTool app into your $PATH. Is copying exiftool to /usr/bin sufficient?

Phil Harvey

So "sudo make install" doesn't put it in your path?  It should.  But if you have previously installed exiftool using a different method then it may come earlier in your path and you may have to uninstall it for the new version to be accessible in the path.

However, coping the new version (including files in the lib directory) to overwrite any older version is sufficient.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

ww408

I hastily ignored that step because the first line in the description is 'Note: The "make test" step is not required'.

I just installed it and ran apt upgrade exiftool to see if the new version was in my $PATH and got this error:

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 27238 (apt)

Have tried it multiple times...

Phil Harvey

I don't know what the problem is, but the work-around is to copy exiftool and the files in the 'lib' directory to overwrite the existing version.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

ww408

#7
I just tried uninstalling it, so I could reinstall it to make sure everything was proper and got this error:

Uninstall is unsafe and deprecated, the uninstallation was not performed.
Please check the list above carefully, there may be errors.
Remove the appropriate files manually.
Sorry for the inconvenience.


And I think $PATH gave priority to the version installed via my package mgr. I should have located the file and run it via the absolute link before I uninstalled it to see which version it was, but I just looked at the apt log and it says I removed version 12.57 (specifically, libimage-exiftool-perl, not sure what that means), but now when I use exiftool, it says v. 13.5.

I'd still like to uninstall and reinstall it, but I'm not sure what to make of that warning. Or mayber there are directory(s) I can copy onto this forum so someone can tell me if everything looks OK.

Quote from: Phil Harvey on January 23, 2025, 12:25:02 PMbut the work-around is to copy exiftool and the files in the 'lib' directory to overwrite the existing version.

Well, the new version is in /usr/local/bin along with 6 unrelated files... The previous version was in /usr/bin, I think...I know it wasn't in /usr/local/bin because I remember viewing it once and there were many other files, not 6.

Phil Harvey

Yes, "make uninstall" is deprecated for some packages, but it should safe for ExifTool because it doesn't have any installed dependencies.  But judging from the message it gave, maybe it no longer does anything.  Oh well.  This is the standard Perl module installer and I don't have much control over this.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).