Hi there,

At the moment I'm creating a texture baker using COPs. Inspired by the GameDevs Maps Baker because it is so fast and a lot more straightforward than using Mantra/BakeTexture Rop and a shader that uses renderstate()

In a VOP COP I'm reading an 8bit PNG file and I want to read the pixel values untransformed and “untouched”.
There is the scrcolorspace argument but it seems it doesn't really matter which option you use.
If set to “auto” it assumes values are sRGB and transforms the values to linear.
If set to “linear” it treats the values as sRGB and transforms the values to linear.

The manual states the following:

“srccolorspace”, string

Specifies the color space in which the texture is stored. When texture values are accessed, they will be translated from this space into linear space for rendering if needed.

auto

(default) Determine the source color space based on the file. Currently, this will assume sRGB color space for 8-bit textures and linear for all other textures.

linear

Transform to linear space. This currently only affects 8-bit textures, since all others are assumed to be already in linear space. Use this option to force linear interpretation of textures used for bump or displacement maps.

The VEX colormap's scrcolormap “linear” option only does things correctly according the how this option is described in the manual.
But! The option is called Source Color Space so this should be the same as Image Color Space from the File Cop.
The manual for the VEX colormap's scrcolormap argument also describes the options as “from this space into linear space”
If the source colorspace is set to “linear” it should not do a transform if the target colorspace is linear.

The File Cop has some more features.
First I can disable Linearize Non-Linear Images parameter which gives me the desired untransformed and “untouched” values.
If I enable the Linearize Non-Linear Images parameter then I have 3 options for the Image Color Space parameter.
If set to Detect From File it assumes values are sRGB and transforms the values to linear.
If set to Linear it treats values as linear already and gives me the desired untransformed and “untouched” values.
If set to sRGB it treats the values as sRGB and transforms the values to linear.

If you ask me then the File Cop does things correctly.

I can't believe I'm the first one to use colormap() with an 8 bit image and bump into this issue.
Please tell me it's a human error on my side because I doubt Side Effects is going to change (fix) the behavior of such an essential function. Although adding an option for “Linearize Non-Linear Images” and setting its default to ON it would stay backwards compatible.

As work around I could just not use the colormap() and use the File COP, as a second input to my VEX COP, instead.
But I like to use the area sampling features that the colormap has. I don't want to write my own code for that.

Anyone?

Cheers,
benS

Actually now that I read the manual again there is a contradiction where it describes the “linear” option.
I missed the bit where it says “interpretation” which is actually the expected behavior.

Transform to linear space.

This is wrong.. as is the result of the colormap() function.

This currently only affects 8-bit textures, since all others are assumed to be already in linear space.

This could be left away for linear.

Use this option to force linear interpretation

This is correct. Although not the result of the colormap()

of textures used for bump or displacement maps.

This could be left away as well in my opinion…

Linear means it doesn't do anything when transforming the color to the working space, it's a no-op.

Exactly it should be a no-op…

Hello Ben,

Did you ever get this to work? I am running into the same issue. I seem to be lacking the control to sample a 16bpp linear encoded normal maps the same way as a 8bpp linear encoded map ( I want colormap() to return the same value on two images if the only difference is 8 vs 16 bit per channel.)

Adding srccolorspace linear does not see to change anything for me.

Thanks,
koen

Edit:

While I was preparing a repro scene for sidefx, I found like my problem is likely that colormap() has a hard time with 8bpp tiff's, they all are treated as 16bpp, sorry for the noise

Hi Koen,

To answer the question; no my only way to work around is to tell people to use 16 bit.
I did not find a way to use the colormap() function to read in a 8 bit PNG file in a way that it wouldn't modify the values in the file.

Your problem doesn't sound like noise but more like you found another undocumented undesired feature of the colormap() function.
In my case it was wrongly assuming a certain colorspace based on bitdepth, in your case it is wrongly assuming a certain bit depth based on file format.

Although I like the flexibility loading images in VEX it has also caused more confusion because of caching the files.
I've been using the trick from the Game Dev bakers to link the Force Compile button to a Reload Textures button on my HDAs.

Using a File Cop might be better after all because it allows the control over bitdepth, colorspace and cache.
But every image would need it's own File Cop node. This would mean unlocking the HDA and doing some scripting.

cheers,
benS

Was investigating a similar issue today and filed a bug report to SideFX. I assume you guys already are aware too, if you've submitted bug reports, but for the visibility of anyone else with this issue - it appears that this is fixed as of 18.0.376