Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

HSVL : V reporting incorrect data in the viewer? #286

Closed
troywilliams1 opened this issue Jun 7, 2018 · 1 comment
Closed

HSVL : V reporting incorrect data in the viewer? #286

troywilliams1 opened this issue Jun 7, 2018 · 1 comment

Comments

@troywilliams1
Copy link

troywilliams1 commented Jun 7, 2018 •
edited by devernay
Loading

Problem

The V data being reported in the Viewer window when sampling using Ctrl+LMB appears to be incorrect.

Expected behavior: The reported V data should equal whatever the highest RGB value being reported is.

Actual behavior: The number being reported is not a value that reflects any known information.

Steps to Reproduce

  1. Create New project
  2. In the node graph add a new node (constant)
  3. Set color of the 'constant' to 118, 118, 118 using the color tool
  4. Ctrl+LMB in the viewport
  5. The data being reported in the V: section of the viewport information is .46, this should be .18116 based on the color information.

Versions

This software was compiled from the source code branch tags/2.3.12 at version 266fb27 using GNU C++ version 7.3.0 with OpenMP 4.5 targetting Intel x86-64 for Unix Environment.
The bundled openfx-io plugins were compiled from version 83cd498.
The bundled openfx-misc plugins were compiled from version f03c6c0.
The bundled openfx-arena plugins were compiled from version 50f9e12.
The bundled openfx-gmic plugins were compiled from version 36a4f22.

Windows 10 Enterprise 64-bit

image
@devernay
Copy link
Member

devernay commented Jun 8, 2018

There is no reference stating that HSV should be computed from linearized color values. The thing is, Nuke until Nuke 8 computed HSV from sRGB values, which made sense since many peaple were using those values to compute HSV in the 8-bit era.
However, let's look back at the original paper by Alvy Ray Smith describing HSV and HSL, presented at SIGGRAPH 1978.
He says: "We shall assume that an RGB monitor is a linear device"
Maybe that's what the Foundry did (reading this paper) when they fixed it in Nuke 9.
Note that in this paper, L from HSL is the luminance and is computed using the NTSC coefficients.

References:

devernay added a commit to NatronGitHub/openfx-supportext that referenced this issue Jun 8, 2018
@devernay
ofxsLut: document HSV
e600cae 
see NatronGitHub/Natron#286
devernay added a commit to NatronGitHub/openfx-misc that referenced this issue Jun 8, 2018
@devernay
HSV, HSL, and HSI are now computed from linear RGB
3d9907f 
Affected plugins: RGBToHSV, HSVToRGB, RGBToHSL, HSLToRGB, RGBToHSI, HSIToRGB.
Nuke 5-8 version used sRGB colors to compute HSV
However, as Alvin Ray Smith said in his paper,
   "We shall assume that an RGB monitor is a linear device"
We thus use linear values (same as Nuke 9 and later).
Fixes NatronGitHub/Natron#286
Reference:
 "Color gamut transform pairs", Alvy Ray Smith, Proceeding SIGGRAPH '78
 https://doi.org/10.1145/800248.807361
 http://www.icst.pku.edu.cn/F/course/ImageProcessing/2018/resource/Color78.pdf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@devernay @troywilliams1