LUTs created from adjustment with HSV checkbox ticked export as if done in HSL

[ultrainfra]

Running Affinity Photo version 1.10.4.1198 on Windows 10..

In the HSL adjustments panel there is a tickbox labeled "HSV" which switches the adjustments to HSV mode. Keeping all the numbers the same, switching to HSV mode will look different since HSV has different properties. However, when you go to export a LUT , the LUT will look like HSL regardless. 

There are other little bugs with the lut export I've come across but this one is the most problematic for me (and I dont recall the others at the moment) because it means a LUT I try to design using HSV is unable to be saved as a LUT. 

I attached the LUTs exported using HSL and HSV modes respectively below. 

To reproduce this:

1. Make the following adjustments with the HSL adjustment layer:

Yellow : Luminosity 15%
Green: Saturation -40% ; Luminosity 70%
Cyan: Hue -10% ; Saturation -35%; Luminosity -20%
Blue: Saturation -5%; Luminosity 30%

2. Leave HSV checkbox unticked. Export a LUT and name it HSL. 

3. Re open the adjustment layer, and tick the HSV box. Re-export a LUT named HSV. 

4. Disable the adjument layer, and create a new LUT adjustment layer. Load the HSV lut. Notice that the results appear as if the HSL mode was used. Load the HSL lut and note that it is no different in appearance.
 

HSL.cube HSV.cube

[ultrainfra]

Anyone else having this issue?

[walt.farrell]

27 minutes ago, ultrainfra said:

Anyone else having this issue?

Not exactly.

First, I found your HSL settings too subtle, at least with my test image. So I made a simpler one that made a huge difference in the image. I then checked the HSV box and verified that it also made a huge difference, but obviously different than without HSV checked.

I then exported each as a .cube file, then Opened a different image, and pasted the HSL adjustment layer into it and verified that it also made a huge difference in that image.

I then deleted the HSL adjustment in the new image, created a LUT adjustment, and loaded one of the .cube files. No difference at all. I then deleted the LUT adjustment, made another, and loaded the other .cube file. Still, no difference.

My initial conclusion is that HSL adjustments are not captured by File > Export LUT... at all, currently. I have tested this with 1.10.4 and with the 1.10.5 beta, and in 1.10.4 with Hardware Acceleration On and Off.

Next test (for another day) will be to see if any other adjustments are currently being captured by Export LUT..., or if the function is completely broken.

[ultrainfra]

3 minutes ago, walt.farrell said:

Not exactly.

First, I found your HSL settings too subtle, at least with my test image. So I made a simpler one that made a huge difference in the image. I then checked the HSV box and verified that it also made a huge difference, but obviously different than without HSV checked.

I then exported each as a .cube file, then Opened a different image, and pasted the HSL adjustment layer into it and verified that it also made a huge difference in that image.

I then deleted the HSL adjustment in the new image, created a LUT adjustment, and loaded one of the .cube files. No difference at all. I then deleted the LUT adjustment, made another, and loaded the other .cube file. Still, no difference.

My initial conclusion is that HSL adjustments are not captured by File > Export LUT... at all, currently. I have tested this with 1.10.4 and with the 1.10.5 beta, and in 1.10.4 with Hardware Acceleration On and Off.

Next test (for another day) will be to see if any other adjustments are currently being captured by Export LUT..., or if the function is completely broken.

Interesting, the HSL adjustments are captured for me. It's just that the HSV tickbox is ignored when exporting the lut. 

If you load the luts I attached into grossgrade you can see that they are captured, and that the HSV adjustments are identical. I'll screenshot the cube representation of the luts from grossgrade, in case you don't have that installed. 

[NotMyFault]

LUTs are broken  / non-working currently 

 

[ultrainfra]

2 hours ago, NotMyFault said:

LUTs are broken  / non-working currently 

 

I've found posts here about LUTs not working going back to 2017 so it seems that they haven't really been working properly for almost 5 years now. Or at least, have had issues more than once. 

[NotMyFault]

There is often a small time windows where functions are actually working (on MacOS), when James needs them for creating one of his great tutorial videos. James uses mostly beta releases on MacOS. On Windows, old bugs often reoccur, or never get fully fixed at all. Yeah this is really frustrating.

[Dan C]

Hi @ultrainfra,

