Bug: Play .png file with relative path fails #1554
Comments
|
It probably has to do with the way photoshop handles different 'presets' when creating a new file. I noticed that if I work in the Photoshop preset "HDTV", pasting the content from the original image yields a much smaller file size when saving it. We're talking 14MB vs 300KB. Funnily enough, MediaInfo doesn't show differences between the files, apart from size. The smaller size works on versions 2.5. The bigger size only on older 2.3.x |
|
That failing png is strange, according to freeimage (the image loading library we use), it has 0 bytes per pixel. Which we/it doesn't know how to handle, so it gets rejected. When it plays with the solid background, that is because ffmpeg is able to play it, but it doesn't provide us the alpha channel when it does so. That ffmpeg was given a chance to load this image sounds like a separate bug. So I am leaning towards saying that this png is 'corrupt' or non-standard, and there isn't anything we can do to make this work. I don't know why it worked on older 2.3, perhaps the freeimage library got more strict and is now rejecting this weird image? |
|
It's weird because I tried to re-export it several times with different color profiles and got the same result. From the same file and creating a new 'project' as well. How can it be that Photoshop 2024 is creating corrupt .png files unless you start from a HDTV preset? Also, it happens with several other files like this, so it's not a one off or just with this combination of pixels. |
|
I wonder if photoshop is producing a "PNG 3rd Edition" or similar newer revision of png that freeimage/libpng doesnt know how to decode? |
|
FWIW this is what I am seeing on Linux with 2.4.0. I did use full path to play it: UPDATE And, I get the same result if I play it with relative path: However, if the black areas around the image are supposed to be transparent, then alpha does not work in either case.
|
|
Here's another example, in case it helps. Does the T19 file also fails to open on Ubuntu? Gimp on Windows opens them all no problem, and from those 14MB files it exports a valid 100KB file
Could be, but I cannot find any proof of that change, I am testing with this and some others like it: https://www.nayuki.io/page/png-file-chunk-inspector This tool told me about the Adobe 1998 color space of one of them, so that was one difference, but changing it to match the correct file didn't fix it.
@dimitry-ishenko download the .zip from the first post; the image shown was just a screenshot as a visual reference. |
|
@Sidonai-1 LOL then you can probably ignore my comments. I don't see a .zip attached to the first post though... |
I don't know why it was formatted like that at the bottom of the post Update: Now I managed to get proper (only #KB) .png files starting from a "custom 1920x1080" preset (without the HDTV label) but honestly I don't know how I managed that. |
|
Sorry to jump in - I just find this interesting - Windows 11 paint opens all of these just fine, with alpha, for some reference. |
Yeah Windows seems to have no problem at all with those. With the exception of VLC, which seems to suffer the same problem as Caspar 🫠 |
|
@Sidonai-1 All of them play just fine for me on Ubuntu 24.04 with CasparCG 2.4.0
|
|
Then perhaps this is a bug in/caused by libpng? All 3 cases are using freeimage ~3.18.0, so I think it is unlikely to be a bug there That would explain why gimp and image viewer won't open it for me either, they will all be using the same version of libpng |
Observed Behavior
On 2.4.x and 2.5 dev:
This png file with alpha fails to play if you use a relative path.
The same file plays normally with a full path, but it shows white background on screen consumer:
Some other png files don't exhibit this behaviour.
This one plays normally in both cases:
Here goes both examples:
Expected behaviour
It plays normally on 2.3.2
Environment
The text was updated successfully, but these errors were encountered: