#1 default gamma in 0.7.2

open
nobody
None
5
2007-10-01
2007-10-01
Kai-Uwe Behrmann
No

The default gamma is always set to 1.0.
This is wrong for cineon and most other HDR images.
HDR is usually gamma 1.0 and a viewer must correct for
the display.
On PC 2.2 is a default on osX 1.8.
With gamma set to something useful, the display
looks good.

To clearify, this is not a memory or likewise bug, but a
functional one.

Discussion

  • darbyjohnston
    darbyjohnston
    2007-10-02

    Logged In: YES
    user_id=1114113
    Originator: NO

    > The default gamma is always set to 1.0.
    > This is wrong for cineon and most other HDR images.
    > HDR is usually gamma 1.0 and a viewer must correct for
    > the display.

    The OpenEXR, DPX, and Cineon plugins all have gamma controls; the default for OpenEXR is 2.2, and for DPX and Cineon is 1.7 (though this may refer to the "film" gamma, which I guess is separate from display gamma?). With the default settings, my test images look very similar to what I've seen from exrdisplay and Shake.

    Having said that though, it would be nice to have a more consistent approach to color. What are your ideas on how to fix this? Should there be controls per file-format or a global display setting?

    It's not the easiest to use yet, but there is a dialog that will let you change display settings and save defaults. Go to the menu Image->Display->Show and use the dialog to change the settings. Go to Image->Display->Add to save those settings. In the Preferences dialog you can now make those settings the default when the application starts. I'm certainly open to any ideas on how to streamline this or make it more intuitive.

    Thanks, Darby

     
  • Logged In: YES
    user_id=634841
    Originator: YES

    djv_view->Image->Displa->Show and djv_lut show the same interface to different things.
    HDRs are normalised prior viewing. So colourimetry is changed
    without a sign in the GUI.
    The sliders do overlapping manipulations. Not shure if this is helpful.

    Ideally display control is done by a proper calibration with a colour
    sensor. Typically a gamma table, embedded in a ICC profile, is uploaded
    to the graphics card by a vcgt loader. My take is: X should not be written
    from a normal application. Such is up to the system. The display profile is used
    to convert from image colours to the display target.

    Then the image needs a colourimetric description. This is harder to get into
    the graphics card. Possibly CTL is a way for your application. To obtain a
    image ICC profile, I plan to expose in Oyranos a according API.

    The LAD cineon is adjusted in LDR. Should'nt it be in HDR?
    With this image I saw the gamma 1.0. It usually looks quite different.

     
  • Logged In: NO

    > djv_view->Image->Displa->Show and djv_lut show the same interface to
    > different things.

    The reason for the split is performance; applying color-corrections to each image takes some amount of CPU/GFX time, whereas making those changes to the video-card lookup table is essentially free. Though I admit that modern graphics cards are fast enough this might not really matter anymore.

    > HDRs are normalised prior viewing. So colourimetry is changed
    > without a sign in the GUI.

    Each image in djv_view can have a simple color profile attached to it; this is the responsibility of the image loader plugin. If you take a look at the Preferences dialog under the Image I/O tab, you'll see that the OpenEXR, Cineon, and DPX plugins all have options for applying and modifying these profiles. If you want to see the raw image data, set the plugin "Color" option to "Raw", or just toggle the color profile on/off from the Image menu. The color picker also has an option to toggle the color profile when sampling image data.

    Do you think there should be some sort of display in the GUI to show that a profile is attached to an image?

    > Ideally display control is done by a proper calibration with a colour
    > sensor. Typically a gamma table, embedded in a ICC profile, is uploaded
    > to the graphics card by a vcgt loader. My take is: X should not be
    > written from a normal application. Such is up to the system.

    I would be more than happy to leave display calibration up to the system; I guess the djv_vlut application is more of a holdover from when there weren't so many color options for linux.

    > Then the image needs a colourimetric description. This is harder to get into
    > the graphics card. Possibly CTL is a way for your application.

    Yes, I am very hopeful about CTL; I need to spend some more time reading about it.

    > To obtain a image ICC profile, I plan to expose in Oyranos a according API.

    Isn't that a function of the file format? Or do you mean some sort of default profile?

    > The LAD cineon is adjusted in LDR. Should'nt it be in HDR?

    I'm not sure what you mean by LDR? Do you mean the 10-bit integer resolution for the color controls?

    > With this image I saw the gamma 1.0. It usually looks quite different.

    Are you looking at the raw image data? Does it look very flat, without any contrast?

    Thanks, Darby