Affinity Designer HSV does not match Affinity Photo HSV result.

[NPC_Daniel]

I'm using a MacBook Pro (13-inch Mid 2012)
Mac OS Catalina 10.15.7
Affinity Designer 1.10.6 with Metal compute acceleration enable
Affinity Photo 1.10.6 with Metal compute acceleration enable

Here's a summary about the issues that I'm having:
( Files attached or: https://www.dropbox.com/s/3jzp0azhmbvoc8x/Images.zip?dl=0 )
( Ignore all "._file" files as they are thumbnails )

I have this Image 'A', which is a Normal Map that represents X,Y,Z, information stored into the RGB channels respectively. (Here's a more detailed explanation about Normal maps: https://en.wikipedia.org/wiki/Normal_mapping )

But texture 'A' needed to be "boosted" to fit the current standard normal space. So 'A' needed to be exactly the same as 'B' but instead I'm getting as a result image 'C' and you can see on 'Channel Breakdown' that the result of 'C' is way different than 'B' in a weird way.

The methods used to achieve 'B' and 'C' are the following:

B: Can be achieved by multiplying 2.25 times 'A' (or 225%); or increasing the saturation using HSV by a 47% inside Affinity Photo (but this method has its flaws as well)

C: Increasing the saturation using HSV by 32% inside Affinity Designer.

But the issue here is that the two different programs yield a different results. 

You can see on 'P-AD' that this is the method used to create 'C', on the center you will find a square with the target color that is separated from the image or any adjustment layer (You can see this on the Layers panel)

And if I try to replicate the same steps on Affinity Photo the result is way different, you can see on 'P-AP1' that I did the same steps and the target color was not reached so I needed to increase the saturation up to 47%, and the result is still different from 'C' but closer to 'B'.

I also subtract 'C' from 'B' and result was clear, there's a slight discrepancy on the color on a diagonal manner ('Subtract') that can be seen on 'C' specially on the top left circle.

So I would like know what is HSV doing inside Affinity Designer ('C' & 'P-AD') and if 'C' can be fixed to match 'B' or 'P-AP2'.
Or if it can be reverted from 'C' to 'A' and how.

Images.zip

[Callum]

Hi NPC_Daniel,

Me and a member of the QA team have tried reproducing this here but we aren't having and luck I'm afraid. If possible could you provide a set of simplified steps we can follow in order to easily reproduce this problem? Please could you also check that you are using the same colour profile in both apps?

Thanks
C

[NPC_Daniel]

@Callum 
Sure, I attached the images for the color profile, they are both using RGB/8 bits IEC61966-2.1.

Step by step:

Affinity Designer:

1. Import 'A' into Affinity Designer
2. Add and adjustment layer: HSL Shift Adjustment 
3. Check the "HSV" checkbox inside the adjustment window
4. Increase Saturation by 32%

The background color should ended up being:
R:127
G:127
B:255

This result is 'C'.

Affinity Photo:

1. Import 'A' into Affinity Photo
2. Add and adjustment layer: HSL Shift Adjustment
3. Check the "HSV" checkbox inside the adjustment window
4. Increase Saturation by 47%
5. EXTRA: Select the layer with the Adjustment attached and rasterize the layer

The background color should ended up being:
R:127
G:127
B:255

If you analyze both results, you can see that they are different, specially 'C', the result achieved using Affinity Designer. If you go to the 'Channel Breakdown' and 'Subtract' you can see that 'C' has a noticeable different on a diagonal way, specially on the bottom right corner of the top left circle. The squares at the bottom of each image represents coordinates. Bottom left ones are diagonals and bottom right ones are vertical and horizontal. The result should look like 'B' but that's not near perfect.

'B' can be achieved by the following steps:

1. Import 'A' into Affinity Photo or Affinity Designer.
2. Duplicate that layer twice
3. Select the top 2 layers and change the Blending mode to "Multiply"
4. Select the top layer and reduce its opacity to 25%

The background color should ended up being:
R:127
G:127
B:255

Affinity Designer is the one that has a problem and shifts something the the saturations goes up.

[Chris B]

Hey NPC_Daniel,

I've been working with Callum on this and I've followed everything you suggested and I have actually reproduced it. I did the same test on Windows but that was correct. I have since discovered it seems that Hardware Acceleration (Metal) seems to be affecting how this renders. If you go to Settings > Performance and change the Display to OpenGL and disable Metal, is it correct for you?

I will get this logged with the developers - thanks.

[Chris B]

In fact, it might not even be Metal causing this. I disabled it in a further test, colour picked and got the same values as Designer - I think there's an issue with the colour picker because visually I can see a distinct different even though the picker currently is picking the same value.

Some more work needs to be done here from me so I'll update you once I've nailed it down.

[Chris B]

Update - I've logged this with the developers. Something isn't right here - I get the same feedback from the Colour Picker Tool despite seeing a difference in the actual background using my eyes.

If I pick the screenshot I get the different readings.

 

[NPC_Daniel]

First of all, thank you for looking into this.

The images that I've provided were specifically done so you can analyze what HSL is doing on each RGB Channel as I really need that information to be right, that's why I also sent you 'B' which is the perfect target image. I currently have a lot of images with the same problem as 'C', so if you not only found what is causing this problem but know a way to fix them or revert what HSL did, please let me know as I need to fix all the images that were damaged by the adjustment layer.

[Chris B]

I'm waiting for feedback on the bug report. I'm trying to find out where it regressed and I'll update you once I find anything.

[NPC_Daniel]

Any progress on this? I really need to find a way to fix or revert the damage done to several images.

[Patrick Connor]

24 minutes ago, NPC_Daniel said:

Any progress on this? I really need to find a way to fix or revert the damage done to several images.

As it happens there is a fix likely to make it into this week's 2.1 beta build. Once the new beta is made available (latter this week) and if you are a V2 customer, you can try the fix for yourself by signing up to the V2 Customer beta process. Unfortunately we are not planning on patching Version 1 for this sort of problem as explained when we released V2.

[NPC_Daniel]

Okay, I get it, but can you share with me what is HSV doing inside Affinity Designer? You're fixing the problem so this won't happen again, but I still need to fix all the images that were damaged by that adjustment error. So I would like to know if there's something I can do to revert or fix this error by doing some steps to achieve the correct result. Or let me know in a math way what HSV did to the images so I can "reverse engineer" a solution. 

[Affinity Info Bot]

The issue "Designer rendering HSV Adjustment differently to Photo" (REF: AFP-6003) has been fixed by the developers in internal build "2.1.0.1720".
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.

[Chris B]

Hey NPC_Daniel,

I've just tested opening the .afdesign and .afphoto files in this new build and the adjustments have updated and are now picking correctly as well as looking correct. So if you still have the .afdesign and or .afphoto files you will have nothing to do other than to export the .tga files again.

[Patrick Connor]

17 hours ago, NPC_Daniel said:

can you share with me what is HSV doing inside Affinity Designer?

It is doing the wrong maths, simple as that. Photo does some calculations through more accurate different code that does not suit the complex documents in Designer. Both V1 applications are meant to draw the identically, but a bug in code that Designer uses (and Photo does not) means they look different.

My only suggestion is that you use Photo V1 to correct the Affinity Designer files. Photo can open edit and save the Designer files.

[NPC_Daniel]

The issue here is that I no longer have the raw files and only the result ones, in the files that I initially sent you can see that 'C' is a TGA file, I have several TGA's with that adjustment already applied. And I would like to know if there's something I can do or steps to follow to fix the TGA files, even if there's math involved. That's why I wanted to specifically know what Designer was doing so I can correct them.

For example, is HSV is adding .5 of luminosity of each channel for 1% on the slider I can subtract .5% to revert to the original state. 

I need to know if there's a fix using only the result image, the TGA file, image 'C' as I no longer have the original file or image 'A'.

[Patrick Connor]

It is a one line change where "shift > 0" 

old code

          inline float ShiftSaturation( float saturation, float shift )
            {
                if (saturation == 0)
                    return 0;
                
                if (shift == 0)
                    return saturation;
                
                if (shift == 1)
                    return 1.0;
                
                if (shift > 0)
                    return fmin( 1.0, saturation / (1 - shift) );
                 
                return saturation + saturation * shift;
            }
 

new code

            inline float ShiftSaturation( float saturation, float shift )
            {
                if (saturation == 0)
                    return 0;
                
                if (shift == 0)
                    return saturation;
                
                if (shift == 1)
                    return 1.0;
                
                if (shift > 0)
                    return fmin( 1.0, saturation + (1 - saturation) * shift );
                
                return saturation + saturation * shift;
            }

So you would need to undo the effect of this old line

                    return fmin( 1.0, saturation / (1 - shift) );

and then apply this new line

                    return fmin( 1.0, saturation + (1 - saturation) * shift );

I hope you can work it out. Beyond that we cannot help, sorry.