troy_s

It doesn't explain everything you are seeing. Exporting to various display referred bit depths isn't something that needs to be designed to in the classical sense. The problem is that there appears to be another transform creeping into the chain. My hunch is that it is the OS level display ICC, but I would love confirmation. The colour science behind the ICC approach isn't that complex. At risk of gravely oversimplifying, the protocol typically goes as follows: "Undo" the display referred transfer function to get to linearized values for linear algebra, if required. Almost always display linear. Take data from primaries and adapt to D50 ICC reference, if the reference isn't ICC's D50. Convert via linear algebra to destination adapted colorimetry, using the D50 reference. Adapt back to the destination white if the white doesn't match ICC's D50. Apply the nonlinear transfer display linear to display referred nonlinear transfer function if required. Examples would be the sRGB OETF. Assuming an image is encoded for standard D65 REC.709 primaries, and the transfer function is listed as an identity / no-op, aka "linear" values, (1) and (5) would result in a no-operation if using a half-decent linear sRGB / REC.709 profile. I say half decent because good gosh there are plenty of junk sRGB profiles out there. For the colour nerds out there, yes there would be a D50 to destination transform, which would be D65 in the case of REC.709 / sRGB, which means it most certainly is not a no-op in reality. The problem is that ICC is protocol based, so we are always discussing a source ICC and a destination. On the way to encoding, there are sometimes three. Those might be typically almost invisible: Source is assumed or tagged "sRGB". This is the first ICC in question. Reference space ("working" space in Adobe terms) where the pixels are taken "to" for manipulation. This is the second ICC. Output or encoding transform. This could be a display or print etc. This is the third. Affinity clearly lets you specify (2), but seems to obfuscate where (3) is coming from, or at least hide it. Your tests indicate that it is applying a transform there, which is all well and good except in the case of using OCIO, as the two systems are quite incompatible. The reasons for this begin with the lack of protocol metadata, that ICC protocol specifically requires to function, in an OCIO chain, but also covers into colour mangling with ICC's D50 requirements and other display referred considerations. TL;DR: The linear sRGB reference space would almost, sort of, kind of work as you want, minus the D50 protocol problem. Affinity would be wise to provide the display transform it is using from within the application, permit overriding with a selected ICC, and most importantly, allow one to turn off ICC management altogether if one chooses to use OCIO instead. Best of all worlds would be to provide clear handling at the tail end to embed / tag the display referred output with ICC information, as well as have the display referred output potentially colour managed for display via ICC protocol, versus OCIO. If you were to hack the system by tagging the output as linear sRGB, that too would fail as you end up with the same problem. You would need to hack the display transform to linear sRGB (OMG Yuck) then tag the image as nonlinear standard sRGB. Really yuck.

Are you sure about this? There are at least a few problems with this approach: You will have effectively transformed pure sRGB / REC.709 primaries to the primaries of your display, essentially breaking the integrity of your data. Specifically, the data encoded in the file would be idealized REC.709 lights, and assigning a profile then rolling through an ICC chain would convert the primaries to those of your display. Via the assignment, it would be identifying data as being display referred nonlinear where it is not. This would take the values between 0.0 to 1.0 of the EXR invert the transfer function when attempting to go to a linearized reference space, which @Mareck appears to be desiring. In the event that the reference were nonlinear in terms of transfer function, this would end up being a no-op, and create the illusion that it works. Neither of which are desired in most pipelines. The above two issues could be mitigated if @Mareck were wishing to work nonlinearly, by going to a nonlinear encoding to start with. The problem is that Affinity appears to be performing an additional transform to the display, which may be obtained via the operating system. It would be good to hear back from a developer on this. Are there any Affinity developers out there that can confirm that there is a display transform happening in this chain that is not listed in the settings?

There shouldn't be a compression. Possibly a clip. Scene referred linear sRGB / 709 should be identical in terms of the buffer (exception being the footnote below) to a linear profile ICC with 709 / sRGB primaries. The problem is in the handling given ICCs are designed for display referred graphic design (relative normalized luminance) work and not photographic work in the scene referred domain. Why the red channel would shift is beyond me unless you have an extremely intense and saturated red colour that was clipping somewhere along the dumping through the ICC chain. The discrepancy between your physical display and the sRGB OETF is not tremendous. A typical display more than likely targets a pure power function in the DAC that ends up 2.2 - 2.4. This matches the power function portion of the sRGB OETF reasonably closely. The linear toe of the OETF is where larger differences will show up, which would be in the deeper shadow areas of your display referred output. The point I make is that you don't want a conversion to sRGB's OETF at all. The primaries are identical, and the transfer function is already designed for 2.2 output. This means that you would want to simply generate the encoded values and "assign" the profile (aka tag not encode) to the encoded values, not "convert" (aka re-encode the data). Viewing the OCIO transform chain under the linear sRGB profile should yield 1:1. If it doesn't, a secret sRGB transform is happening somewhere. Perhaps Affinity is rolling the final output through the operating system's chosen display ICC? That is the kludgy way you work in a linearized reference space with display referred applications. Your data starts off tagged as official sRGB, then would be compared against the reference, which would be linear sRGB. The primary lights are identical[1], so the transform to the reference space aligned buffer would undo the OETF, yielding display linear values. On the way out, the reference would be identified as linear sRGB, which means linearized values using REC.709 primaries, and the output ICC (sRGB, Apple P3, etc.) would transform the primaries to the destination, and then lay the transfer function on top of that. In this way, you essentially end up with a linearized reference for manipulation, albeit within the crippled up ICC model, subject to possible display referred / ICC assumptions. [1] Under the ICC v2 chain, sadly the reference is enforced to be D50, which means your data isn't entirely subject to merely the transfer function, but also a chromatic adaptation transform to align the achromatic axis with D50. The opposite would happen on the way out.

Can you unset the ICC setting? That OETF encode is very much coming from the ICC chain, as the entire chain would break if it were hard coded. That implies that somewhere a display / monitor setting is set to something with the sRGB OETF specified in it somewhere. Finding which one it is will sort it. Am I correct in estimating that when you set it to sRGB linear for both that it is very close, with a slight deviation in the lower values that is most noticeable?

That looks suspiciously like the sRGB OETF is being applied on top of the output stack. Are those all of the places where ICCs are integrated in Affinity? If so, alter the first one to be linear sRGB, as the transfer function / display referred encoding is being manually applied in this instance.

False. Scene referred linear is zero to infinity, with 1.0 meaning absolutely nothing. A scene referred image that was mastered under a particular series of transforms will need to replicate those transforms to achieve 1:1 between applications. In the case of your file, start by taking the scene referred data from the EXR and apply the transforms in question. I believe that Affinity had a problem applying Looks via OCIO, and as such, the proper transform would need to manually stack the look into the transform chain. In this instance, the output would be mastered for whatever the output destination was designed for. ACES for example, has many potential outputs. Filmic was designed for a typical 2.2 sRGB display. If one accidentally appends an ICC on top of that chain, the output would become broken as one would be applying an additional series of transforms via the ICC in question. To start, disable any ICCs in your chain, as well as any power functions (Awful term "gamma"). Apply the same OCIO transforms on your image as you were doing in the other application. Do you see 1:1? If so, does the exported display referred format appear 1:1?

Awful advice in here. Just simply awful. @Mareck I suspect the issue is that you have an ICC chain stacked on top of the OCIO chain, and it is further adjusting the assumptions in the image. I can't know more without further information.