[Sidefx-houdini-list] Linear Workflow

Robert Kelly isstuff at gmail.com
Fri Aug 27 18:58:31 EDT 2010


Magnus you explained that clearly!


> 1. ALL shaders should have their input colors/textures converted to linear
> -> apply 1/2.2 to all textures and color parameters (including point
> colors). In houdini right now it could equal to add a multconstant node
> after a color parameter before its piped into something (like a mult etc).
>

this sounds like a texture input vop that has a sRGB  to linear
convert toggle like Peter Bomar described is a really good idea. Or
maybe you just have every image viewer / editor working in linear

On 27 August 2010 05:10, Magnus Pettersson <magnus at stormstudios.no> wrote:
> Just to summarize for some people who might still be confused by all this
> (most likely :P) what to actually do. This is "the ballpark" linear workflow
> without LUTs and so on. I assume all textures and colors is already sRGB
> (2.2) space (if stuff looks good on your monitor, it is most likely in sRGB
> and need conversion to linear):
>
> 1. ALL shaders should have their input colors/textures converted to linear
> -> apply 1/2.2 to all textures and color parameters (including point
> colors). In houdini right now it could equal to add a multconstant node
> after a color parameter before its piped into something (like a mult etc).
>
> 2. Ok now all your inputs should be correct, time to Render. Now to view
> this "in the ballpark sRGB" put the mPlay gamma to 2.2 and this should give
> you a good appreciation of how your render looks (if your monitor colors
> isnt totally wacky then you should go buy/borrow a monitor calibrator!). And
> this ofcourse means if you watch the picture in mPlay gamma 1.0 it will look
> dark (because of your monitors gamma correction making it darker).
>
> 3. When happy with the render looking at it with this mPlay gamma 2.2 you
> can send it off to comp. Like people said Nuke comp artists just take in all
> your renders with linear space and everyone should be happy :)
>
> The reason we have this very confusing gamma 2.2 here and 0.454545 there and
> some makes stuff darker (monitors) and other brighter (like mPlay gamma) etc
> is because of the EVIL old CRT screens had a negative gamma (technically
> limitation) and to correct for this every picture produced, every GUI
> produced and most likely every photo taken and every webpage have been
> having a 2.2 positive gamma applied (mostly in background without user
> knowledge) to correct for the CRTs shortcomings. BUT now a days with our new
> technology our LCD screens have no problem showing right colors in linear
> (which would be the best for us in this business so we wouldnt need to
> care).
> But if LCD screen manifacturers from the beginning would give you a screen
> in linear space as default noone would buy them because people would go "omg
> this new technology is crap, everything is ugly!" so they have applied this
> negative gamma curve to display the content of all programs and all internet
> "correct".
>
> Myself would like to see linear becoming the new standard, but that would
> require all digital content that is shown on a monitor to be chaged. So most
> webpages on the internet would have to change its colors, all pictures
> produced until now need to be converted to linear and so on, which you can
> understand is a massive undertaking. Not to mention all new content made
> needs to be made in linear (photos, programs gui, webpages etc)
>
> Because of a very small procentage of the people who owns a monitor or
> creates the GUI/webpages/images found in this digital age is actually aware
> of this linear space mumbo jumbo, so seeing a change in this in the
> near/distant future is very unlikely so we will have to continue our sRGB to
> linear (to sRGB) pipeline.. i blame CRT!
>
> Magnus Pettersson | Effects TD
> Storm Studios AS
> www.stormstudios.no
>
>
> On Thu, Aug 26, 2010 at 9:23 PM, Andy Nicholas <andy at andynicholas.com>wrote:
>
>> Thanks Edward, yep, I think this is the piece of the jigsaw I'm missing.
>>
>> I need to go away and do some research around all this, particularly the
>> perceptual bit. Once I set it straight in my head, I'll write a summary on
>> my website.
>>
>> Thanks again,
>>
>> A
>>
>>
>>
>> On 26 Aug 2010, at 19:39, Edward Lam <edward at sidefx.com> wrote:
>>
>> > On 8/26/2010 3:45 AM, Andy Nicholas wrote:
>> >>
>> >> What also didn't help my understanding was by putting Houdini's
>> >> colour correction gamma setting to 1/2.2 it made a pure linear ramp
>> >> (defined by a shader) in Houdini look correct in the render (i.e. an
>> >> even distribution of black through white), but using a value of 2.2
>> >> made it look anything but linear and over exposed the dark areas.
>> >
>> > You're missing the fact that the eye itself also has a nonlinear
>> > response. When you put in a 2.2 value into mplay, you're now undoing the
>> > power curve that the monitor applied, giving you linear _luminance_. Do
>> > not confuse this with _perceptual_ lightness.
>> >
>> > If you want *perceptual* (lightness) linearity, then you need to
>> > generate an approx. 0.4 power luminance curve [1], explaining why
>> > putting an mplay gamma value of around 0.4 "works".
>> >
>> > Lastly, this issue has nothing to do with Houdini in particular. Take a
>> > linear gradient in another package (say Photoshop) and you will see the
>> > same thing.
>> >
>> > Regards,
>> > -Edward
>> >
>> > 1. http://www.poynton.com/notes/colour_and_gamma/GammaFAQ.html#lightness
>> > _______________________________________________
>> > Sidefx-houdini-list mailing list
>> > Sidefx-houdini-list at sidefx.com
>> > https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>> _______________________________________________
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>
> _______________________________________________
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>



More information about the Sidefx-houdini-list mailing list