Closed ServOKio closed 2 months ago
I don't know what "mine" is, but decodeImageFile will first attempt to decode the image based on the extension of the filename, and if that doens't work out, it will try to decode it via decodeImage, which just iterates through all of the decoders trying to find one that will work.
🤷♂️ It looks like "decodeImageFile" can't find it on its own, but if you specify the decoder, yes, everything works
findDecoderForNamedImage
finds the PngDecoder, but it is incorrect
You could also use decodeImage, which is probably on par with lookupMimeType for performance, and is what decodeImageFile uses when the expected decoder fails. I don't know why decodeImageFile isn't falling back to PNG as the attempted JPG decoder failed, unless you're using an older version of the library before that change went in.
findDecoderForNamedImage is just a niave name based lookup, it doesn't try to actually ensure the decoder is valid for the actual image data. I should probably have skipped adding these functions. People aren't very good about naming files.
You could also use decodeImage, which is probably on par with lookupMimeType for performance, and is what decodeImageFile uses when the expected decoder fails. I don't know why decodeImageFile isn't falling back to PNG as the attempted JPG decoder failed, unless you're using an older version of the library before that change went in.
That's right, I'm on version 4.1.7, decodeImageFile sees that the file name ends in png and decodes as png, but it's actually jpg so...yes
Anyway, thanks a lot, good luck 👋
Let's just imagine that the user renamed
.jpg
file to.png
and thendecodeImageFile
->findDecoderForNamedImage
gives an incorrect response and I get an errorMaybe it's better to try to read
mine
?