When I upgraded from 3.6 to the 3.7 version of Spine, projects had discolorations in their sprites, and retained these discolorations on export. Is there any fix for this? I couldn't find anything in the settings menu about it.
3.7 project discoloration
- Bearbeitet
Hello, could you send us the problematic project to contact@esotericsoftware.com mentioning this thread, please?
It's not project specific, it applies to all projects (except spineboy)
With a fresh project I imported a random image and still found it discoloured
Just to be sure, did you save these images in RGB or CMYK color space? this behavior seems to be similar to the one that happens with CMYK, while you should be saving them in RGB before importing them in Spine.
All of the images are in RGB and load fine in 3.6, the only difference I know of is that I am opening them in 3.7 instead of 3.6
There was a change from 3.6 to 3.7 in color management: Texture packer - sRGB?
According to the posts, Spine now respects the gAMA and sRGB PNG chunks.
Are you using the PhotoshopToSpine export script or some custom/manual settings that might correspond to the ones in the thread maybe?
The first gifs I uploaded were using the GIMP Export To Spine script, the second set of images is using paintdotnet png export
It would help if you can provide an image that loads incorrectly, so we can see the problem firsthand. You shouldn't be seeing incorrect colors in Spine, so let's focus on that first. Afterward we can look at the colors you see when exporting. 3.7 has much more sophisticated GIF encoding and is a lot better at preserving colors than 3.6.
Zip file contains project from 3.6, it visibly shifts to the darker colours when I open it in 3.7 over a short time frame
As for the new sophisticated encoding, it also adds those weird pixels visible at the top of the model, despite no animations being changed other than scale (of which the scale is root of 6.00 from 3.6, 600% encoding from 3.7)
Your PNG images contain sRGB and gAMA chunks
here is your sword image on top and the same image saved with Photoshop on bottom: Bild entfernt wegen fehlender Unterstützung für HTTPS. | Trotzdem zeigen
When there is a gAMA chunk, it means the specified gamma should be applied. When there is an sRGB chunk then the gAMA chunk should be ignored. The sRGB chunk means sRGB gamma should be applied.
The first thing I found was that Spine was preferring gAMA when both gAMA and sRGB are present, so that is fixed (sRGB is now used if both are present). I also found Spine assumes all input images are sRGB, then when the sRGB chunk is found it was applying sRGB again. This was the problem you were seeing and has been fixed in 3.7.82. :party: You didn't see it in 3.6 because it doesn't apply sRGB twice (it also doesn't apply gAMA at all). Photoshop never writes an sRGB chunk, so many Spine users have not encountered the issue.
PNG and gamma correction is a mess. 
On to your second issue, 3.7 has many more options for GIF encoding. The jagged pixels at the bottom of your animation in the first post above are from alpha dithering (try setting to 0). That the tip of the hat stays is super strange though. If you can provide the Spine project and images, we'd love to look into it!
The colour space shown in GIMP is only listed as RGB, and in the newer version of spine (3.7.82) sprites still appear discoloured.
This gif shows the colours shifting from the original, brighter ones to the newer, darker ones. There are no settings in GIMP to change the gAMA or sRGB layers/settings when using the script.
I'm having the exact same issue, even after the update to 3.7.82, and been having it ever since 3.7 but since it was in beta I just brushed it off and kept working on 3.6. My pipeline goes from corel painter to gimp and then uses the .py script (though I'm not sure if it is the newest version of it). I mention this because I remember testing it a while ago and I think that it didn't happen if I just draw something directly in gimp.
I "solved" it by changing the line
1, # gama to
0, # gama
in the py export script, but now I'm kind of wondering whether that might be something that gives me trouble later, like maybe the unreal engine uses that information in some way I'm unaware of. I could also provide images with the issue if that's useful but I don't have them with me right now.
@ngSliver, reporting stuff during the beta is super important! 
We still have some occasional crash reports that some people are able to reproduce, but no one has explained what they are doing.
The colour space shown in GIMP is only listed as RGB
You probably want to look at the color profile tab (but I'm not much of a GIMP user).
We got the mage project you emailed, thanks. The PNGs are different from what you first posted: Bild entfernt wegen fehlender Unterstützung für HTTPS. | Trotzdem zeigen
This doesn't have the sRGB chunk, instead it has gAMA 0.45455 (which is an approximation of sRGB, but not exactly the same).
I found Spine has a bug where it assume the input images are sRGB even if they have gAMA, so what you see is Spine applying both sRGB and gAMA, which is wrong. To prevent the sRGB assumption, we'd need to 1) convert sRGB back to linear, then apply gamma (I worry this might be lossy), 2) rewrite the code that reads PNGs (because silly Java is doing it wrong), or 3) always assume sRGB and ignore gAMA. That last option will make almost all PNG images correct, as relying on gamma in PNG isn't great anyway. Images that do rely on gamma will appear incorrectly, such as the famous apple-pear. I think that is probably fine for Spine's usage and it's what we'll do in 3.7.83, but we'll revisit doing it correctly in the future.
TLDR; you should be ok in 3.7.83. Sorry for the trouble! Bild entfernt wegen fehlender Unterstützung für HTTPS. | Trotzdem zeigen
Aighteo, thanks for getting on this so quickly, solves many headaches i'd be having otherwise