levels (exposure) shifts while inserting 32-bit (linear) layer(s) into 16-bit document

[marcus.fehse]

it’s a photo2 behaviour: while inserting a CGI overlay

rendered to HDR/32-bit openEXR documents as a layer or a group of layers into a 16-bit document containing a digiphoto

levels (or exposure) of the inserted layer(s) shifts to dark.

no idea, if i miss a setting (which should be the same in photo1 and photo2).  in photo1 inserting these layer(s) gives the expected result.

[NotMyFault]

RGB/32 differs from RGB/16 not only in color depth, but in gamma (1.0 vs 2.2) and unbound color values (larger than 1.0 is possible).

You should really preprocess RGB/32 images (to RGB/16) before adding them to other document formats:

• Clipping or tone mapping unbound color values
• gamma-conversion 
• color profile conversion 

There are decisions to made, and simply copy/paste gives you one fixed interpretation which might be suboptimal (like in this case)

 

[marcus.fehse]

hm.  i work with affinity photo 1 for some years now.  if i open some CGI content – always 32-bit HDR in openEXR format – and copy it into a 16-bit RGB document the software works in a – let’s say – consistent way.  there is now visible difference between the 32-bit HDR document and the 16-bit RGB document at the end.  i would deduce that photo 1 interprets the unbound color values of my openEXR document(s) using some given gamma and clipping.  ... and imagine: i’m happy with that!

i would understand, if the RGB/32 HDR content would show up darkened because of the gamma and clipping or whatever in the new software.  but it shows up like expected (and already known from photo 1)!  the problem occures with copy/paste.  in other words: in affinity photo 2 i’m forced to decide either to convert my RGB/16 document into RGB/32 color space or my RGB/32 HDR content into RGB/16 color space before composing it even if i’m fine with the fixed interpretation the software already did to show me the RGB/32 HDR content on my 8- or 10-bit device.

as any user (aka. client) i’m wondering: why should i?

most decisions for brightness, light temperature and so on are already made in CGI (under the influence of monitor/graphics card gamma, operating system and software) before rendering.  in most cases there is no need to adjust it once again.  just take the RGB/32 layer and paste it to the RGB/16 document like seen in the other tab (and like it did in the previous software version).  from the users point of view there is no need to reinterpret the data while pasting.

 

[NotMyFault]

Can you show us the same workflow steps, in both V1 and V2, leading to different results?
including the V1 based Affinity document, and the RD file used as source for copy/paste?
 

The one of the mods might be able to try to reproduce.

You OCIO setup may differ between V2 and V1, or other settings.

I know there are some open bugs about handling of copy / paste, but this issue might ne a new one.

[marcus.fehse]

i made a screen recording for you.  hope this helps.

to provide the source files i need more space on your the server (my files are a bit too heavy).

Edited March 7, 2023 by marcus.fehse
a misunderstanding

[lepr]

12 hours ago, marcus.fehse said:

hm.  i work with affinity photo 1 for some years now.  if i open some CGI content – always 32-bit HDR in openEXR format – and copy it into a 16-bit RGB document the software works in a – let’s say – consistent way.  there is now visible difference between the 32-bit HDR document and the 16-bit RGB document at the end.  i would deduce that photo 1 interprets the unbound color values of my openEXR document(s) using some given gamma and clipping.  ... and imagine: i’m happy with that!

i would understand, if the RGB/32 HDR content would show up darkened because of the gamma and clipping or whatever in the new software.  but it shows up like expected (and already known from photo 1)!  the problem occures with copy/paste.  in other words: in affinity photo 2 i’m forced to decide either to convert my RGB/16 document into RGB/32 color space or my RGB/32 HDR content into RGB/16 color space before composing it even if i’m fine with the fixed interpretation the software already did to show me the RGB/32 HDR content on my 8- or 10-bit device.

as any user (aka. client) i’m wondering: why should i?

most decisions for brightness, light temperature and so on are already made in CGI (under the influence of monitor/graphics card gamma, operating system and software) before rendering.  in most cases there is no need to adjust it once again.  just take the RGB/32 layer and paste it to the RGB/16 document like seen in the other tab (and like it did in the previous software version).  from the users point of view there is no need to reinterpret the data while pasting.

 

 

Colour management when pasting is broken in Affinity 2. It's still broken in beta 2.1.0.1713.

I have mentioned it in other threads but never made an official bug report because it has seemed inconceivable for the developers to not know about it, but I'm starting to wonder about that since we've had numerous releases of Affinity 2 retail and beta since the initial release in November.

[marcus.fehse]

15 hours ago, ,,, said:

Colour management when pasting is broken in Affinity 2.

