Screenshots saved as .png files have wrong gamma in certain image viewing applications

[Takehaniyasubiko]

Hello, this is a rather small issue, but I noticed it today with mpv 0.9.0-1 and it's quite annoying if somebody needs to take a lot of screenshots as .png files.

The problem is (probably) caused by mpv using the problematic PNG gamma correction, which makes output files display incorrectly in applications that ignore it. I assume that the gAMA chunk of PNG shouldn't be added by mpv for full compatibility. The whole gamma correction thing in PNG is terrible in practice and should be avoided, as it can lead even to idiocy such as this: http://superuser.com/questions/579216/why-does-this-png-image-display-differently-in-chrome-firefox-than-in-safari-a

[haasn]

Removing gAMA atoms from saved screenshots would basically be a dirty compatibility hack for the sake of shitty viewers/browsers.

The better solution is to use a browser or image viewer that respects the gamma tag correctly, like Firefox or https://github.com/haasn/sxiv.

If you still think hacking around the issue is a good “solution”, it would be simple to add a flag to selectively disable this behavior. @wm4, what are your thoughts?

Edit: I realized that we already have a way to disable it, screenshot-tag-colorspace=no.

Ps. Ironically, there is an actual problem with PNG gamma tags, but neither your link nor the article it mentions seems to know about it: The problem is the redundancy between the sRGB atom and the gAMA atom. It was introduced for backwards compatibility with older image viewers, but some implementations seem to misinterpret this as a free license to conflate sRGB and gAMA 45455.

[ghost]

I expected that this would happen. Use such obscure features, and every program will display it differently.

[Takehaniyasubiko]

haasn, I wasn't precise enough. Sorry. mpv uses the gamma correction feature of PNG wrongly. It adds wrong gamma settings so the files are too bright. Firefox and eog display all of .png screenshots from mpv too brightly.

screenshot-tag-colorspace=no does fix it, though.

[haasn]

They should display it identically if you have CMS enabled with the same device profile in both programs. If that is not the case, it is a bug. Can you post such a sample with screenshots+settings?

On April 28, 2015 12:19:43 PM GMT+02:00, Takehaniyasubiko notifications@github.com wrote:

haasan, I wasn't precise enough. Sorry. mpv uses the gamma correction feature of PNG wrongly. It adds wrong gamma settings so the files are too bright. Firefox and eog display all of .png screenshots from mpv too brightly.

---

Reply to this email directly or view it on GitHub: https://github.com/mpv-player/mpv/issues/1881#issuecomment-97002771

[Takehaniyasubiko]

I'm using a fresh install of Ubuntu 15.04 with mpv 0.9.0-1. I didn't assume a bug in mpv, but there's something wrong going on and I thought I should write about it because I'm not sure which way I should interpret this thing.

I have a model PNG screenshot taken by somebody else. When I use mpv to open the same video file that model screenshot is from, I get identical picture. However, if I make a screenshot of the same scene without screenshot-tag-colorspace=no, the gamma information produced in the .png created by mpv makes it brighter in certain applications. It shows too bright in Firefox and eog, but shows right in Shotwell and Gimp, and mpv itself.

[haasn]

What happens if you run mpv with --vo=opengl:target-trc=srgb? Does that make it match the Firefox output?

[Takehaniyasubiko]

vo=opengl:target-trc=srgb does not change anything in the colours and / or gamma of mpv. The Firefox (and eog, and probably much more - I just tested these two) output is too bright for PNG files created with mpv.

[haasn]

I find that hard to believe. What mpv settings are you using?

[Takehaniyasubiko]

We're not in a church and this is not a matter of beliefs. I'm just reporting what happens.

My mpv config is simple:

vo=opengl-hq

ao=alsa:device=[hw:0,0] softvol=no

geometry=50%:50%

screenshot-format=png screenshot-template=/home/takehaniyasubiko/%F_%P

vo=opengl:target-trc=srgb does not change colors and / or gamma. The picture looks the right way. It's just that screenshots made by mpv are too bright in certain applications.

[haasn]

Cannot reproduce.

eg. using https://0x0.st/uT.mkv as an example:

mpv --pause --no-config -vo opengl-hq ~/uT.mkv --screen shot-format=png -> screen captured using import -depth 8 -define png:include-chunk=none

mpv --pause --no-config -vo opengl-hq:target-trc=srgb ~/uT.mkv --screen shot-format=png -> screen captured using import -depth 8 -define png:include-chunk=none

-> output of internal screenshot tool (default ‘s’ keybinding)

For me, the last two match, but the first is too dark. (Ignore the terrible banding due to quantization and inconsistent dithering.)

Edit: Finally, here's a screenshot of my browser, verifying my findings, with my ICC profile embedded. (And here is the same screenshot without the embedded profile. This one should look noticeably wrong on every monitor except my own)

