View source for Krita/Direct RAW Editing

The goal of this page is to discuss about the problem, solutions and design around the possibility to directly edit RAW image inside Krita, instead of first converting them to a RGB image.

A moderately long thread discussing this can be found [http://lists.kde.org/?t=122150829000004&r=1&w=2 here].

== RAW Color Space ==
=== The Problem ===
RAW images are often bayer images, meaning that one pixel is either red, blue and green, and that there are usually twice as much green pixels as red or blue. Converting to an RGB color space involves determining values for the other channels via interpolation, in a process called debayerisation. There are multiple algorithms available to perform this process, that are not equally suited for all image types. Certain types of images (i.e. outdoor landscapes) may be best suited by one algorithm, while others (e.g. buildings) are better suited by another.

For this reason, and for the sake of full preservation of the original input data within a Krita file, it is preferred to keep the raw bayer data in Krita. The problem is that pigment and Krita are not designed to work with pixels that needs to know the values of their surrounding pixels.

=== A Dedicated Colorspace ===
One possible solution is to represent RAW in a special color space. This might look like:
* an 8-bit metadata field, which would indicate whether the main component is Red, Green or Blue.
* a 16-bit main component field containing Red, Green or Blue value.
* two 8-bit (or 16-bit?) pre-visualization fields, containing the two missing values to get a RGB triplet. These would be used to get a basic transformation from raw to rgb for display on the canvas.

=== "Faking It" ===
Another option is to ignore the problem, accept that filters will not work correctly on bayer data, and import RAW directly into a 16-bit single channel (i.e. "grayscale") layer. At time of writing, this seemed to be the preferred option, as the benefits, if any, of a dedicated bayer color space do not seem worth the extra effort, given that this solution can be mostly implemented with existing functionality (the filters it needs - debayerisation and white balance - are needed for either case, and it leverages existing color spaces).

=== Considerations ===
In either case, a debayerisation filter is needed either for final rendering, or to convert the bayer data to RGB prior to additional filtering/editing. This would allow both complete preservation of the original sensor data, and the ability to experiment quickly with different debayerisation algorithms to find the best result.

== Important Filters ==
A number of filters are needed for an effective RAW editing workflow:
* Debayerisation: converts bayer data into RGB data using a user-selectable algorithm.
* White Balance: Allows adjusting of warmth and tint. This would be useful for generic photo processing as well, and possibly even non-photographic works.
* Curves: Needed to adjust the brightness (exposure) and contrast, as well as to apply non-linear tone mapping. We already have this one.
* Hue/Saturation: Saturation is probably more important than hue. We have this one already, as well.

== Importing ==
It is important to preserve the camera white balance. Assuming we preserve the metadata in the raw layer, we may want to add a way to create a white balance filter from this. At any rate, an import is expected to create, at minimum, three layers. The raw data in bayer format will be one; operating on that will be debayerisation and white balance filter layers, with the order depending on which of the above options is decided upon.

Depending on the sophistication of the import wizard (if we keep one), additional filter layers (one or more brightness/contrast curves, and a hue/saturation) may also be created. Alternatively, we may create a script to streamline this process, which would not be limited to use on raw import.