The opacity of a layer or brush set to Overlay blend mode in a 16 bit image produces a lower level of opacity than the same layer in an 8 bit image. Reproducible: Always Steps to Reproduce: 1. Create a new 16 bit image 2. Paint some grey on Layer 1 3. Set Layer 2 to Overlay and paint over the grey with white. Note that the strokes are grey rather than white 4. Convert the image to 8 bit and see the strokes on Layer 2 turn to opaque white Photoshop does not exhibit this behaviour - it displays the white as opaque white regardless of the colour depth. Saving the 16 bit image from Krita as a .psd and reducing the colour depth to 8 bit in Photoshop retains Layer 2's original grey appearance however.
Are you sure that the colorspace isn't linear(for example, sRGB-elle-v2-g10.icc (the g10 means gamma=1.0, thus linear). Color maths works differently in a linear space(It works in fact more accurately to real life physics, as real life doesn't have the gamma crunching we impose on computer graphics) Go to image->convert image colorspace and chose anything appended with srgbtrc.icc(preferably srgb-elle-v2-srgbtrc.icc) to fix this.
I'm using 16 bit with sRGB-elle-V2-g10.icc (Default), and converting to 8 bit sRGB-elle-V2-g10.icc (Default). If I convert to 8 bit sRGB-elle-v2-srgbtrc.icc as you suggest, it still changes the opacity. If I start with a 16 bit sRGB-elle-v2-srgbtrc.icc however, it does stay the same after converting to 8 bit. This suggests to me that the issue then is that the default settings cause things to change unexpectedly when converting the colour depth, and if the default settings were used to begin with, there is no apparent way within Krita to do this without affecting the appearance of layers using Overlay. Also, I haven't tested all of the colour profiles (there are a lot of them!), but so far none of the ones I've tested seem to allow solid white when using Overlay. Do any of them?
Correction: the default settings use 8 bit - the problem begins when starting with a 16 bit image (as I typically do).
The solid white thing is something inherit in the overlay algorithm as referenced from the official Adobe PDF documentation. If you can't reproduce it with photoshop, mypaint or even the css blending modes, then we have a problem(Gimp's overlay algorithm has been non-standard for a whole version or two, should be fixed in 2.8). I need you to do something really really dumb. Could you go to settings->configure Krita->color management. And then just -look- at the page and press ok. Then try to reproduce your bug?
Same results after looking at the color management page. Photoshop does produce solid white when using 8 bit, as does Krita. I can confirm that using Photoshop's default settings on a 16 bit image does not produce solid white (as I have now come to realise is normal behaviour), although it's using a different default colour profile to Krita so it produces a lighter shade of grey. The key difference though is that it doesn't change anything when converting to 8 bit, which I think is the fundamental issue here. I'm not sure, but perhaps a solution would be for the "Profile" section of the "Convert Image Color Space" panel to switch to a srgbtrc.icc colour profile when "Depth" is changed from 16 Bit to 8 Bit?
Wait a sec - that's what it does already! Sorry, getting confused. :) When I select 8 Bits in the "convert Image Color Space" panel, it also automatically changes the Profile to sRGB-elle-v2-srgbtrc.icc - and maybe that's the problem right there. Shouldn't it retain the same profile that the image already uses?
I'm not sure, but perhaps a solution would be for the "Profile" section of the "Convert Image Color Space" panel to switch to a srgbtrc.icc colour profile when "Depth" is changed from 16 Bit to 8 Bit? < it should already be doing this. Isn't it? You should be careful with what is causing it now(and make sure to watch the optimisations checkbox). 1. 16bit linear to/from 8bit linear should give the same results, only with banding in the dark shades. 2. 16bit srgbtrc to/from 8bit srgbtrc should give the same results as well. 3. 16bit/8bit linear to/from 16bit/8bit srgbtrc, should give different results. (But it may be that the cache isn't updated yet, so toggle the layer visibility maybe?) Everything else is a bug. The overlay thing is something I'll need to ask boud the specifics about, I am curious what ps is doing there :)
Ah! Sorry. Well, maybe? Or maybe not? We are having a ball deciding the best behaviour that avoids people coming to us to tell us their images look strange.
Well, all I know is this: If I start with a 16 bit image using the default colour profile (sRGB-elle-V2-g10.icc (Default)), and I change it to 8 bit, the profile automatically changes to sRGB-elle-v2-srgbtrc.icc, which produces incorrect results. If I change it back to sRGB-elle-V2-g10.icc (Default) before converting though, it produces correct results. So unless it has adverse ramifications elsewhere, it would seem that when starting with 16 bit using the default profile, it should stay that way when converting to 8 bit.
How do you change it? If you just change the profile in the Image Properties dialog, you're not converting the pixels, and you will get weird results.
I'm changing it with Convert Image Color Space, but I get the same results with Image Properties. Is there somewhere else I should be changing it?
No, the issue shpuld be happening with both methods, because it's about final image composition. What this bug is about is about user expectancy, with power user vs regular user expentancies. I need to discuss this with boud proper on how to solve this.
Okay -- I think I get it now. I would in general warn against converting a multilayered image from one color model to another: keep working in the color model you are using, and only convert the final, rendered result.
Our solution will be to add a warning to the convert dialogue when doing so to multiple layers: https://phabricator.kde.org/T1078 The issue is that going from 16bit linear to 8bit linear will lead to far more visible information loss than 16bit linear to 8bit srgbtrc, so the later is preferable default behaviour.
(In reply to Boudewijn Rempt from comment #13) > Okay -- I think I get it now. I would in general warn against converting a > multilayered image from one color model to another: keep working in the > color model you are using, and only convert the final, rendered result. In my particular case that's unavoidable, as clients often require multilayered PSD files, and 16 bit files are too large to transfer easily. I'd work directly in 8 bit except the airbrush is not smooth and there's more brush lag, but those are reports for another day. ;)
> In my particular case that's unavoidable, as clients often require multilayered > PSD files, and 16 bit files are too large to transfer easily. I'd work > directly in 8 bit except the airbrush is not smooth and there's more brush lag, > but those are reports for another day. ;) Hm, in that case, I'd say, use a gamma corrected profile even in 16 bits/channel rgb, that way you won't get surprises when converting down to 8 bits/channel.
Created attachment 95991 [details] Opacity error when converting color spaces Boud asked me to upload this here. I recently discovered that when converting between color spaces of different gamma curve, opaque areas convert fine wile transparent areas get screwed up: generally lightened and desaturated. It happens either if I convert from 8 bit to 16 or 8 to 8, as long as I convert from on-linear gamma to linear. The layer in question has semi-transparent content, with the layer's opacity value at 100%. I tested converting brush strokes made with a smooth edge brush, and the inner, opaque part of the stroke converts well while the semi-transparent edge, start and end of stroke doesn't.
Git commit 18ee2042a807685fa53cd0c8d95f9e4f3d410b33 by Dmitry Kazakov. Committed on 24/08/2020 at 20:05. Pushed by dkazakov into branch 'krita/4.3'. Add a warning message when changing profile of a multilayered image When changing color profile of the image blending modes start to behave differently. The biggest visual drift is caused by the difference in tone response curves, though just changing primaries will also affect blending modes like "Overlay". M +31 -0 libs/image/kis_layer_utils.cpp M +2 -0 libs/image/kis_layer_utils.h M +1 -0 libs/ui/CMakeLists.txt M +19 -0 libs/ui/dialogs/kis_dlg_image_properties.cc M +3 -0 libs/ui/dialogs/kis_dlg_image_properties.h M +34 -2 libs/ui/forms/wdgimageproperties.ui A +63 -0 libs/ui/widgets/KisWarningWidget.cpp [License: GPL (v2+)] A +46 -0 libs/ui/widgets/KisWarningWidget.h [License: GPL (v2+)] M +2 -2 plugins/extensions/colorspaceconversion/colorspaceconversion.cc M +21 -1 plugins/extensions/colorspaceconversion/dlg_colorspaceconversion.cc M +6 -1 plugins/extensions/colorspaceconversion/dlg_colorspaceconversion.h M +24 -2 plugins/extensions/colorspaceconversion/wdgconvertcolorspace.ui https://invent.kde.org/graphics/krita/commit/18ee2042a807685fa53cd0c8d95f9e4f3d410b33
Git commit 8181058a56ef97c0128a83ca6de10a230cfb2e23 by Dmitry Kazakov. Committed on 24/08/2020 at 20:06. Pushed by dkazakov into branch 'master'. Add a warning message when changing profile of a multilayered image When changing color profile of the image blending modes start to behave differently. The biggest visual drift is caused by the difference in tone response curves, though just changing primaries will also affect blending modes like "Overlay". M +31 -0 libs/image/kis_layer_utils.cpp M +2 -0 libs/image/kis_layer_utils.h M +1 -0 libs/ui/CMakeLists.txt M +19 -0 libs/ui/dialogs/kis_dlg_image_properties.cc M +3 -0 libs/ui/dialogs/kis_dlg_image_properties.h M +34 -2 libs/ui/forms/wdgimageproperties.ui A +63 -0 libs/ui/widgets/KisWarningWidget.cpp [License: GPL (v2+)] A +46 -0 libs/ui/widgets/KisWarningWidget.h [License: GPL (v2+)] M +2 -2 plugins/extensions/colorspaceconversion/colorspaceconversion.cc M +21 -1 plugins/extensions/colorspaceconversion/dlg_colorspaceconversion.cc M +6 -1 plugins/extensions/colorspaceconversion/dlg_colorspaceconversion.h M +24 -2 plugins/extensions/colorspaceconversion/wdgconvertcolorspace.ui https://invent.kde.org/graphics/krita/commit/8181058a56ef97c0128a83ca6de10a230cfb2e23