pano

From

Yes, DNG opcodes need some love from Affinity

This is a feature request suggestion that will make Affinity much better for users of DNG cameras, so many users.

Many industrial camera don't have lensfun profiles.. only embedded data in DNG files

That's very annoying... seems very standard functions that Affinity can implement like other vendors did. ..at least basic lens correction functions

When opening DNG files with opcodes, for example with the FixVignetteRadial command, Affinity Photo is ignoring them. Adobe apps and Capture One are correctly interpreting these DNG commands. Please check the attached file in Capture One / Photoshop and in Affinity Photo 1.9 (but I guess v2 is the same story). It's a bit exagerated, but useful to check if opcodes are supported. Thank you mod.dng

Colors can't be subject to copyright, just the brand. Why Serif is not making it's own palette with a different name?

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.

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

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

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.

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.

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.

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

Where the LAB data comes from? Seems different to me