good to know.  let’s hope it’ll get logged as a bug now!

[marcus.fehse]

On 3/6/2023 at 11:29 PM, NotMyFault said:

RGB/32 differs from RGB/16 not only in color depth, but in gamma (1.0 vs 2.2) and unbound color values (larger than 1.0 is possible).

You should really preprocess RGB/32 images (to RGB/16) before adding them to other document formats:

• Clipping or tone mapping unbound color values
• gamma-conversion 
• color profile conversion 

There are decisions to made, and simply copy/paste gives you one fixed interpretation which might be suboptimal (like in this case)

 

as already mentioned here: not helpful too.  you might know a lot about graphics, bit-depth and colour spaces but not enough about respectful behaviour.  if a user reports a bug (or what feels like a bug at least) the intention is to help the developers to improve their product.  „You should really preprocess ...“ is an advice based on your opinions.  you should really ask yourself if someone who reports a bug with the conclusion „in photo1 inserting these layer(s) gives the expected result.“  – which doesn’t sound like a first-time user – wants to hear it’s her or his fault.  itIsYourFault again, @NotMyFault!  just think about it.

... and sorry to all the others for getting off-topic!  i just hope my comment improves the quality of conversation in this part of the affinity-forum a bit.

[NotMyFault]

1 hour ago, marcus.fehse said:

not helpful too.

sorry to disappoint you.

1 hour ago, marcus.fehse said:

not enough about respectful behaviour.

again, sorry for disappointing you. Still difficult for me to understand how a regular forum user can be disrespectful to you in that matter. I don't get payed by you. All I can do is giving my honest best-practice advice, based on my personal opinions.

1 hour ago, marcus.fehse said:

if a user reports a bug (or what feels like a bug at least) the intention is to help the developers to improve their product

I'm not a Serif developer/moderator/supporter, and I assumed (my mistake?) this has been fully clarified before in one of my answers to another  thread started by you.

1 hour ago, marcus.fehse said:

is an advice based on your opinions

yes, exactly. What else do you expect from me I could provide to you?

[NotMyFault]

1 hour ago, marcus.fehse said:

i just hope my comment improves the quality of conversation in this part of the affinity-forum a bit.

It gives all readers a first class insight about your way thinking. 

Welcome on my "ignored user" list. This will of course improve the quality of your conversations, as I will no longer take part. Have a nice evening & rest of your live.

[lepr]

On 3/8/2023 at 2:40 PM, marcus.fehse said:

good to know.  let’s hope it’ll get logged as a bug now!

Doesn't look like Serif is interested.

[marcus.fehse]

31 minutes ago, ,,, said:

Doesn't look like Serif is interested.

how do you know?

[lepr]

14 minutes ago, marcus.fehse said:

how do you know?

I don't know.

I said: "Doesn't look like".

There is no comment by a Serif person.

[marcus.fehse]

12 hours ago, ,,, said:

I don't know.

I said: "Doesn't look like".

There is no comment by a Serif person.

i understand.  thank you for keeping this problem in your mind and bringing this issue up again.  hej, @serif did you notice the annoying „colour management broken while pasting“ BUG?  =;^)

Edited March 28, 2023 by marcus.fehse
added a word

[Lee D]

@marcus.fehseI've logged this with the developers to investigate. Can you please DM me a link to the files shown in the screenshots and video so I may link them to the report, they are only used for confirming/testing and are deleted after. I can send a Dropbox link to upload them to, just let me know in the DM, also please include your exact workflow, just so I have it as a reference.

[marcus.fehse]

1 hour ago, Lee D said:

@marcus.fehseI've logged this with the developers to investigate. Can you please DM me a link to the files shown in the screenshots and video so I may link them to the report, they are only used for confirming/testing and are deleted after. I can send a Dropbox link to upload them to, just let me know in the DM, also please include your exact workflow, just so I have it as a reference.

the files are on their way.  my workflow:

the aerial was developed in DxO and saved as 16-bit data in sRGB IEC61966-2.1 colour space.  the renderings are HDR saved as 32-bit linear openEXR files.  in most cases i add some layers for ambient occlusion or a depth layer and group them with a alpha-mask before pasting this to the photo.  but even the unedited openEXR file colour- or gamma-shifts when pasted to the 16-bit document.  my workaround at the moment is to change the colour space before pasting – either the aerial to 32-bit HDR or the rendering to 16-bit.  but this is not intended, isn’t it?

[Affinity Info Bot]

The issue "Exposure shift inserting 32bit (linear) layer(s) into 16bit doc differs in V2 compared to V1" (REF: AFP-6086) has been fixed by the developers in internal build "2.1.0.1781".
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us.