Jeff Lait

Very nice cheat sheet, thank you for figuring this all out...

UV to Polar and Polar to UV unwrap the polar coordinats about the (0,0) origin of space. By having uvmap1 be in image space, you get the zero (0,0) at the center of the image, so the desired effect.

For uvmap3, you want to generate the angle values 0..1 and distance values 0..1 across your texture; this could be two horizontal and vertical ramps; but uvmap3 in texture mode also generates that sort of perpendicular ramp.

After uvtopolar1, the range of our values are 0..1 for angle (as it is in "Circle/2Pi" mode) and 0..1.41 for length (as it was distance of the 2-sized square). Since you want to truncate at 1, you want to treat 0..1 range of the incoming coordinates as teh entire image - this results in sample3 being in texture space.

polartouv1 generated coordinates with the pole being at the origin (0,0), so thus you want to sample the image with (0,0) being the center of the image - so sample3 is in image space.

This complexity is brought to you by the existence of negative numbers in copernicus. Stuff as simple as "normals" immediately becomes tricky to store as there are two ways to do it; the obvious way for those from 3d (as -1 to 1) and the obvious way for those from texturing (as 0 to 1 with 0.5 being "center").

Ignoring the issue of data/display windows and working with square images; the "texture vs image" question is mostly if your coordinates have (0,0) as the corner of the image or the center of the image. This setup is doing both so ends up using both.

@dst accepts only float4, but OpenCL will widen float -> float4 for you. It doesn't widen the others.

Varying Layer means the real type of the output will not have to be strictly float4.

The problem is we want to write a gamma kernel, but not have to write a float, float2, float3, and float4 versions of it. So we write only the float4 version, and let COPs throw away the extra data when we write to @dst. Likewise, when we read from the source layer we implicitly widen.

This does mean we are doing extra computation; but as the time seems to be dominated with the memory costs we bear with it...

If using #bind to set up the signature, the varying is created with the float? type. The size for outputs will then be determined by the first menu of the "Metadata" option on the signature page. By default this is "First Input", which means all the varying writeable layers will match your first input, which usually is a good guess.

You can alternatively set it to "Match Name" so the source of the same name will be used, if it exists, or specify a specific input to copy the size from.

Checking the code, we aren't binding Alpha :< So the alpha attribute is not supported. I've submitted an RFE (152678)