Jump to content


Photo

Fusion 7 Color Management Workflow


  • Please log in to reply
31 replies to this topic

#1 leif3d

leif3d

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 554 posts

Posted 27 October 2014 - 02:31 AM

So Fusion 7 has a great embedded color management workflow per-loader, but by default it doesn't really work properly...
Is there a way to make the loaders know that when they load an sRGB file to remove the gamma curve always? Or do we have to default the entire loader?
There should be default options for all color profiles or at least for color formats.
Also, the default LUT should be sRGB and active.

Nuke makes this so easy for the newcomer, people always have to do an extra step in Fusion for this, even now, with new color management...

#2 Kenzor

Kenzor

    Member Pig

  • Adv Members
  • PipPip
  • 23 posts

Posted 28 October 2014 - 06:53 AM

To set the default viewer LUT:

Setup the LUT how you want it ( I use the gamut view LUT to go from linear to sRGB)

Right click in the viewer window > choose setings > save defaults


also there are options in > preferences > view > display LUT plugins

#3 Kenzor

Kenzor

    Member Pig

  • Adv Members
  • PipPip
  • 23 posts

Posted 28 October 2014 - 07:00 AM

How would the loader 'know' that the image data is sRGB rather than log etc. Maybe some per project defaults could be used ?

#4 isotron

isotron

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 237 posts

Posted 28 October 2014 - 10:22 AM

i wrote this little tool script to switch (per hotkey) the sRGB Gamma Curve. So u dont need to go in the gamma Tabs , and save your time ;)



if (tool==nil) then
print("it's tool script. please select a Loader tool before run this script")
return
end

if tool:GetAttrs().TOOLS_RegID~="Loader" then
if tool:GetAttrs().TOOLS_RegID~="Saver" then
print("it's tool script. please select a Loader or Saver tool before run this script")
return
end
end

check = tool.Comments[1]
length = string.len(check)
if length == 4 then
tool.Gamut.GammaSpace = "none"
tool.Gamut.GammaAction = 0
tool.Comments = "srgb_removed"
return
end

tool.Gamut.GammaType = "Space"
tool.Gamut.GammaSpace = "sRGB"
tool.Gamut.GammaAction = 1
tool.Gamut.PreDividePostMultiply = 1
tool.Comments = "srgb"

print(tool.Comments)
print("Done")

#5 leif3d

leif3d

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 554 posts

Posted 28 October 2014 - 12:39 PM

To set the default viewer LUT:

Setup the LUT how you want it ( I use the gamut view LUT to go from linear to sRGB)

Right click in the viewer window > choose setings > save defaults


also there are options in > preferences > view > display LUT plugins


thanks for the help Kenzor. I do realize the LUT can be saved and defaulted, but it's so strange to me that out of the box color management is not implemented right, even when it has been reworked...

How would the loader 'know' that the image data is sRGB rather than log etc. Maybe some per project defaults could be used ?


Well, I don't think Fusion can "know" with the current implementation, but that's the striking part. It has a new color management workflow where that could have been implemented properly, but it doesn't...

Nuke has a preference for handling each color profile individually (based on the extensions), so all jpeg, png, tga, tiff files would be linearized, but exr, tiff float would be left alone. This is not very hard to implement, and it seems the color management went through a big overhaul based on previous feedback (which I really appreciate), but it's not implemented in the friendliest way and definitely makes no effort to allow customization in the preferences, which is also a shame.

#6 leif3d

leif3d

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 554 posts

Posted 28 October 2014 - 12:45 PM

i wrote this little tool script to switch (per hotkey) the sRGB Gamma Curve. So u dont need to go in the gamma Tabs , and save your time ;)



if (tool==nil) then
print("it's tool script. please select a Loader tool before run this script")
return
end

if tool:GetAttrs().TOOLS_RegID~="Loader" then
if tool:GetAttrs().TOOLS_RegID~="Saver" then
print("it's tool script. please select a Loader or Saver tool before run this script")
return
end
end

check = tool.Comments[1]
length = string.len(check)
if length == 4 then
tool.Gamut.GammaSpace = "none"
tool.Gamut.GammaAction = 0
tool.Comments = "srgb_removed"
return
end

tool.Gamut.GammaType = "Space"
tool.Gamut.GammaSpace = "sRGB"
tool.Gamut.GammaAction = 1
tool.Gamut.PreDividePostMultiply = 1
tool.Comments = "srgb"

print(tool.Comments)
print("Done")


Thanks isotron, a script definitely helps. I think my complaint is less from a time concern and more from a customization and workflow standpoint. Eyeon re-worked the color management, go it right, but defaulted everything wrong and made customization by color profiles not possible...I can't imagine why they would do that.
i was hoping I was missing a simple preference or workflow somewhere, but apparently there are no global options to deal with certain color profiles or at least extensions.

#7 isotron

isotron

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 237 posts

Posted 29 October 2014 - 05:13 AM