[Takehaniyasubiko]

Interesting. Reds in the second and third image you showed are over-saturated and both images are too dark on my end. When I open that file with mpv --pause --no-config -vo opengl-hq ~/uT.mkv --screenshot-format=png, I get a very nice image, without excessive reds and no missing details due too crushed blacks. This is a screenshot of my mpv output made with the system print screen function:

However, if I make a screenshot with mpv, it's too dark and has excessive reds. This is the one made with mpv:

EDIT: I just noticed that screenshot-tag-colorspace=no sucks after all because it introduces some sick banding.

[haasn]

Reds in the second and third image you showed are over-saturated and both images are too dark on my end.

If you're using Firefox, make sure to set

gfx.color_management.enablev4=true
gfx.color_management.mode=1

Does that fix the issue? (I have no idea why Firefox has it set to 2 by default, but it's pretty stupid.)

EDIT: I just noticed that screenshot-tag-colorspace=no sucks after all because it introduces some sick banding.

Because your browser is severely misinterpreting the image. “Lack of a colorspace tag” does not mean “don't use colorspaces”. It just defaults to sRGB.

If you want to get an sRGB image, tag it as sRGB instead. If that produces better results for you, then your input file was probably incorrectly tagged to begin with. (Which can be fixed by using --vf=format:gamma=srgb)

mpv --pause --no-config -vo opengl-hq ~/uT.mkv --screenshot-format=png

Also, note that invoking mpv in this way will virtually always result in an incorrectly rendered image. If you want correct colors, you need to use either target-trc+target-prim or icc-profile.

[Takehaniyasubiko]

No, those changes in about:config didn't change excessive reds and missing hair details on the left.

As for mpv, I just used your example to show how it behaves while using the same commands.

I have model PNG files from a person nicknamed der richter who deals in video processing for various anime releases. When I use mpv with opengl-hq, I get identical picture to the one showed by der richter. For some reason, mpv's deafult PNG output is flawed because it produces a picture of a higher contrast. It might seem better at first, but it actually sucks because it basically manipulates the gamma curve to get a higher contrast and more saturation at the expense of picture detail.

[haasn]

Can you post an example of such a model PNG file + its corresponding source frame?

As it stands, I still can't reproduce any actual issue on my end.

[Takehaniyasubiko]

Yes, I'll show it in a minute, but first I wanted to post this:

[ffmpeg] swscaler: full chroma interpolation for destination format 'rgb48be' not yet implemented

I just saw in the terminal, after I took a .png screenshot with mpv. Does it matter?

[haasn]

Does it matter?|

Doubtful.

[Takehaniyasubiko]

OK, now I will show a model image from Vampire Hunter D: Bloodlust.

Notice the details on D's coat and hat, and on the floor.

Now, the PNG output of mpv:

The image has more "pop", but at the cost of destroying the intended, cinema-like picture. It shows in the lost details on the coat, hat and floor. Well, in the case of those floor details, they aren't really lost - they are just obscured by the excessive reds.

[haasn]

The second image matches my reference monitor very closely. The first one hardly does. (Edit: When treating it as sRGB, ie. the untagged default assumption)

If you still want to simulate the look and feel of the former, you can use --vf=format:gamma=srgb, with the obvious caveat being that it no longer corresponds to the artist's implied intent.

I have talked to der_richter personally and concluded that he strips the colorimetry data from the images, in part due to the various PNG optimization and recompression tools he uses to minimize file size. In other words, you should only view his screenshots (without color management) on a calibrated reference monitor, same as a high-end TV or cinema display.

I have such a monitor[1], and in terms of the gamma curve it looks identical to the second image (when applying colorimetry).

[1] I have mine calibrated to a slightly higher ambient brightness than the official specification, but this is only a minor difference in overall image darkness and doesn't change the relative details. I still stand by my judgment.

[Takehaniyasubiko]

The first image shows how it's supposed to look. In other words, how this was mastered.

I have a cinema display. A Panasonic plasma that passes the cinema standards. The first image is exactly how it should look. It's clear anyway. Those details are there and they are supposed to be seen. The second image either kills or obscures many of them to achieve a higher contrast and more colour intensity, which might be cool for some people, but it's not the mastered version.

[haasn]

Yes, on an ideal/reference mastering monitor. When color management is disabled.

If the top (with color managament disabled) does not match the bottom (with color management enabled), then either: 1. your monitor is not an ideal reference, or 2. your ICC profile was incorrectly measured. Which one is it?

Again, it works on my machine, so I can't reproduce the presence of any bug.

[Takehaniyasubiko]

I am aware of how der richter makes his reference images and that is why I was looking at them on my cinema display, not my PC monitor (my PC monitor is terrible anyway).

My mpv picture is exactly the same as his reference images, which preserves all details. However, the PNG files created by mpv kill or obscure a lot of details. This is basically a case of creating images of higher contrast at the price of picture fidelity.

EDIT; I think you keep missing one thing. I'm talking about the PNG files from mpv mismatching the reference images in certain applications. For example, if I open those two images with D in Gimp, they are exactly the same. They are different in Firefox and eog, however (didn't test more applications). I'm seeing some compatibility issues between the mpv-created .png files and certain applications.

