The apple/pear image is really neat! :nerd: I'm all for improving Spine, but I am still wondering if there is an actual problem you are having that you would like solved? Since test images are required it seems that you are pursuing this solely on principle? That's perfectly fine of course, but we have a lot to work on and try to prioritize based on users needs.
Spine loads all images using sRGB, eg:
Loading Image
If changed to use linear RGB then it's definitely wrong:
Loading Image
I did find that we are loading the image data, then applying PMA. You may be right that this is incorrect. It sounds logical, though it has never caused a noticeable problem. Do you have any test images that show PMA is incorrect? This would allow us to validate the fix. The images that Spine displays in the editor have PMA applied, so it should show any problems there. We have changed how PMA is applied in the editor to avoid problems. The texture packer has not yet been updated.
The ramp_srgb image has an sRGB chunk set to "perceptual":
Loading Image
That image should be rendered correctly by your browser as a black square. Spine loads and display it correctly, since it always uses sRGB:
Loading Image
The ramp_linear image has a gAMA chunk with 1:
Loading Image
Spine displays it incorrectly as a black square. The image loader is ignoring the gAMA chunk and blindly using sRGB:
Loading Image
The pear/apple image has a gAMA chunk with 0.02:
Loading Image
This has the same problem as the ramp_linear image, it is loaded using sRGB, not 0.02 gamma:
Loading Image
0.02 gamma is of course an extreme case. Using anything other than sRGB is likely rare. Photoshop Save for web
doesn't write a gAMA or sRGB chunk even when Convert to sRGB
is checked and Metadata
is "All". It doesn't seem possible to get Photoshop to write linear RGB at all. Also, unlike a web browser, Spine is consuming images the user provides (and likely created), so the user is in control of the images. Still, we'll look into respecting the gAMA chunk.
I think it would be good if: Spine showed things gamma correctly, and that TexturePacker also handles gamma correctly, and once it does so - offers a 16bit export mode.
We'll look at fixing up the texture packer to be sure there is not a problem applying PMA to sRGB. A test image showing a problem would be very helpful.
I haven't dug into output, but I believe I was wrong earlier
Spine's output is almost certainly sRGB.
I doubt many users would use 16bpp to avoid the imprecision at small RGB values using 8bpp. You are the first to ever bring this up, and even you don't seem to have a problem in a real world project. The imprecision is in small values. If PMA is what caused values to become small, then those pixels have low opacity and can barely be seen, so the tone being incorrect is unlikely to be noticeable.
If you aren't using PMA, AFAICT there isn't a problem. Likely only game projects want PMA and 16bpp wastes storage space, which is something most games want to avoid. Even for games, if it is really a problem then PMA can be avoided by using the Bleed
setting, which provides nearly identical blending (though affects batching if slot additive blending is used).
Spine is using JRE APIs to load images, so it is a convoluted process, but Spine should now respect PNG sRGB and gAMA chunks (it renders slightly differently on screen versus in the screenshot):
Loading Image
You'll need 3.7.20-beta (not yet released). For various reasons you'll also need the latest Spine launcher, version 3.7.20 (available in a few hours, download and reinstall Spine), else you'll see an apple even with 3.7.20-beta.
Now let's see who complains that their images look funny!
I'm not sure why Spine shows only a pear while Firefox and Chrome show a pear with a faint apple. Interestingly, Windows Image Viewer shows only a pear, but when I screenshot it, I get an image like Firefox/Chrome. :o Spine's screenshot looks different (dimmer), but doesn't show a faint apple.
FWIW, I noticed Slack, ImageGlass, and Windows thumbnails don't do gamma correction.