np, that nuke guess the color profile based on the extension, is okay, in the most situations, but nuke even cant know if i render out an jpg with "non-srgb" .
I thought the open color IO could help, but i think , there is a need of meta data, read and write) in all fileformates, even in jpgs. So that such of this Informations could be stored in.

#8 leif3d

leif3d

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 554 posts

Posted 29 October 2014 - 10:19 AM

np, that nuke guess the color profile based on the extension, is okay, in the most situations, but nuke even cant know if i render out an jpg with "non-srgb" .
I thought the open color IO could help, but i think , there is a need of meta data, read and write) in all fileformates, even in jpgs. So that such of this Informations could be stored in.


"Most situations" is usually helpful enough to make something default. Besides, I've never seen a jpeg without an sRGB profile, sure you can change it to anything you want, but you or the texturing department could control that. When you pass the image through the pipeline to fusion you would expect the gamma handling to happen automatically, or else confusion can happen in a collaborative environment where someone doesn't color manage their shots properly, because there is no way to standardize fusion to an approved color management workflow.
I just can't believe they would get something so basic wrong. It's pretty silly...
Oh well, at least it's some kind of improvement.

#9 Kenzor

Kenzor

    Member Pig

  • Adv Members
  • PipPip
  • 23 posts

Posted 29 October 2014 - 12:16 PM

I feel like your making a lot of assumptions on the way things 'should' be.

Not everyone uses a linear workflow.

Partial automation would cause other issues and be confusing ( as it is in after effects )

And for 3d texturing jpgs are linear when used for bump maps ad other technical passes

The only way to be sure is with custom scripted loaders linked to a data base for the project. This hides the colour setups from your artists, and deals with naming conventions etc.

All artists in should be taught correct colour management anyway

So personally I don't think its silly.

#10 leif3d

leif3d

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 554 posts

Posted 29 October 2014 - 05:02 PM

I feel like your making a lot of assumptions on the way things 'should' be.

Not everyone uses a linear workflow.

Partial automation would cause other issues and be confusing ( as it is in after effects )

And for 3d texturing jpgs are linear when used for bump maps ad other technical passes

The only way to be sure is with custom scripted loaders linked to a data base for the project. This hides the colour setups from your artists, and deals with naming conventions etc.

All artists in should be taught correct colour management anyway

So personally I don't think its silly.


I appreciate your input kenzor, but my point of view is not so much an opinion of workflow, which you're right, can be completely subjective. I'm talking about math. Math is objective, whether someone agrees with it or not.
I don't think I'm making assumptions, working with linear data is just the correct way of working with data, because it's the only predictable way of working with data. People can work incorrectly and make great art, but that's a choice. Besides, this wouldn't be an issue if it was done correctly, like Nuke, or Maya (now in 2015 ext 1), people would just benefit from something which has been implemented correctly without noticing.
Many tools in Fusion work terribly if you're not in a linear workflow, such as the film grain tool (even grain without exposure compensation), DOF (no bokeh from over exposed pixels, people have to compensate with fake highlight blooms), 3D light exposure and falloff looks terrible as does the rest of the 3d rendering, alpha on a regular over merge looks muddy, etc... I could go on for a while...
Automation can be done right and leave room for change in the preferences if you want to work another way.
Automation in After effects is destructive, but it tries its best since it's not a true 32-bit floating point film compositor, it's a motion graphics tool that can serve as a compositor. It's also carrying legacy code for over a decade now, so much of the effects don't even work in floating point.
Linearization for Fusion's 3d renderer could happen in the renderer, like any other application. Fusion would know not to color transform its bump map, specular map, etc...It would be extra work, but it could be done.
You're right about automating with scripts, it's a great idea, I was just proposing defaulting to the correct way math needs to work to achieve predictable results.
You're also right about people needing to learn color management, that's why I teach it here and as you can see I'm pretty passionate about it :)
Also, take my comment of "silly" as just a silly comment. :)

You're probably familiar with this document, but if you're not, A great read is Steve Wrights color management explanation.

#11 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 29 October 2014 - 10:27 PM

Slow down, I'm not following. Are you suggesting that all tools in Fusion, and all images in Fusion be linear? If so, then why would bump maps, etc. need special treatment? What's the benefit of having a mixed up workflow relying on metadata? I mean, it COULD make sense in Fusion since Fusion natively supports 8 bit images whereas Nuke does not, but that complication gets you What?

- Chad


#12 Kenzor

Kenzor

    Member Pig

  • Adv Members
  • PipPip
  • 23 posts

Posted 30 October 2014 - 06:02 AM

Leif3d dude your showreel is pretty awesome so I can see you know what your doing .

I agree with the maths, and personally I'll always work in a linear colour space .

I helped design the colour pipeline lexhag and there's a bunch articles on our fusion workflow on my site http://www.designima...ows-simplified/

I have my own fusion frustrations and while I agree that as compositors we 'should' be working in linear Colour ... My particular beef is that pivot points of the fusion colour tools are designed for a 2.2 gamma colour space. It makes them a pain to use and I really feel this 'should' have been fixed in fusion 7 ( a tick box 'is input linear ' would do )