BTW, I want to clear something. You said that the second image with D matches your reference monitor very closely. OK, but what do you see? Are the gray lines on his hat clearly visible, for example? How about the reds on the left? Are they obscuring the floor details a bit? The second image was made with mpv so maybe you're just using an applications that shows it correctly?

[haasn]

My mpv picture is exactly the same as his reference images, which preserves all details.

All of the images preserve all the details. I think you don't realize this fundamental aspect - the raw source pixels inside the images themselves are completely unchanged.

The only thing that changes is the response curve of your monitor, which is highly variable and inconsistent across displays. Color management exists to counteract this inconsistency, by essentially applying the inverse of the monitor's distortion to the image beforehand.

So if your monitor is very much off from the ideal one, then you will end up losing a lot of detail. This is not something inherent to the color management process, it's inherent to the monitor not being a good fit.

The closer your monitor approaches the true BT.1886 curve, the closer the color managed image will appear to the non-color managed image, both in terms of pixels and in terms of visual appearance.

Also, it's important to distinguish between loss of detail and loss of exaggeration of detail. Displaying something that is designed for BT.1886 on an sRGB monitor instead can indeed greatly exaggerate the details.

This is basically a case of creating images of higher contrast at the price of picture fidelity.

This has nothing to do with contrast. The overall contrast is the same across both images. So is the fidelity. It's the same image. You're just displaying it on different devices (conceptually).

Take the same (untagged) source image, eg. hook up a blu-ray player to 10 different devices and you will get 10 different images on the screen. If you happen to hook it up to something matching sRGB, you would get something equivalent to one of these files - while if you happen to hook it up to something matching BT.1886, you would get the other version.

I'm talking about the PNG files from mpv mismatching the reference images in certain applications. For example, if I open those two images with D in Gimp, they are exactly the same.

Then that would suggest a bug in GIMP, as they are not the same images at all. Also, it works on my end. Maybe you forgot to set your display's ICC profile in GIMP's color management settings?

