boberfly / GafferCycles

Cycles for Gaffer
BSD 3-Clause "New" or "Revised" License
84 stars 10 forks source link

image_texture node Colorspace UI enhacement #43

Open kubo-von opened 4 years ago

kubo-von commented 4 years ago

Hey @boberfly, This is more of a enhacement suggestion. First I though that the colorspaces are not working but after playing with the image_texture node for little I found that typing in the values exactly the same way as in Blender works eg: sRGB Non-Color or if OCIO is set to ACES _Utility - Linear - sRGB srgbtexture etc..

It would be more handy to have a drop down menu so one does not have to remember and type these. Although for ACES the colorspace should be filtered a little bit, not like blender currently has it, which is rather chaotic i dare to say: Screenshot from 2020-01-28 18-41-42

boberfly commented 4 years ago

Hey @kubo-von

I have only very recently started building with OCIO after fixing a linker issue so I'm glad this does work with the right strings! :)

The GafferArnold implementation I think also suffers from this issue with aiImage nodes, I'm curious to see what happens there, but I can imagine just making an enum list of strings that gets generated from some listing from OCIO would be the way to go.

Btw out of the box Gaffer comes with the config here: https://github.com/imageworks/OpenColorIO-Configs/releases/tag/v1.0_r2

kubo-von commented 4 years ago

Haha, ok so I'm digging into it while its still fresh from the oven :D

Arnold seems to have the same thing indeed,but it seems it has just three hardcoded values "linear, srgb and rec709"

I wish I could be of more help, but my programming skills don't go beyond Python. Can only provide test data and bug reports/cheeky enhancement suggestions. I'm testing features I use in other renderes now and trying to convert some of my personal projects to gaffer now. If you would need anything specific tested let me know! :)

boberfly commented 4 years ago

Yep keep the test scenes coming I want to fix these issues so that a polished feature-complete release can be made (good timing as Gaffer 0.56.x is near as well as Blender 2.82 with a stable Cycles release). Cheers

kubo-von commented 4 years ago

Alright so actually after learning more about Gaffer (Why are the resources like the Gaffer blog so hard to find ? :D ) I found how to do this myself with simple python in startup script like so:

import Gaffer
import GafferCycles
import PyOpenColorIO

config = PyOpenColorIO.Config.CreateFromEnv()
for CS in config.getColorSpaces():
    n = CS.getName()
    if n.startswith("Input") or n.startswith("Output") or n.startswith("log") or n.startswith("canon") or n.startswith("crv"):
        continue
    Gaffer.Metadata.registerValue(
        GafferCycles.CyclesShader, "parameters.colorspace",
        "preset:"+n, n
    )

Screenshot from 2020-02-02 16-34-25

It'd be still handy to have a comboBox for this, I'll dig into it more.

boberfly commented 4 years ago

Whoa that's pretty cool! You should share that approach on the Gaffer forums so it benefits Arnold and other renderers which could use this.

kubo-von commented 4 years ago

Sadly it does not really work for Arnold, it seems they have just 2 hardcoded values there. Cycles support of OCIO is better :) I've send it to the forums anyway though, still might be useful.

willDTF commented 3 years ago

hi, thank you @kubo-von for the preset menu, helps a lot ! i have a little stugle to manage the colorspace with Cycles, how do you manage cycles' ODT ? i've tried with 'CustomOptions' node but without success for now thanks image

kubo-von commented 3 years ago

Hey @Kaiz3rTool What are you trying to achieve by adding the attribute? If you wanna render out in ACEScg, all you need to do is to feed cycles with textures in ACEScg and use ACEScg for the display when tweaking things, and as long as you are rendering into .exr your result has inherently that colorspace, just need to specify it when loading it in the next app. But I might be wrong!

willDTF commented 3 years ago

@kubo-von yes, i try to render in acesCG, I don't think that's the right way to do it as, with aces, we are able to choose different output that the incoming one. also, the image is not drived by the viewer as the viewer set the colorspace after rendering In arnold, for the same process, we have the ociocolormanager node to talk to the renderer, but we don't have the same thing for now in cycles so I guess i can send it as an option , but i don't found how to write it correctly for now