color shift when saving with GLMakie.save

[koehlerson]

If I record a gif, the background color is correctly captured, see e.g. this example where the background color of my slides match the gif background color:

However, using GLMakie.save renders a slightly different color than record:

[jkrumbiegel]

can you read the image back in and check if the rgb value of the background is actually incorrect? because images can be displayed differently depending on color space etc., which you'd want to exclude as a factor

[koehlerson]

I used the pipette tool from gimp and the background color was correct if I loaded the figure exclusively. If I loaded a screenshot of the picture from firefox, it was, as can be seen, two different colors. I fixed it by loading the picture in gimp and used the option "save background color". The last step was necessary such that they were displayed correctly. Not sure how much this relates to Makie. Does Makie save the background color as information for png export? I don't know how the png format works and if there is some field to set it.

[asinghvi17]

Nope, it does not! How are you saving the figure and what theme are you using? It could be that gif compression simplifies the color.

[koehlerson]

GLMakie.save("name.png",fig) and theme_dark()

[asinghvi17]

This is the raw background color of theme_dark. Could you tell me if it is the same as your presentation's background color? Then we could narrow down where this discrepancy is happening.

[koehlerson]

Same issue. The theme of the slides is set to the very same color #1A1A1A. However, the issue is again there and only fixed if I export with gimp and the option save background color. Maybe browser issue?

[asinghvi17]

Huh. My color meter is showing that the top image is #181818 and the bottom is #1A1A1A. I am leaning towards a browser issue but have no idea why that might be the case! Could you send me the PNG after gimp export, just drag and drop it in to the comment field of the github issue? Will inspect it on my machine and try to see what the difference is.

[koehlerson]

This is before gimp reexport

https://github.com/koehlerson/MakieCon/blob/58a3844030cc7b1376adc8065706f57c70becd65/assets/arrows-incompressible.png

and this is afterwards

https://github.com/koehlerson/MakieCon/blob/bca0a64463cd419683bef96c5e86bba4e4df3a15/assets/arrows-incompressible.png

[koehlerson]

But again, if you import these two, they probably both will show you the same value in gimp (at least that's for me the case and I don't see a alpha channel with the color picker tool). The issue only appears if I include them in e.g. slides or in general displaying it with the browser I guess

[asinghvi17]

Huh! Can confirm that they show the same value...can you try saving them with CairoMakie and see if that has this issue? (just run save("filename.png", fig; backend = CairoMakie))

I guess gimp might be adding some metadata or something? Not sure.

[koehlerson]

CairoMakie save works out of the box without the gimp extra steps

[jkrumbiegel]

This might be a color space embedding issue. The color space implementation factors in the moment you compare via screenshots. The same colors can be rendered differently depending on the color space that is assumed. Maybe the gimp edit writes the color space information. Can you upload the original glmakie png and the gimp png? One could diff these with a metadata tool and see where the deciding factor is.

[koehlerson]

This is before gimp reexport

https://github.com/koehlerson/MakieCon/blob/58a3844030cc7b1376adc8065706f57c70becd65/assets/arrows-incompressible.png

and this is afterwards

https://github.com/koehlerson/MakieCon/blob/bca0a64463cd419683bef96c5e86bba4e4df3a15/assets/arrows-incompressible.png

The first is the GLMakie png and the second link the gimp png

[jkrumbiegel]

Looks like the original has some gamma / white point information in it and the edited one not. So I assume both files are interpreted with different gamma and that gives the lightness difference.