Color accuracy 32 bit - how to archive - things to look out for ...

Dear Developers,

I am currently trying to compare color Vector values of rendered pixel against set color in the editor.

While this works fine for 8Bit RGB I am having trouble to get it to work in 32 Bit eg. 0.001 steps of color.

What are the gotchas I have to doublecheck ?

• My render settings are linear 32 bit
• My Project is set to Basic, Linear
• My Render storage image is set to 32 (96) Bit

My returned Values in Python are for a test all matching but not recognized for comparison.

if color in colorlist: # -> returns no matches

Color generated = Vector(0, 0, 0.001)
Color object applied and readout = Vector(0, 0, 0.001)
Color rendered pixel = Vector(0, 0, 0.001)

only the colopicker in C4D Pictureviewer gives me Vector(0, 0, 0.013) which should not be a problem hence the retrieved rendered pixel value is Vector(0, 0, 0.001)

Any tips on color ?

And if any on comparing c4d.Vectors in python hence the seem not to match.

kind regards mogh

ignore the output on line 3 in the console its just a reminder for me from different part of the code

Hey @mogh,

Thank you for reaching out to us. What is likely getting in your way is the so called Enable Color Profile option of the Picture Viewer. The option actually acts more like a display transform which is applied to bitmap data in the picture viewer.

When you disable it, your values will likely be what you expect them to be, "raw".

Cheers,
Ferdinand

Hi again.

As mentioned in my other Post it seems Render Instances Produce "shifted" colors when measured as pixel value in Code as also in the Picture viewer.

Is this a limitation of render instances ?

When I switch the render Instances to "Classic" Instances the produce the correct color in the rendering and in pixel readout from code ...

kind regards
mogh

Hey @mogh,

that is hard to say. The search terms "instance pv", "instance picture", and "instance color" do not return anything in our bug tracker, and I am not aware of a bug that matches your description.

There is this bug report, but it seems to be a different case, because you seem to talk about the Picture Viewer (PV).

Render instances should have their color correctly shown in viewport instead of inheriting from instantiated object.

The ticket from above was classified as "not a bug", i.e., as intentional. With that being said, I would not be too surprised if there is a bug in the PV, because in the wake of OCIO we had some troubles with the PV.

I would check first if the render output serialized to disk contains the correct data or not. When OCIO is on, you will not see colors in render space anyways in the PV because colors are there then intentionally in the view transform. I documented this for C++ in the OpenColorIO Manual. But I think you are not using OCIO but simply something like this:

In this case the "render space", i.e., color definitions in code will be in the sRGB space with a gamma of 1.0 and the "display space" will be sRGB with a gamma of ~2.2. unless you uncheck the option I showed you above. However, BaseBitmap instances can have still their own color profiles associated with them. With 2023.0 things got there a bit more complicated, because BaseBitmap instances now not only carry color profiles for their bitmap profile, but also an OCIO profile for the render space, display space, and view transform. But you cannot deal with this in Python, because the necessary interfaces elements have not been yet wrapped.

So, long story short: Are you talking about the same thing the ticket is talking about? If not, could you please provide some code snippets and in/output examples for what is going wrong? The whole PV color management bugs are tricky to track and report. The more precise you are, the better are the chances of things being fixed or for me providing a workaround.

Cheers,
Ferdinand

Hi @ferdinand ,

I might not come up with a striped down code quickly, I can tell you that i render scenes without any materials just display color ... everything set to linear 32 bit as far as I could cobble together myself ... nothing special because I code R20 and 2023.

I suspected something like:
Render Instance is accessed in memory (and the shifted because of internals) and then rendered wrong with the color of the original polygon.
"Classic" Instance - Polygon is copied into place and inherits the correct color from the Classic Instance

Before fixing my code with changing all render instances to classic and back - I also could not reproduce the issue with generic cubes ....

from memory the color of one of the checked instances shifted from (0.016, 0.56, 0.4) to (0.016, 0.56, 0.8) pixel readout was 0.7999999999999999999324324 ... see picture

Edit:

here is a Picture with "Classic" Instance and Render instance Display Color renderings ...

kind regards

Hey @mogh,

Thank you for the clarification. I will have a look, but this seems indeed to be identical to the ticket I quoted above. The developer owning this project classified the ticket as "not-a-bug" because apparently he considered this behavior to be intentional.

I will check out what is what, optionally put your scenario in said bug-tracker ticket or create a new one, and then come back here. As a general FYI, this strikes me more as a general bug report, since there is no coding really involved. Normally, they should go over our support portal, but we will deal here with this one directly.

Cheers,
Ferdinand

edit: Eh, I forgot - on which version are you? 2023.1.3 I assume, judging by your first screenshot?

Thanks, @ferdinand

Yes seems intended but could be troublesome if you use mograph / redshift object color to drive something ?

C4D Version : 2023.1.2

A solution to guide the user could be to disable the object color when set to "Render Instance" , but from a UX standpoint I am not a fan of taking away control from the user.

thanks for taking it to CS
kind regards mogh