Bug 398838 - Standard color profile for Grayscale images has a gamma 2.2 tone reproduction curve
Summary: Standard color profile for Grayscale images has a gamma 2.2 tone reproduction...
Status: RESOLVED WORKSFORME
Alias: None
Product: krita
Classification: Applications
Component: Color models (other bugs)
Version First Reported In: 4.1.1
Platform: Microsoft Windows All
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2018-09-19 13:09 UTC by ch-bartz
Modified: 2018-11-06 14:46 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ch-bartz 2018-09-19 13:09:34 UTC
Standard color profile for Grayscale images obviously has gamma 2.2 instead of a sRGB TRC.

Reproducible: always 

Steps to reproduce:
1. open any image in Krita, e.g a 16 bit per channel integer precision grayscale TIFF, or an RGB 8 bit per channel integer precision JPEG).
2. Click "Image -> Properties... ->  Image color space -> Color Space Browser".
3. In the Color Space Browser, select Model: "Grayscale/Alpha". Select bit depth: "8 bit". Then select Profile: "gray built-in (standard)"

Observed behaviour:
The diagram at the right side of the Color Space Browser shows a tone reproduction curve which looks more like gamma = 2.2 (equals the TRC of the profile "Gray-D50-elle-V2-g22.icc") instead of the expected(?) sRGB TRC (for 8 bit). Additionally, regardless of the bit depth chosen in step 3, the color profile "Gray built-in" is always tagged as "(standard)" in the profile list for the model "Grayscale/Alpha". 

Expected behaviour:
In the diagram at the right side of the the Color Space Browser, a sRGB tone reproduction curve should be seen which should look like the TRC of the profile "Gray-D50-elle-V2-srgbtrc". 
I can imagine that the assignment of the tag "(standard)" to color profiles for grayscale images is intended to be consistent with the choice for RGB images. If that is true, the profile "Gray built-in" should not be tagged "(standard)". Instead you might want to assign the default profile following the rules in the table below:
Model           depth      Standard Color profile name               TRC
Grayscale/Alpha 8 bit      Gray-D50-elle-V2-srgbtrc.icc (standard)   sRGB TRC
Grayscale/Alpha >=16 bit   Gray-D50-elle-V2-g10.icc (standard)       gamma=1.0

Additional Information :
My System configuration:
Krita
  Version: 4.1.1

OS Information
  Build ABI: x86_64-little_endian-llp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: winnt
  Kernel Version: 10.0.17134
  Pretty Productname: Windows 10 (10.0)
  Product Type: windows
  Product Version: 10

OpenGL Info
  **OpenGL not initialized**
Comment 1 wolthera 2018-09-19 13:14:11 UTC
The 'standard' or default profile is generated by LCMS, we select it as default so that we are 100% sure it is always there.

What kind of workflow do you have that requires this to be changed?
Comment 2 ch-bartz 2018-09-19 14:18:46 UTC
I'm new to Krita and color management and just tried to see if there were Icc profiles or DCF tags embedded in my 16 bit grayscale images that Krita would recognize. I then wanted to adjust the Levels without changing relative measured intensities (pixel values relative to each other). I thought it is necessary to set the correct working color space (which I think should be linear, gamma=1.0) before doing so. While exploring, I thought it is irritating that standard settings behave differently for RGB and Grayscale Images.
My workaround so far would be to manually select one of the well defined and documented profiles (e.g. "Gray-D50-elle-V4-g10.icc") while promoting to 32 bit floating point precision if needed and ignore the default settings.
Comment 3 Andrew Crouthamel 2018-10-07 04:28:48 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Andrew Crouthamel 2018-11-06 14:46:57 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!