Krita/High dynamic range: Difference between revisions
Created page with 'This page is about ideas on improving the HDR capabilities of Krita. One of the reference bug on the subject is [http://bugs.kde.org/show_bug.cgi?id=125543 #125543]. There are th...' |
No edit summary |
||
Line 1: | Line 1: | ||
'''Warning!''' | |||
This page is heavily outdated. To read about real HDR feartures that are new in Krita 4.2.0, please go to https://krita.org/en/item/krita-4-2-0-the-first-painting-application-to-bring-hdr-support-to-windows/ and learn more on https://docs.krita.org/en/ | |||
---- | |||
= Introduction = | |||
This page is about ideas on improving the HDR capabilities of Krita. One of the reference bug on the subject is [http://bugs.kde.org/show_bug.cgi?id=125543 #125543]. There are three issues to solve for now in Krita : Color management, LDR to HDR and tone mapping. | This page is about ideas on improving the HDR capabilities of Krita. One of the reference bug on the subject is [http://bugs.kde.org/show_bug.cgi?id=125543 #125543]. There are three issues to solve for now in Krita : Color management, LDR to HDR and tone mapping. | ||
= Color management = | = Color management = |
Revision as of 08:39, 24 April 2019
Warning!
This page is heavily outdated. To read about real HDR feartures that are new in Krita 4.2.0, please go to https://krita.org/en/item/krita-4-2-0-the-first-painting-application-to-bring-hdr-support-to-windows/ and learn more on https://docs.krita.org/en/
Introduction
This page is about ideas on improving the HDR capabilities of Krita. One of the reference bug on the subject is #125543. There are three issues to solve for now in Krita : Color management, LDR to HDR and tone mapping.
Color management
Color management in krita and koffice is managed by the pigment library.
File format and color spaces
- openexr is allready supported, except that the chromacity is ignored (chromacity describes a transformation between RGB and XYZ
- cineon is not supported, it's a logarithmic color spaces, it requires a lut wich gives the transformation between the transmitance values and rgb (see rendernan for some examples)
Color profiles
There is currently no specification which support floating point profiles, the International Color Consortium has just released a proposition about a revision of the specification.
How it is done in other software ?
- OpenEXR Color Management is a proposal from ILM which explain their workflow. It's a proposition for importing and exporting, it's rather weak on exactly how to do this
- cinepaint use icc profile for display
- Adobe After Effects use icc profile internaly, for After effects there are a serie of tutorials on the subject
Color convertion
- color convertion should be done taking into account the exposure, that way when it would be possible to draw in the current range of exposure instead of the generic 0.0-1.0
LDR to HDR
This is the process for creating HDR image from a serie of Low Dynamic Range images, usually a scene taken with the bracketing capabilities of a digital camera:
Tone mapping
Automated Processes
We should provide one or more HDR tone mapping filters a la at least pfstools, possibly other algorithms that seem useful.
Manual Process
This is a suggested process for manual HDR mapping that would be nice to support. This process involves importing multiple exposures as separate layers into Krita. These can be "true" exposures, or different non-HDR tone-mappings of a single (usually RAW) exposure. We'll assume the latter case as the required tools are more complicated. (Multiple true exposures may require alignment, but we already have these tools.)
- Begin by importing the single RAW. See Direct RAW editing.
- Create a clone of the layer stack after debayerisation (and probably after white balancing).
- This requires the ability to clone the layer stack at a point, so that different operations (filters, paint layers) can be applied and the results later blended together.
- Apply tone-mapping to get multiple exposures. This consists of curves and hue/saturation filter layers. We have these already.
- Add a channel-to-alpha filter to one exposure to convert Luma to Alpha.
- This requires a filter that can take input in an arbitrary color space, perform an implicitly color space conversion, and dump the result as an Alpha channel. Ideally this should blend that with any previous alpha channel in the stack according to the blend mode (the default "Normal" mode would simply replace any previous alpha channel). Also ideally, this filter could map to any channel; for example, copy Red to Green.
- Apply filters or painting to the alpha channel as desired.
- This requires that filters can be told to operate on a single channel, in this case Alpha. That said, operations such as blur acting only on Hue (again, with implicit color space conversion being performed), sharpen acting only on Luma, etc, would be another extremely useful option. In fact this might even obviate the need for otherwise-important filters such as chromatic reduction.
The end result is a composited image with fine control over the tone mapping process.
An example would be a landscape. Typically, the sky will be very bright compared to the other elements. One might create two tone mappings to work with; one that maximizes the detail in the sky (which will typically produce a very dark foreground), and one that maximizes the visibility of the other elements (which will typically produce a heavily washed-out sky). These would be combined by mapping the sky-exposure Luma to alpha, and applying a curve to cut the dark (foreground) areas to full transparency while boosting the sky, including darker parts thereof, to high opacity. Because foreground elements tend to be extremely bright around the edges which have sky behind them, applying some blur may be desired to prevent fine details (such as leaves on trees) from being lost. In order to achieve this, we need the three operations bullet-pointed above.