They are different in Firefox and eog, however (didn't test more applications).

These have different “default behaviors” for missing ICC profiles. Whereas GIMP, sxiv, mpv etc. will just disable color management if you haven't specified a profile, Firefox and presumably eog will just “assume the display is sRGB” instead.

sRGB is not a close match for BT.1886, which is why your images end up losing so much detail.

Are the gray lines on his hat clearly visible, for example?

They're clearly visible in both. So are the floor details.

This is not something I can describe in imprecise terms.

[Takehaniyasubiko]

No, I am not missing that. The contrary, I know about that and that's why I got myself a cinema-standard plasma TV, that was tested professionally by people from HDTVtest.

Long story short, I know my display shows the right image. I never had any problems with picture fidelity. The problem is that PNG files created by mpv are not displaying correctly in certain applications. Whether it's an issue with mpv or with those applications, I don't know. What I know is that it's not a good idea to have screenshots made with mpv display incorrectly in certain applications. It's much better to have it like PNG files created by the default system print screen feature, which display the same way in every application.

[haasn]

Long story short, I know my display shows the right image. I never had any problems with picture fidelity. The problem is that PNG files created by mpv are not displaying correctly in certain applications.

Then this sounds like you are not using the correct ICC profile in those applications. For example, in Firefox, you need to set gfx.color_management.display_profile to the correct path. Have you done that?

(This should also be done in mpv. If your theory is correct, then there would be no difference in the rendered result for content corresponding to your monitor. You should also never use mpv without color management in general if you care about accuracy whatsoever)

Whether it's an issue with mpv

I can rule this out with a high degree of certainty. The PNG files mpv is producing with tag-colorspace are correct.

It's much better to have it like PNG files created by the default system print screen feature, which display the same way in every application.

If you think displaying wrong in every application is somehow better than displaying wrong in only in wrong applications, feel free to strip color tags.

Edit: Since I still have not been able to verify the presence of any concrete issue in mpv, I suggest closing this issue, as the mpv-specific workaround you are asking for already exists: screenshot-tag-colorspace=no. The only thing that's left for debate is whether or not it should be default behavior or not, and the only argument I can come up with for disabling it by default is “to protect users who have misconfigured environments”.

[Takehaniyasubiko]

My plasma TV doesn't need a colour profile because of its accuracy per se. It was professionally tested by the HDTVtest workers in one of their many reviews. For example, Blu-ray's via PS3 are close to perfection on this TV, perfection being the mastered image.

I much prefer the approach used by most applications that allow PNG screenshots, which is not adding anything that could make them incompatible with certain apps. The PNG files created by the system print screen feature will display the same in all applications and only the calibration of one's monitor or TV affects them. mpv seems to add something that tries to fix crappy displays with software solutions.

[haasn]

My plasma TV doesn't need a colour profile because of its accuracy per se.

And yet here you are, complaining about applications doing stupid things when they don't have a color profile.

It was professionally tested by the HDTVtest workers in one of their many reviews.

Wait, so they tested one of their own devices, not yours?

I much prefer the approach used by most applications that allow PNG screenshots, which is not adding anything that could make them incompatible with certain apps. The PNG files created by the system print screen feature will display the same in all applications and only the calibration of one's monitor or TV affects them. mpv seems to add something that tries to fix crappy displays with software solutions.

Yes, and most video players also behave like VLC. We don't. We do things correctly.

Deal with it.

(Or don't, and use the hacks that we already provide for occasions like this - like the VSFilter/libass compatibility hacks.)

[Takehaniyasubiko]

I am not complaining about this because I can bypass it simply with the print screen key. I am seeing a problem in general because mpv seems to force its screenshots into a certain color profile, which means they are usable only on a given set. People rarely use screenshot just for themselves. They often share them online. With mpv's behaviour, you have to remove what mpv adds if you want to share them without risking incompatibilities across different hardware and software. I think it shouldn't be like this and I am assured in such a view by the fact that every other screenshot feature that I used before didn't act this way.

BTW, "Wait, so they tested one of their own devices, not yours?" doesn't make any sense. Panasonic plasmas are (well, were) manufactured to adhere to a given standard. There might by minimal differences between sets of the same model. It's more than obvious that a model tested by the HDTVtest workers will have the same specifications for every owner.

[mia-0]

FWIW, these images display fine here as well in a color managed setup, using Chromium, Krita, GIMP, sxiv (with CMS patch), mpv and others, and in fact the version with the tags has slightly more visible detail with my particular setup, i.e. it would look worse without color management. They look identical in applications which do not support color management, of course.

From that, I conclude that software which displays these incorrectly has buggy color management code which needs to be fixed and not worked around by mpv, or that your system is misconfigured. It’s unfortunate that there seem to be applications which do this incorrectly, but they have no excuse, and we have no reason to compensate for their bullshit.

Also, you cannot be sure your TV is accurate until you have actually measured your physical device with proper equipment. Reviews are completely irrelevant. You’d be surprised how different displays can be, even if they come from the same lot, and even if you use the same settings.

I am seeing a problem in general because mpv seems to force its screenshots into a certain color profile

Nothing of the sort. mpv attaches tags so they can be displayed correctly in a properly color managed setup.

[Takehaniyasubiko]

Of course I can be sure that my model of Panasonic plasma is accurate. It was tested with proper equipment by HDTVtest and Panasonic guarantees that all sets of a given model are the same. Reviews are not irrelevant if they come from professionals that tested hundreds of TVs. The Panasonic line of plasmas is famous for accurate picture, especially in the Cinema mode with the D65 standard.

The other apps are probably buggy, or just do things "differently" (I'm sure their authors will insists they are not buggy in this regard, that they just expect a different source etc). That's probably why adding such data to PNG files is omitted by most screenshot backends, so that the image itself doesn't force any gamma setting or color space.

EDIT: I checked what will happen if I use Gamma6500K.icc both system-wide and in the mpv.conf. No changes. mpv plays every file the same (correctly), but the screenshots are still saved with some weird data attached to them, which makes them display wrong in certain apps.

[mia-0]

Panasonic guarantees that all sets of a given model are the same

Very bold claim; I call bullshit.

Reviews are not irrelevant if they come from professionals that tested hundreds of TVs.

Well, if you actually read their reviews, you will notice that they calibrated and profiled these things. That is not without reason, and you will have to do the same if you want to get anywhere close to their results. No, your TV will not reproduce colors properly out of the box.

That's probably why adding tags to PNG files is omitted by most screenshot backends

No, most of them simply never added color management support. OS X will attach display color profiles, for example.

[Takehaniyasubiko]

Bullshit when it's common knowledge? Panasonic plasma TVs were manufactured professionally to adhere to the cinema standards. It's obvious that a given model will have the same picture across the whole line. The HDTVtest workers always point out to tiny differences in advanced calibrations, but the main modes are preconfigured to adhere to the cinema standards and the user can achieve the same results on a unity of the same model as the one tested. I actually compared my plasma with a grading monitor anyway. The picture was very close to a D65 standard on the grading monitor, which is exactly what the HDTVtest confirmed.

Personally, I think that screenshots should be made without data that creates incompatibilities across the plethora of possible configurations. People who want a color profile can add them in professional image editors. A screenshot made by a video player should be universal, in my opinion.