rgbtoi Procedural Texture - "rgbtoi" - weird results

[Ldina]

I am experiencing some strange behavior with Live Procedural Texture and the "rgbtoi" function. Perhaps I am doing something wrong, but if so, I can't figure out what it is. I'm on a MacBook Pro running Ventura 13.6.4, using AP 2.3.1. I was trying to create a Toning Preset using Procedural Textures, but the display comes out very dark, which stopped me in my tracks. 

Here's the original image. I picked this image because it had a lot of different colors for testing. The below image shows only the base layer (the original pixel layer). The layers above the base layer are hidden.

I added a Channel Mixer Adjustment Layer and set it to grayscale and I get the expected result. It displays the weighted grayscale of the image (using approximately 30% Red, 59% Green, 11% Blue for the conversion to grayscale). Note the sample points in the Info Panel. They look about right to me and agree with the image as displayed on my monitor.

Below is a screenshot with the Procedural Texture Layer visible and the Channel Mixer Layer hidden. I used the "rgbtoi" function, which I believe does a similar RGB to weighted grayscale conversion as Channel Mixer (approx 30%R, 59%G, 11%B) and provides the output as grayscale intensity. The image displays extremely dark, but the sample points in the Info Panel are nearly identical to those shown in the Channel Mixer screenshot. The sample points do NOT agree at all with the displayed image. I'm guessing it is a "display issue" because the calculated values in the Info Panel seem to be correct. 

If I change the Layer Blend Mode of the PT layer to Color, Hue or Saturation, the image displays the same as Channel Mixer, but this shouldn't be necessary. And for my purposes, it defeats my intention of building a PT to do Toning. I could put a Channel Mixer Layer (set to Grayscale) below the PT Layer, but that shouldn't be necessary, should it? Seems like a bug to me, unless I am missing something (which is very possible). Any help would be appreciated. 

I'll also attach the afphoto file, created using AP 2.3.1. Thanks.

PT-rgbtoi.afphoto

 

 

 

[NotMyFault]

its a bug already fixed in 2.4 beta. PT filter was broken in multiple aspects in 2.3.1 on Mac.

[Ldina]

@NotMyFault Thank you. It was driving me crazy, so it's good to know it's a bug and is fixed in 2.4 beta. I'll probably wait for the official v2.4 release.

[NotMyFault]

33 minutes ago, Ldina said:

It displays the weighted grayscale of the image (using approximately 30% Red, 59% Green, 11% Blue for the conversion to grayscale).

rgbtoi uses different factors,  

https://en.wikipedia.org/wiki/Grayscale

The sRGB color space is defined in terms of the CIE 1931 linear luminance Y_linear, which is given by^[6]

[Ldina]

@NotMyFault Thanks again. 

 

[lacerto]

@Ldina, as rgbtoi is broken on macOS, why not just use direct percentage calculation on 0 to 1 range?

Another problem of course is that the input sliders have lost their value boxes (a bug that has existed there for years, I think that at some point they were there, at least as tool tips). So you need to be a bit innovative with the rulers to get exact(ish) values (30, 59, 11).

The attached file has the same traditional grayscale conversion also as a Black and White Adjustment to show that the conversions are equal. 

rgb2gray.afphoto

 

[Ldina]

@lacerto Thank you, Lacerto. That definitely works.

I came up with an alternative solution until "rgbtoi" and other PT functions are fixed in v2.4. I hard-coded 30%R, 59%G, 11%B into the formulas for each individual channel. As long as the a,b,c and d variables are set to zero, I get a straight BW conversion, since all three channels are identical. This results in a BW conversion which is indistinguishable from Channel Mixer (with CM set to grayscale). The a,b,c,d variables are for toning and brightness control. They allow me to adjust the color of the individual channels (by eye). The "d" variable allows me to control the overall brightness. I made that brightness adjustment "d*2" in the formula to allow for a much wider brightness range when working on dark images. So, this way, I don't have to worry about the position of the sliders to achieve a neutral tone. 

The slider settings of +17R and +20Y below give a warm yellow-orange tone to the image. I created a bunch of "Value Presets" for different tones. I wanted to use the rgbtoi function, but this works okay for now. 

Thank you!! 

[lacerto]

I downloaded 2.4.0 beta. Perhaps something was done with Live Procedural Texture, but rgbtoi still does not work, and there are still no value boxes for sliders:

 

Is there somewhere a log that describes the alleged fixes in this filter? I cannot see anything mentioned e.g. here:

I have build 2256, which I suppose is the latest? Nothing on the Windows side, either, rgbtoi still works, but no value boxes for sliders.

[NotMyFault]

Which Mac (CPU)  do you have? Some of the PT filter issues affected M1 (and maybe later) models specifically.

then i see you are using different formulas than the OP.

[NotMyFault]

15 minutes ago, lacerto said:

have build 2256, which I suppose is the latest? Nothing on the Windows side, either, rgbtoi still works, but no value boxes for sliders.

 

[lacerto]

Well, if Metal computing is turned off, rgbtoi also works with the current release version 2.3.1 (and probably every version before). So nothing seems to have been fixed, at least in respect of rgbtoi.

I have M1, and I have tested this both native and Rosetta. On Windows rgbtoi works at least on 2.3.1 and Windows Pro 11 with hw acceleration on.

I don't hold my breath to see the slider value boxes returned, either.

[NathanC]

3 hours ago, lacerto said:

Well, if Metal computing is turned off, rgbtoi also works with the current release version 2.3.1 (and probably every version before). So nothing seems to have been fixed, at least in respect of rgbtoi.

I'm also seeing this when toggling Metal On/Off with this PT filter in release and the latest .2256 beta, i've now logged this with the developers.

[NotMyFault]

Very strange. I tested in latest beta and it worked there. But I entered formula from scratch, only copied image layer, not the PT layer. Will redo testing.

[Ldina]

7 hours ago, lacerto said:

Well, if Metal computing is turned off, rgbtoi also works with the current release version 2.3.1 (and probably every version before). So nothing seems to have been fixed, at least in respect of rgbtoi.

@lacerto Good catch! Thank you. I'm on a 2017 MBP using an Intel Processor and I found that rgbtoi works for me too if I turn Metal acceleration off. Just wanted to confirm this is the case with Intel Silicon, so the developers have this info. I haven't retried the Voronoi (cellnoise) function yet, but I may do so. 

[Affinity Info Bot]

The issue "Procedural Texture- 'rgbtoi' function canvas rendering inconsistent with metal enabled" (REF: AF-1963) has been fixed by the developers in internal build "2.5.0.2317".
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 @Affinity Info Bot to notify us.