So to summarise ...

The issue is that if one is working in linear colour then all images should be linearised when they are loaded . Repetitive processes suck time so we want to automate them where possible . Plus in collaborative environments we need to make sure everyone works to the same standards

In general the first operation for an 8bit image like a jpg would be to linearise it and promote it to floating point .

But normal maps , bump maps , alpha masks etc are linear already ( Ie don't have the video gamma backed in ) and are often stored as 8bit images. Here the linearisation process will mess with the values and cause fringes with alpha maps and unsightly seams with normal maps

Should this process be automated ? Well i guess to some extent that relies on people like us working through the special cases until we can come up with a consistent set of rules that can be coded.

I have some links to the Sony pictures workflow but it's a bit of struggle to do the forum post from my phone ...

I really respect your feedback guys . I look forward to further comments . :)




#13 Kenzor

Kenzor

    Member Pig

  • Adv Members
  • PipPip
  • 23 posts

Posted 30 October 2014 - 09:38 AM

Here's a link to the Sony image document http://opencolorio.o...i_pipeline.html

What I find interesting about this is that even with all there resources they still rely on a simple naming convention to pass colour information around.

#14 leif3d

leif3d

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 554 posts

Posted 30 October 2014 - 03:16 PM

Slow down, I'm not following. Are you suggesting that all tools in Fusion, and all images in Fusion be linear? If so, then why would bump maps, etc. need special treatment? What's the benefit of having a mixed up workflow relying on metadata? I mean, it COULD make sense in Fusion since Fusion natively supports 8 bit images whereas Nuke does not, but that complication gets you What?

- Chad

Bump maps or other "driver" images like normal maps or masks (meaning images that drive attributes but don't participate in the color process directly) would need special treatment because you would be loading an 8 bit image and Fusion would think it needs to be linearized when it doesn't need to be... I know, it's a bit complicated, but it can be done right.
The benefit of this complication is correct and predictable color, lighting and tool math in fusion.

Leif3d dude your showreel is pretty awesome so I can see you know what your doing .

I agree with the maths, and personally I'll always work in a linear colour space .

I helped design the colour pipeline lexhag and there's a bunch articles on our fusion workflow on my site http://www.designima...ows-simplified/

I have my own fusion frustrations and while I agree that as compositors we 'should' be working in linear Colour ... My particular beef is that pivot points of the fusion colour tools are designed for a 2.2 gamma colour space. It makes them a pain to use and I really feel this 'should' have been fixed in fusion 7 ( a tick box 'is input linear ' would do )

So to summarise ...

The issue is that if one is working in linear colour then all images should be linearised when they are loaded . Repetitive processes suck time so we want to automate them where possible . Plus in collaborative environments we need to make sure everyone works to the same standards

In general the first operation for an 8bit image like a jpg would be to linearise it and promote it to floating point .

But normal maps , bump maps , alpha masks etc are linear already ( Ie don't have the video gamma backed in ) and are often stored as 8bit images. Here the linearisation process will mess with the values and cause fringes with alpha maps and unsightly seams with normal maps

Should this process be automated ? Well i guess to some extent that relies on people like us working through the special cases until we can come up with a consistent set of rules that can be coded.

I have some links to the Sony pictures workflow but it's a bit of struggle to do the forum post from my phone ...

I really respect your feedback guys . I look forward to further comments . :)

Thanks for the nice comments Kenzor.
You're right, it's pretty convoluted. Fusion would have to go the extra mile to get this done.
Maya now compensates the entire viewport (tools included) to participate in a correct color managed workflow. It applies a LUT to the viewport and compensates all its inputs (when they meet certain requirements like color, but not bumps or specular) in order to display and render in linear space. This way light and color get processed physically correct with nice light falloff and termination. Diffuse intensities and transparencies are far more accurate, not to mention subsurface scattering, GI and other subtle effects.
Maya got it wrong (very much like Fusion IMO) years ago on their first try and now, they had to hire a specialized guy to get it right after a lot of complaining from the user base. RenderMan went through similar UI limitations for linear workflows, but after a lot of feedback they've gotten it right.

Here's a link to the Sony image document http://opencolorio.o...i_pipeline.html

What I find interesting about this is that even with all there resources they still rely on a simple naming convention to pass colour information around.


Sometimes the solutions can be done very early on the pipeline, so it makes some sense I guess to organize extensions.
I can always keep compositing manually linear, but I was hoping for a better solution. I'll see if with some scripting I can automate the whole process to my liking, but I don't know LUA...

#15 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 30 October 2014 - 05:18 PM

I'm going to disagree 100%. :)

With the exception of files that have colorspace metadata, No conversion should happen automatically. Why? Well, the compositor will KNOW intuitively if a color plate is in the wrong color space MUCH more often than they would a bump map or glossiness map or velocity map.

So the default should be to leave the image alone, but provide an easy way (as F7 does) to set the gamut conversion.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users