Feature Request - RAW files in LAB/16 format

[pano]

When I open a RAW file, it's created by default an RGBA/32 document (with gamut limitations!).

I would like to open the RAW image into the LAB/16 format to avoid any color loss.

In Photoshop/Camera Raw this is already possible and should be very quick to implement because AF already support the LAB/16 format for other files.

Thank you

[NotMyFault]

55 minutes ago, pano said:

with gamut limitations

This is a misinterpretation. The RGB/32 in develop Persona displays unbound data. Depending on you assistant settings, it will converted after clicking „develop“ to the selected color format and color profile. Limitations will only apply if you choose a format not suitable. 
 

So just choose LAB/16 as output format.

 

[pano]

If I have a RAW file, I don't know what colors are there and what color space is including the whole native camera color space.

So the only viable choice is LAB, that contains all colors. Any other arbitrary choice may lead to a gamut mapping with an error.

Picking RGB/32 and then automatically converting to ROMM RGB (the largest color space) is not a warranty of loseless colors, the camera color space is often wider than that. Converting to LAB after won't recover any color lost.

That's why Adobe is allowing the direct RAW->LAB conversion.

[NotMyFault]

Lab/16 does not support color values exceeding 1.0, so will get clipping of highlights in many cases (practically every outdoor image with sunlight). Only RGB/32 allows to deal with unbound values.

So if you ask for a LAB mode, for the target of preserving gamut, you need to ask for float support or something like LAB/32 which dos not yet exist in Affinity (and I actually don’t know if is standardized welsewhere)

[pano]

CIELAB (or LAB) is designed to support a dynamic range of approximately 100:1 that´s enough for single shoot photo. hdr-CIELAB is addressing wider dynamic ranges, but i'm not interested in that. An L* of 0-100 is more than enough for all my needs. I'm currently more interested in accurate colors.

RGB/32 is storing RGB data as 32 bits per channel (=96 bit), but my point is about the color space, not the bit format.

LAB/16 is an "unbounded" color space AND a bit format. 16 bits per channel (=48 bit) are enough for my 12/14 bit RAW files.

[pano]

The 3D Gamut of LAB is not a cube, so some values are not valid in the color space and Affinity Photo mess up things of course. Programmers call the reference white D50 a color space but this doesn't make a lot of sense.

For example LAB 0 127 127 is a red in Affinity, while this is of course not the case. Everything is black when there is no light. This is just an out of gamma value that is wrongly displayed. The Affinity Gamut Check is not working with the Proof Profile D50!

The valid gamut include all human visible colors and is "unbounded" in this sense.

 

[NotMyFault]

There are multiple wide gamut color profiles for RGB/16 which will cover probably all gamut you need. LAB/16 has some other nice properties like more oriented to human perception.

https://en.wikipedia.org/wiki/ProPhoto_RGB_color_space

The ProPhoto RGB color space, also known as ROMM RGB(Reference Output Medium Metric), is an output referred RGB color space developed by Kodak. It offers an especially large gamut designed for use with photographic output in mind. The ProPhoto RGB color space encompasses over 90% of possible surface colors in the CIE L*a*b* color space, and 100% of likely occurring real-world surface colors documented by Michael Pointer in 1980,^[3][4] making ProPhoto even larger than the Wide-gamut RGB color space.

 

LAB implementations have their own issues, leading to unwanted clipping of gamut and not reaching the theoretical benefits:

https://en.wikipedia.org/wiki/CIELAB_color_space

 

Range of coordinates

As mentioned previously, the L* coordinate nominally ranges from 0 to 100. The range of a* and b* coordinates is technically unbounded, though it is commonly clamped to the range of −128 to 127 for use with integer code values, though this results in potentially clipping some colors depending on the size of the source colorspace. The gamut's large size and inefficient utilization of the coordinate space means the best practice is to use floating-point values for all three coordinates.

 

Do you have any test images proving that an export (from PS) to lab/16 covers a wider gamut than RGB/16 with ROMM RGB(ProPhoto)?

And that Affinity Photo is unable to deliver equivalent results from its RAW engine (with target format LAB/16)?

Do you expect adding LAB/16 RAW editing provides any benefit without solving the current color format issues before in Affinity Photo?

[pano]

You seems right, LAB is clipping more than ProPhoto in PS.

I can't find on Wikipedia anything about unwanted LAB clipping. Do you have any link to learn more?

Thank you

[v_kyr]

1 hour ago, pano said:

I can't find on Wikipedia anything about unwanted LAB clipping.

• CIELAB color space

Quote

Using CIELAB in an 8-bit per channel integer format typically results in significant quantization errors. Even 16-bit per channel can result in clipping, as the full gamut extends past the bounding coordinate space. Ideally, CIELAB should be used with floating-point data to minimize obvious quantization errors.

• What are 'Clipped Colors' from ICC Profile Conversions?
• ...

[pano]

Why not a LAB/32 with floating point values then?

[NotMyFault]

There seems to be a huge gap between theoretical benefits and actual demand, plus implementation effort, compatibility issues (no other app capable). And you seem to be the first and only user requesting this feature. Would you (as developer in the place of Affinity/Serif) spend some 100.000€ development cost for such a feature? Or can Affinity sell some 10.000 more licenses just for this feature?

[pano]

If this feature is going to cost them 100k, they can shutdown immediately.

They only need to implement a new pixel format for TIFF files. This won't be so difficult if they use libTIFF. Once they have Float LAB<->XYZ (that's likely already in a float format) it's done and they can put it in their internal working format. This may take a senior programmer a couple of days.