Thanks for your report & our sincerest apologies for the delayed response here, we were extremely busy over the Christmas period and working from home during the pandemic is unfortunately extending our response window to be longer than normal, many thanks for your continued patience and understanding here.

On 12/29/2021 at 2:48 AM, ultrainfra said:

In the HSL adjustments panel there is a tickbox labeled "HSV" which switches the adjustments to HSV mode. Keeping all the numbers the same, switching to HSV mode will look different since HSV has different properties. However, when you go to export a LUT , the LUT will look like HSL regardless. 

I can confirm I've been able to reproduce this here and I've logged it directly with our developers as a separate issue so it can be investigated and hopefully fixed shortly.

I hope this helps

[iconoclast]

Hi everyone!

I'm not sure if it is the same issue as reported here. Yesterday I tried to create a LUT on my own for the first time and followed the instructions in this video-tutorial. Not really too complex, I think. But it didn't work correctly, as you can see on my screenshot below. The left image on that screenshot is the image I took the adjustments from for my LUT. You can see them in the layers panel (only Adjustment Layers, no Blend Modes, only one Adjustment Layer with reduced opacity). The right image is the same one as the left, the source image, but with the LUT instead of the other Adjustment Layers. Should look the same, right? But somehow it doesn't. Am I doing something wrong or is there still a bug in the LUTs function?

I'm on Windows 10, Affinity Photo 1.10.4.1198.

[Dan C]

Hi @iconoclast,

Sorry to see you're having trouble!

I've followed the tutorial provided and attempted to recreate your document setup here and this has worked as expected for me, I've included a copy of the document and resulting LUT created below - you can enable/disable the LUT layer and the group to see that these match.

Could you please provide a copy of your Affinity document? If you wish, you can delete the pixel layer and I will use a different image with your adjustments to check this

DSC_0639.afphoto testinglut.cube

[iconoclast]

Hi Dan, thanks for your reply!

Your files work pretty fine, as far as I can see. Unfortunately my own ones don't. Couldn't even upload them to this forum. Don't know why. Server error, repeatedly. The LUT-Problem seems to be related to the certain images I tested. I tried a Stock Photo from Pexels, and it seemed to work as it should, as far as I could see. But two other photos - one that I made with my old camera and one from a local photo studio - create odd results. Especially the second one.

My suspicion is that it has to do with the color profiles of the images. The second one has GIMP built-in sRGB. I suggest, I must have done some editing with GIMP on it in the past and was careless with the color management. The other one uses a sRGB from Hewlett Packard. Must be the original profile of my old camera.

As I created a LUT from the second image after I converted its profile from GIMP's to another sRGB, it seemed to work. At least much better. Will test it out a little more tomorrow, before I give a final judgement.

Thanks again so far!

[iconoclast]

OK, I did some research in the meantime. In fact, it doesn't seem to be the color profile or even the certain image. Must have to do with the adjustments somehow.

I created a new LUT with the same adjustments from a Stock Photo and got the same problem. The same photo looked verry different with the LUT than with the adjustment layers (see the attached screenshots below). It looks like the Levels adjustment isn't cosidered in the LUT, because the result looks the same with the LUT as with deactivated Levels adjustment layer (second screenshot).

Here are my adjustments to reproduce what I did:

1. First I created an adjustment layer for the Channel Mixer with the following adjustments:

RGB,

Red channel: 100, 15, 14, 0, 0

Green channel: 30, 98, -29, 0, -4

Blue channel: 10, 35, 50, 0, -8

Alpha: 0, 0, 0, 100, 0

2. Then I created the Levels adjustment layer with the following settings:

RGB,

Red: 4, 100, 1, 0, 100

Green: 2, 77, 1,189, 0, 100

Blue: 0, 70, 1,097, 0, 100

Alpha: 0, 100, 1, 0, 100

Master: 1, 97, 1, 0, 100

3. Then a HSL adjustment layer with:

HSL,

0, 25, 0

4. Finally I created a Curves layer

RGB,

Master: X: 0,562; Y 0,44

I think, the certain values are not the important point. My impression is that it has to do with the Levels adjustment layer. Even because the Master adjustments was reset to default after I reloaded the image.

Image with all adjustment layers on the left and with the LUT on the right:

Image with deactivated Levels adjustment layer on the left and with LUT on the right.

 

[Dan C]

Many thanks for this further info and screenshots! 

4 hours ago, iconoclast said:

It looks like the Levels adjustment isn't cosidered in the LUT, because the result looks the same with the LUT as with deactivated Levels adjustment layer (second screenshot).

I agree, and I've been able to replicate this here - FWIW it appears as though the 'Master' channel changes in the Levels is being exported, however the changes to the Red, Green, Blue & Alpha channels are being lost when exporting the LUT, which is a bug I'm logging with our developers now

[ultrainfra]

I insalled the latest update to Affinity recently and it appears this issue still persists. Current version is 1.10.5.1342. Adjustments done with the HSV mode enabled for the HSL adjustments panel still export as if the HSV tickbox were unchecked. Hence, applying the LUT to the same image fails to reproduce the same adjustments as HSV.

If any devs see this, do you know if fixing this issue is on the to-do list?

[iconoclast]

I think there must be something wrong with the self exported LUTs anyway, because if I use the ones I created myself, they take a lot more time to apply their effect to the image than all the other LUTs I have downloaded from web.

[ultrainfra]

10 minutes ago, iconoclast said:

I think there must be something wrong with the self exported LUTs anyway, because if I use the ones I created myself, they take a lot more time to apply their effect to the image than all the other LUTs I have downloaded from web.

That's odd. I haven't noticed anything like that. What dimensions are your luts? 

If you use the small 17 * 17 * 17 cube size that's the default, it might take a longer time because there's more interpolation to be done between the points defined by the LUT. Alternatively, if you are using a very large size, that would mean the program applying the LUT has a larger file to load into memory. Good LUT sizes are 33*33*33 or 64*64*64. Most LUTs you'd download from the web are one of these two sizes. 

It's also possible that the exported LUT contains out of gamut values (less than zero or more than one). I can't recall at the moment if these values are clipped when exporting LUTs. Sometimes that "upsets" programs that apply LUTs.

Otherwise, I'm not really sure why that would happen to you. 

 

[iconoclast]

That's interesting, because as far as I remember I made it as the official tutorial and even another one on Youtube told me and always dragged the Quality slider to the max. It always was a bit of a mystery for me why this slider exists anyway if you should always choose the maximum quality. But of course I always want the best quality, so I didn't ask for it.

Thanks for the hint! I will check that out.

[Dan C]

1 hour ago, iconoclast said:

That's interesting, because as far as I remember I made it as the official tutorial and even another one on Youtube told me and always dragged the Quality slider to the max

I had noticed this recently when re-watching the older official tutorial for LUTS - I believe James was using the highest quality as an example here, but it certainly could have been explained clearer as to the use and repercussions of such a setting.

I'll be sure to suggest better wording in any future re-writes/revisions of this video!

In regards to the quality itself, I certainly don't believe that the max value is required and this would absolutely explain the difference in load times for 'Affinity LUTs' vs non-Affinity ones - as most LUTs are created using either 16x16x16 or 32x32x32 AFAIK 

[ultrainfra]

On 3/23/2022 at 12:24 PM, Dan C said:

I had noticed this recently when re-watching the older official tutorial for LUTS - I believe James was using the highest quality as an example here, but it certainly could have been explained clearer as to the use and repercussions of such a setting.

I'll be sure to suggest better wording in any future re-writes/revisions of this video!

In regards to the quality itself, I certainly don't believe that the max value is required and this would absolutely explain the difference in load times for 'Affinity LUTs' vs non-Affinity ones - as most LUTs are created using either 16x16x16 or 32x32x32 AFAIK 

Hi Dan, I see you have the staff icon under your name. Do you happen to be one of the developers, or have communication with them? I was wondering if you knew if the issue I first posted about here is going to be fixed. 

[Dan C]

11 hours ago, ultrainfra said:

Do you happen to be one of the developers, or have communication with them?

I'm part of the technical support team, but I do have access to both our bug report logs and contact with our developers

11 hours ago, ultrainfra said:

was wondering if you knew if the issue I first posted about here is going to be fixed. 

I can confirm this issue is logged with our developers in the aforementioned internal bug record, however there have been no updates to this recently - I'll be sure to 'bump' this report for you now to bring it to our developers attention once again.

I hope this helps!