PDA

View Full Version : Linear Workflow and Gamma Explanation



Creativetone
01-13-2012, 12:24 PM
Very well organised and a clear tutorial about the subject.

Linear workflow and Gamma explanation. (http://www.seazo.no/linear-workflow)

Matt
01-13-2012, 01:40 PM
Looks like it was inspired by mine!

Part 1:
http://www.youtube.com/watch?v=wEbH62a1YqA

Part 2:
http://www.youtube.com/watch?v=9jM44iCCkEw

Download Version:
http://www.pixsim.co.uk/video_tutorials/The_Beginners_Explanation_of_Gamma_Correction_and_ Linear_Workflow.zip

Slides: (This is an updated version with corrected diagrams and more information - not ever been released until now)
http://www.pixsim.co.uk/downloads/Linear_Workflow_in_LightWave.zip

speismonqui
01-13-2012, 04:04 PM
both look great, thanks.

BUT, I would love to see a "merge" of these two AND Lightwave related. Matt, you're explanation and diagrams are great, even Jarrod's video is great but how to apply these in lightwave? Can you guys share your CS settings? Do you change them according to the project? Maybe I'm missing something or I'm not smart at all but somehow I still don't know how to get the most out of it in LW.

eagleeyed
01-13-2012, 05:50 PM
Linear Workflow is a lot easier depending on what version of LightWave you are using?

Version 9 or Version 10 or 11 with Colour Space built in?

If you have 10.1 or 11 just open Layout, press d, then click on the CS tab and select the sRGB Preset. :)

This thread has a lot more discussion on the topic (skip to the last few pages for version 10 talk :)) http://forums.newtek.com/showthread.php?t=102397

evolross
01-13-2012, 06:01 PM
Linear workflow and Gamma explanation. (http://www.seazo.no/linear-workflow)
Good link. Very thorough. Matt your stuff always helps too. :thumbsup:

geo_n
01-13-2012, 10:12 PM
Is there a better fix for lwf and bad AA in lw 10.1 that doesn't involve higher render time, or burning in the gamma?
http://forums.newtek.com/showpost.php?p=1211419&postcount=490
Left render lwf lw 10.1 bad AA. Right render lwf lw 10.1 dbw pixel hack good AA. Camera settings are the same. I could up the AA on the left to get same quality in right but increases render time a lot. I don't use lwf in lw 10.1 for animation because render time is high to get good AA.

Matt
01-13-2012, 10:20 PM
Is there a better fix for lwf and bad AA in lw 10.1

LightWave 11 fixes anti-aliasing not being considered by LWF.

geo_n
01-13-2012, 10:26 PM
LightWave 11 fixes anti-aliasing not being considered by LWF.

Yes, but none for lw 10.1? Its one of the main features of lw 10.1.

Creativetone
01-13-2012, 11:02 PM
Thanks, Matt!
Your updated slides looks good and clear. :thumbsup:


Slides: (This is an updated version with corrected diagrams and more information - not ever been released until now)
http://www.pixsim.co.uk/downloads/Linear_Workflow_in_LightWave.zip

Matt
01-14-2012, 02:48 AM
Yes, but none for lw 10.1? Its one of the main features of lw 10.1.

Yes, I know, but I'm afraid not.

biliousfrog
01-14-2012, 03:23 AM
If you have 10.1 or 11 just open Layout, press d, then click on the CS tab and select the sRGB Preset. :)



sRGB?...Wouldn't you leave everything set to Linear to remain in linear colour space?

geo_n
01-14-2012, 04:10 AM
Yes, I know, but I'm afraid not.

That's too bad. That essentially makes lw 10.1 lwf less useful if you have to bump AA settings to get good AA, render times 3x or 4x in a scene. I haven't tried unified sampling in lw 11 much. Hopefully its fixed but I guess the lw 10.1 people are out of luck.


sRGB?...Wouldn't you leave everything set to Linear to remain in linear colour space?

Setting it to linear or default makes it same with lw 9.6 engine with no gamma correction. As the excellent video explains, its taking out that gamma 2.2 input from textures, lights, color picker,etc so that they are linearized and then can be used correctly by lightwave which is linear. An analogy is putting 220v on 110v. They don't exactly match so you make the 220v appliance 110v. In lw that's by setting srgb as colorspace. But I don't see how colorspace can be useful in lw if render times are huge. Only for stills maybe.

biliousfrog
01-14-2012, 06:10 AM
Setting it to linear or default makes it same with lw 9.6 engine with no gamma correction. As the excellent video explains, its taking out that gamma 2.2 input from textures, lights, color picker,etc so that they are linearized and then can be used correctly by lightwave which is linear. An analogy is putting 220v on 110v. They don't exactly match so you make the 220v appliance 110v. In lw that's by setting srgb as colorspace. But I don't see how colorspace can be useful in lw if render times are huge. Only for stills maybe.

Changing the output colourspace shouldn't have any effect on render times as Lightwave renders in linear colourspace anyway, that's why you needed to adjust the input colours and images to get a decent looking render.

I'm confused because, after reading through the docs, it seems to suggest that the default setting of everything set to linear is the correct setup for working with LCS. Of course, if the web help system actually worked, I'd try to find that section again and re-read it.

geo_n
01-14-2012, 06:31 AM
Changing the output colourspace shouldn't have any effect on render times as Lightwave renders in linear colourspace anyway, that's why you needed to adjust the input colours and images to get a decent looking render.

I'm confused because, after reading through the docs, it seems to suggest that the default setting of everything set to linear is the correct setup for working with LCS. Of course, if the web help system actually worked, I'd try to find that section again and re-read it.

Changing the input colorspace, which is when you set picked colors, light color, palette, 8 bit files, to srgb will affect the render especially the AA that I posted in the link. The edges are jagged and only way to clean it up is higher AA and AS. I just read somewhere that the renderengine doesn't take into account the colorspace when doing AA. This makes lwf in lw 10.1 less useful. Its getting fixed in lw 11 with the unified sampling I guess, but
I don't have this issue in vray and kray when working with lwf.
Also I don't change the output colorspace at all. I set it to default(linear) and save to exr which is only useful if its in linear space with no baked gamma.
I think there's some misunderstanding of why you don't set all lw 10.1 to srgb. The output should never be set to srgb unless you want the gamma to be baked in. "Display color space" set to srgb is ok just to check how it looks with gamma correction.


edit: the hack is to use db colorcorrector pixel filter with lwf in lw 10.1 to get good AA and gain speed back but that burns in the gamma and all output is useless for post process.

I'm just really surprised this major issue is existing for a major feature. Its just lately that I use lwf in lw 10.1 since we use lw 9.6 still for most projects. But I use lwf in vray,kray for a long time. Maybe not many people have used lwf in lw 10.1 since it came out July and not yet noticed the bad AA when using lwf. Why this will not be fixed for lw 10.1 I don't know. The rendertimes with lwf are just too high on more complex scenes.

biliousfrog
01-14-2012, 06:46 AM
So what we're saying is that the LW documentation and default CS setup is wrong.

biliousfrog
01-14-2012, 06:50 AM
BTW, I have just been testing some renders and the AA is terrible. I really hope LW11 has fixed this or I'll be going back to 9.6 because I can't swallow the extra render times.

geo_n
01-14-2012, 06:55 AM
So what we're saying is that the LW documentation and default CS setup is wrong.

How is it wrong? Sorry I didn't read the docs for lw. There's ton's for vray I read and I learned from vray people that to work in linear space most everything has to be degamma'd even color pickers.
Its the same way in lw 10.1 you degamma all Input by setting it to srgb.
Output srgb is separating thing and only concerns the final image not how the renderengine translates or getting fed the linear inputs.

geo_n
01-14-2012, 06:58 AM
BTW, I have just been testing some renders and the AA is terrible. I really hope LW11 has fixed this or I'll be going back to 9.6 because I can't swallow the extra render times.

Yes its terrible. Like my previous post I can't believe this major feature for lw 10.1 has a big drawback that won't be fixed. Released last July only its barely a year.

biliousfrog
01-14-2012, 07:13 AM
I can't browse or search my docs because the directory structure seems to be broken so I can't find the exact quote without manually opening every html page and scanning the text but I'm fairly sure that it says that the default settings are what most people would use (everything at linear) when working in lcs. Which is why I left mine set to the default settings.

Perhaps I totally mis-read it but I'm 99% certain that it was recommended to stick with the default settings.

geo_n
01-14-2012, 07:27 AM
Then the docs assume that most users will use the burned in gamma image as final. But there are users who want correct linear image as final. Its just wrong assumption but not completely wrong. But with the AA issue who use it? Someone who doesnt care about render time maybe.

bobakabob
01-28-2012, 06:46 PM
So to confirm, if good render times are a priority in LW 10.1, leave the CS at the default settings of "Linear" (not sRGB)?

Having just installed 10.1, and reading this thread, I'm still trying to get my head round CS options. Switching to sRGB leaves everything looking pale and washed out. Is the advantage greater flexibility in setting brightness / contrast post production?

geo_n
01-28-2012, 08:28 PM
If you leave CS at default then its better to go back to lw 9.6 and render there.
If you will do Linearworkflow by turning on srgb then all materials and lights will have to be changed. Color values, gradients, lights will have to be toned down with srgb on. You'll also use less lights because working in lwf has a better distributed falloff and scenes are brighter. You'll have less overbright and dark splotchy areas with linearworkflow.

evolross
01-28-2012, 08:32 PM
So to confirm, if good render times are a priority in LW 10.1, leave the CS at the default settings of "Linear" (not sRGB)?
If render time is priority, perhaps. I've been doing a ton of production shots in LW 10.1 and I haven't personally noticed any increased render times needed to get good AA. And this is compared to my years of work in the 9.X series. Whatever the issue is, I am glad it's getting fixed in LW 11 though it would be nice to get an update to LW 10.1. Perhaps try your scene both ways and see which takes longer to get the quality you need, though you may have to adjust your light settings to get them to look similar.


Switching to sRGB leaves everything looking pale and washed out. Is the advantage greater flexibility in setting brightness / contrast post production?
No not really. Having more flexibility for grading in post is a result of saving your renders in a higher bit-depth file format (i.e. more color data in the actual image file). So instead of rending to an 8-bit JPG or TIFF, render to a 16-bit TIFF, or even better a 32-bit EXR. Though if you're saving in EXR and using a LWF (linear workflow) you should set your output to "Linear" as the EXR format assumes a linear-gamma image.

Using a LWF basically sets all your image textures, lights, backgrounds, and fog to linear-gamma which is correct for LW's linear render engine. So the benefit is more realistic/natural shadows, spec hits, reflections, color blending between edges of objects in your scene (especially if you're rending with motion blur or DOF). Basically your image will look more natural. There's actually a lot of benefits, but most people only usually mention the shadow levels. If your image is looking washed out when you set the CS to "sRGB" then you need to adjust your light and radiosity levels and "dial" it back into something that looks natural. If you have an image looking good using LWF settings, then when you turn them off (i.e. switching the CS tab back to "Linear"), it will and should look unusually dark. This is because you're looking at a raw, linear, gamma 1.0 image which is way too dark on normal monitors, but this is all correct.

I personally use LWF for everything and I render my output in linear to EXR. Then I bring that into Nuke, which like LW is also native linear, and work with Nuke's sRGB LUT (lookup table) settings. The entire comp is done in linear. Then I can output to linear, cineon, or sRGB depending on where my render is headed (e.g. to a DI color suite, to a Quicktime for a director to watch, etc.)

You don't have to use LWF and people haven't for years and continue to do so. When you don't, you just have to fight with light settings a little more to get things to appear more natural (shadows, texture brightness, everything I mentioned above). You can still render to a 32-bit TIFF or EXR, you just have to remember that you've "burned in" the image at sRGB and you'll need to "back off" the sRGB by using an inverse LUT in a linear comp environment like Nuke (which is easy to do as it's designed to do this as well).

Yeah the preset dropdown is a little confusing on the CS tab in LW. Whenever I explain it to new people I always say that the dropdown refers to what you're "viewing" in. You're always "working" in linear in LW no matter what because it's a linear renderer. But if you set the dropdown to "sRGB" that means you're viewing in sRGB (i.e. LW is correcting it to sRGB). If you set the dropdown to "Linear" then LW is doing nothing to it and it's WYSIWYG (what you see is what you get) which is technically linear, but not utilizing a LWF, which is the way LW has always been pre-10 (unles you were using DP's nodes to do a LWF - like I did :)).

One helpful note, your lights should always have their falloff set to inverse-squared if you're using LWF as this is how lights naturally behave. If you want the "natural" look, then make sure this is set if you're using falloff (which you should if you're going for realism).

I hope this helps. Feel free to ask any further questions. It took me a while to "get it" but now that I understand I'll always use it.

Danner
01-28-2012, 11:05 PM
You will have troublesome AA using LCS in LW 10.x on reflective surfaces. There are ways around this, sometimes I just use reflection bluring and leave the antialias at a normal setting. My render times at 1280 x 720 are never over 10 min per frame. Most are around 5 min and some dip as low as 58 seconds per frame, like the one I'm rendering now (see attatched).

geo_n
01-29-2012, 01:13 AM
Matt already said newtek is aware of the problem in lw 10.1 lwf. Its not lwf aware 100%. The simplest scene with srgb on already exibits the bad AA in renders.
I would just skip lw 10.1 for lwf and wait for fix in lw 11.

Mr Rid
01-29-2012, 01:43 AM
Am I the only one that thinks the way the CS presets apply is backward? The intuitive thing is to select "linear" to apply a linear process. But instead you apply 'sRGB' to process in 'linear', and apply 'linear' to process in 'sRGB.' Its like disabling a light to enable it. Doesnt this confuse everyone at first?

biliousfrog
01-29-2012, 01:49 AM
Am I the only one that thinks the way the CS presets apply is backward? The intuitive thing is to select "linear" to apply a linear process. But instead you apply 'sRGB' to process in 'linear', and apply 'linear' to process in 'sRGB.' Its like disabling a light to enable it. Doesnt this confuse everyone at first?

Nope, you're not alone, it's typical Lightwave logic. It makes perfect sense to the NT staff and no sense from a logical perspective therefore, the users are the idiots and should just get used to it. This thread, and others like it, are proof that the presets don't make sense.

geo_n
01-29-2012, 02:28 AM
I don't newtek is to blame. Its the same way in vray and kray. You apply correct gamma to your input before feeding it to your 3D app which works in linear space. Maybe the whole industry should just term the process "degamma your inputs". Doesn't sound sexy as linearworkflow. Making stuff sound cool is the industry way. "Production", etc. Even a one man artist uses "production" for his work. Lol.

stiff paper
01-29-2012, 02:44 AM
Am I the only one that thinks the way the CS presets apply is backward? The intuitive thing is to select "linear" to apply a linear process. But instead you apply 'sRGB' to process in 'linear', and apply 'linear' to process in 'sRGB.' Its like disabling a light to enable it. Doesnt this confuse everyone at first?

Yes, it doesn't make any sense. I find it much easier to understand (not to mention much easier to make work) in 9.6 where you have to hotwire it all yourself... and that's completely absurd given that the entire point of having it built in is supposed to be to make it easier.

I've kind of given up on expecting anything other than slightly inept workflow in any new features now.

My take on it (and on some other LW issues too) is that LW devl collectively allows programmers to decide how the workflow should be, and in my experience it's fewer than 1 in every 1000 programmers who can do that and not get it all ridiculously arse-backwards. I've worked with some truly great programmers, but not one of them should ever be allowed to design workflow, and they're fully aware of that (they're not happy about it, and they think everybody else is wrong, but they do know).

biliousfrog
01-29-2012, 08:19 AM
...My take on it (and on some other LW issues too) is that LW devl collectively allows programmers to decide how the workflow should be...

That sums it all up perfectly. Not only does it make the process of learning an application difficult but it also means that, in order to progress, you need to start thinking like a programmer to use aspects of the application....and that's not productive when the application is designed for creatives.

bazsa73
01-29-2012, 09:32 AM
Am I the only one that thinks the way the CS presets apply is backward? The intuitive thing is to select "linear" to apply a linear process. But instead you apply 'sRGB' to process in 'linear', and apply 'linear' to process in 'sRGB.' Its like disabling a light to enable it. Doesnt this confuse everyone at first?

Couldn't agree more. Matt told me once I do it wrong if I choose linear from the presets when my intention is to work in the linear workflow. It is misleading and confusing.

Lightwolf
01-29-2012, 02:12 PM
Couldn't agree more. Matt told me once I do it wrong if I choose linear from the presets when my intention is to work in the linear workflow. It is misleading and confusing.
I suppose the main problem is that many people think that the linear workflow is new.
And it's not - it has actually been the only thing that LW ever did up to 10.0.

In that sense, what has been added was a colour management "workflow". Ah, screw that, just colour management.

Cheers,
Mike

Cageman
01-29-2012, 02:35 PM
Am I the only one that thinks the way the CS presets apply is backward? The intuitive thing is to select "linear" to apply a linear process. But instead you apply 'sRGB' to process in 'linear', and apply 'linear' to process in 'sRGB.' Its like disabling a light to enable it. Doesnt this confuse everyone at first?

Yes... at first, before I noticed what the CS-tab has at the very top of it:

"Convert Color Space to Linear" and below that are setting for colorpickers, lights, textures etc.

:)

Cageman
01-29-2012, 02:39 PM
That sums it all up perfectly. Not only does it make the process of learning an application difficult but it also means that, in order to progress, you need to start thinking like a programmer to use aspects of the application....and that's not productive when the application is designed for creatives.

I think the implementation is quite logical, to be honest... and I'm not sure how people to this date havn't figured it out yet... I'd say that it is more related to an issue of communication from NT rather than a bad workflow desicion, because when you understand it (and my god... it isn't hard at all), you'd wonder why you even had these gripes in the first place.

:)

XswampyX
01-29-2012, 03:10 PM
I think the implementation is quite logical, to be honest... and I'm not sure how people to this date havn't figured it out yet... I'd say that it is more related to an issue of communication from NT rather than a bad workflow desicion, because when you understand it (and my god... it isn't hard at all), you'd wonder why you even had these gripes in the first place.

:)

+1

I have to agree, at first I didn't get it. It seemed to me to be just extra complications where none existed beforehand. Then I watched a few videos and read a few articles, Bham! It makes perfect sense. Change all your input colours/images to Linear, render, output to linear and then tonemap it to get it back to what your average monitor can display.

Good job Newtek! :thumbsup:

Cageman
01-29-2012, 03:32 PM
+1

I have to agree, at first I didn't get it. It seemed to me to be just extra complications where none existed beforehand. Then I watched a few videos and read a few articles, Bham! It makes perfect sense. Change all your input colours/images to Linear, render, output to linear and then tonemap it to get it back to what your average monitor can display.

Good job Newtek! :thumbsup:

Uhm... no...

When doing what you just wrote, you are doing it the way LW9.x does colormanagement which is... it doesn't do any colormanagement. :D

Again, you have to tell LW to convert from x colourspace to Linear (as it says in the CS-tab). Most of your texturework is usually in sRGB space, so, your textures should be set to sRGB in order for LW to correctly convert it into linear colorspace to feed the engine correct data. This goes with pretty much all things you are doing...

A correct setup should look like (see attachment). Most, if not all, monitors display graphics in sRGB space, but LWs renderengine operates in Linear space.

When it comes to textures, there are some things to think about; Displacementmaps and Normalmaps should be loaded as linear, and you have to manually do a per texture override for those if they are stored in a non-floating point format.

Mr Rid
01-29-2012, 03:37 PM
I think the implementation is quite logical,...

:)

Its not at all to the majority. I've wasted so much time with this mess at work and trying to explain it to each person new to it.

The backward preset logic is not a huge deal (although I dont see how anyone could think this is the best way to set it up), its just more of the left vs right brain way of thinking I often see as a fundamental problem with interface befuddling the majority of less tech-minded users, beginning with the terminology. A programmer's aptitude requires a practice of operating and defining within mathematical rules that is a very different way of problem solving from the pursuit of creative goals where success results more from freeform experimentation and following unconscious impulse. The computeryness of the tools I am forced to deal with constantly frustrates the hell out of me, when so often I can see a simpler way of setting it up to get from A to B.
101300

LCS presets are indeed that simpler 'button' I was always insisting on to greatly simplify the ridiculously complicated linear gamma mess. But the left brain weirdness just has to linger by applying 'red' to make it 'blue' so the same confusion has to keep getting posted and answered.

I still havent seen an ideal explanation of the whole color space thing for those first approaching it. Each explanation has some good examples but then other points are vague, confused or missing. Usually, in the before and after render comparison I actually prefer the look of the before image.

left brain
101298

right brain
101299

XswampyX
01-29-2012, 03:43 PM
Sorry Cageman, my bad.

I meant convert them from sRGB to linear, before rendering. :foreheads

I often use a hdr as an environment, and the settings you referred to double convert them. So I use the DBW Color space node to convert all my textures.

http://www.db-w.com/products/dbwtools/docs?start=1

I can see how people get confused!

Cageman
01-29-2012, 03:50 PM
Well... since we work with Nuke as our main compisiting application, I've noticed that with the settings I showed in my attachement, an F9 render in LW compared to a rendered frame on the farm brought into nuke looks _exactly_ the same, since Nuke is designed to work with linerized data, and as such it adds 2.2 gamma to the images for display purposes.

This was not true when using LW9.x for rendering, where we had to either remove gamma in Nuke, or go for a very tedious workflow within LW to linearize the content.

LW10.x and LW11 is so much better for us in this regard, because we know that what we see in LW is what Nuke will display as well. And ontop of that, we have much more information in the dark areas of a render, way more realistic falloff for lights (especially lights that are close to a wall).

Easier and much more nice. I really can't complain about it... and... while I do understand that the "logic" might be hard to understand for some, once you do understand it, it isn't hard, and it is not a convoluted workflow as such. So, again, I'm not sure it is the logic that is the problem, it is the fact that the communication for it hasn't been the best. Because, really, it isn't hard at all.

Cageman
01-29-2012, 03:55 PM
Sorry Cageman, my bad.

I meant convert them from sRGB to linear, before rendering. :foreheads

I often use a hdr as an environment, and the settings you referred to double convert them. So I use the DBW Color space node to convert all my textures.

http://www.db-w.com/products/dbwtools/docs?start=1

I can see how people get confused!

About HDR:s.

Most of our floatfiles that we use are in fact linearized, but many HDR-files you find on the internet or even purchase have, for some reason, 2.2 gamma encoded into them. We use maybe 1 or 2 such files, all the other floatfiles we use are our own and we make sure they are created correctly. :)

In such cases, I usually go into the texture editor and change those odd HDRs with 2.2 gamma to sRGB, instead of doing the reverse... changing a lot of floatfiles to Linear.

:)

It all depends on your source of course... if the majority of the stuff you use are "crippled" with 2.2 gamma encoded, I fully understand your approach to setting floatfiles to sRGB.

:)

Mr Rid
01-29-2012, 04:02 PM
LW10.x and LW11 is so much better

Absolutely.

stiff paper
01-29-2012, 04:09 PM
I suppose the main problem is that many people think that the linear workflow is new. And it's not - it has actually been the only thing that LW ever did up to 10.0.
In that sense, what has been added was a colour management "workflow". Ah, screw that, just colour management.

Ye-ee-e-esss...

Now, I'm not arguing with you here, because your point is valid (and I don't disagree), but it set me thinking about why it doesn't apply, in my case, at least...

I use LWF in 9.6 all the time. It makes perfect sense. When I first encountered Linear WorkFlow in LW I read the "explanation" of it and thought "Er... what?" but then I read something somewhere else that said something useful like "All your textures and color values have a curve on them that you don't normally know anything about. It's so they display nicely on TVs, which have a funky curve on their displays. You can remove the curve from all your images and from all your color settings on everything, then do a render like that, then afterwards you can put the curve back on your finished render and it will look a lot better."

And that was all I needed. Got it instantly. Doing a LWF in LW9.6 makes absolute logical sense. In LW10? No. I find it ridiculous and wrong-headed and backwards.

So I already knew about LWF and was using it completely fine, and I understand exactly what's happening, why it's happening, and why the renders look better using LWF. And, for me, LW10's approach definitely makes a lot less sense.

So, with the stated goal of making LWF easy to use and accessible to everybody, they actually managed to make it less easy to use and a lot less intuitive than it was when it didn't even officially exist. That's some going.

stiff paper
01-29-2012, 04:28 PM
or go for a very tedious workflow within LW to linearize the content.
Really? Well, I use Nuke. And I never render anything these days in 9.6 that isn't LWF. I'd say it takes me only seconds, usually, to set up LWF in 9.6. I've never even noticed the time it takes, which for me seems a long way from tedious. Try selecting 800 items in Layout. That's tedious.


while I do understand that the "logic" might be hard to understand for some, once you do understand it, it isn't hard, and it is not a convoluted workflow as such.
But we, collectively, seem to keep using "It's completely insane but once you adapt you can use it" as an excuse as to why Newtek can carry on making things be non-intuitive and clumsy, and I honestly think it's not a helpful thing to keep doing. Surely it would be much better all 'round for everybody if everybody pointed at the things that don't make sense and shouted about them. That way, if those things are then altered so they do make sense and are intuitive, we might be able to pull in some new users who otherwise would be off to intuitive and nicely explained "other-3D-land".

Cageman
01-29-2012, 04:35 PM
So, with the stated goal of making LWF easy to use and accessible to everybody, they actually managed to make it less easy to use and a lot less intuitive than it was when it didn't even officially exist. That's some going.

I would never want to go back to the tediousness that is pre LW10 regarding this. Never...

I still try to grasp what the heck is so hard to understand regarding LCW in LW10.x... It kind of blows my mind that people aren't understanding it.

Oh well... is there anything I can do in order to make you understand this? A video mayhaps?

jasonwestmas
01-29-2012, 04:35 PM
The was a time when I thought tweaking the heck out of my hdr image could solve any issue of darks that were too dark and colors that get washed out. I mean, you can do it that way but the sRGB gamma with color space previews get things done a lot faster imo. That's why they're there obviously.

I guess I don't worry about backwards thinking verses forwards thinking as I have to deal with it in several different programs. Unity nodes are opposite of lightwave and softimage nodes, they go right to left verses left to right. UV master in Zbrush makes you create UVs at the highest sub-d level verses PUV and GUV tiles has you create the UVs at the lowest sub-D level. I have to vertically flip the textures in ZB before I export them. 3Dcoat reads the Y-Green normal map channel upside down verses lightwave, zbrush and unity. Z=Up in 3DS max. . .Not that this is ideal but this kind of backwards stuff is everywhere.

bobakabob
01-29-2012, 04:40 PM
If render time is priority, perhaps. I've been doing a ton of production shots in LW 10.1 and I haven't personally noticed any increased render times needed to get good AA. And this is compared to my years of work in the 9.X series. Whatever the issue is, I am glad it's getting fixed in LW 11 though it would be nice to get an update to LW 10.1. Perhaps try your scene both ways and see which takes longer to get the quality you need, though you may have to adjust your light settings to get them to look similar.


No not really. Having more flexibility for grading in post is a result of saving your renders in a higher bit-depth file format (i.e. more color data in the actual image file). So instead of rending to an 8-bit JPG or TIFF, render to a 16-bit TIFF, or even better a 32-bit EXR. Though if you're saving in EXR and using a LWF (linear workflow) you should set your output to "Linear" as the EXR format assumes a linear-gamma image.

Using a LWF basically sets all your image textures, lights, backgrounds, and fog to linear-gamma which is correct for LW's linear render engine. So the benefit is more realistic/natural shadows, spec hits, reflections, color blending between edges of objects in your scene (especially if you're rending with motion blur or DOF). Basically your image will look more natural. There's actually a lot of benefits, but most people only usually mention the shadow levels. If your image is looking washed out when you set the CS to "sRGB" then you need to adjust your light and radiosity levels and "dial" it back into something that looks natural. If you have an image looking good using LWF settings, then when you turn them off (i.e. switching the CS tab back to "Linear"), it will and should look unusually dark. This is because you're looking at a raw, linear, gamma 1.0 image which is way too dark on normal monitors, but this is all correct.

I personally use LWF for everything and I render my output in linear to EXR. Then I bring that into Nuke, which like LW is also native linear, and work with Nuke's sRGB LUT (lookup table) settings. The entire comp is done in linear. Then I can output to linear, cineon, or sRGB depending on where my render is headed (e.g. to a DI color suite, to a Quicktime for a director to watch, etc.)

You don't have to use LWF and people haven't for years and continue to do so. When you don't, you just have to fight with light settings a little more to get things to appear more natural (shadows, texture brightness, everything I mentioned above). You can still render to a 32-bit TIFF or EXR, you just have to remember that you've "burned in" the image at sRGB and you'll need to "back off" the sRGB by using an inverse LUT in a linear comp environment like Nuke (which is easy to do as it's designed to do this as well).

Yeah the preset dropdown is a little confusing on the CS tab in LW. Whenever I explain it to new people I always say that the dropdown refers to what you're "viewing" in. You're always "working" in linear in LW no matter what because it's a linear renderer. But if you set the dropdown to "sRGB" that means you're viewing in sRGB (i.e. LW is correcting it to sRGB). If you set the dropdown to "Linear" then LW is doing nothing to it and it's WYSIWYG (what you see is what you get) which is technically linear, but not utilizing a LWF, which is the way LW has always been pre-10 (unles you were using DP's nodes to do a LWF - like I did :)).

One helpful note, your lights should always have their falloff set to inverse-squared if you're using LWF as this is how lights naturally behave. If you want the "natural" look, then make sure this is set if you're using falloff (which you should if you're going for realism).

I hope this helps. Feel free to ask any further questions. It took me a while to "get it" but now that I understand I'll always use it.

Evolross, many thanks for such detailed helpful information :)

stiff paper
01-29-2012, 04:46 PM
is there anything I can do in order to make you understand this? A video mayhaps?
Ah, sorry. I've left you with a misunderstanding. My fault.

I can use LWF in 10.x with no problems. It's just that the first time I looked at it, it was, very clearly, completely Looney-Tunes. And just because I can sit there afterwards and work out how it works, I don't personally think that makes it okay for it to be, in the immortal words of Rocky Balboa, "Mentally irregular."

I'll never understand why it's so hard for software developers to ask some "normal" people "Does that make sense and work for you?" but it obviously is hard for them because they never seem to.

biliousfrog
01-29-2012, 04:47 PM
The past few posts have basically backed up what we're (mostly) all saying. LWF takes some understanding but I, like many, have been doing it manually in 9.6 for ages. LW10 does make things easier, to a degree, but getting it all set up correctly is far more convoluted and confusing than it should be...especially as there are presets to 'make it simple'.

As cardboard has pointed out, if the user has to alter their thinking and work in a way that is unintuitive then the design of the product has failed. I'm sure we've all struggled with something in the past but, when someone has shown us how to achieve our goal, we've thought, "ah, that makes sense"...well, that's because the product is well designed. If, after being shown how to do something, you think, "eh?...why have I got to do it like that?"...that's a fail. In terms of software, the former is when programmers create what the user's expect, the latter is what happens when the programmers create a tool with little understanding of how it will be used and by whom.

Mr Rid
01-29-2012, 04:47 PM
"You can remove the curve from all your images and from all your color settings on everything, then do a render like that, then afterwards you can put the curve back on your finished render and it will look a lot better."

If I read that, I would only wonder 'why remove the curve then put it back... doesnt that put you back where you started? Why not simply drag a few level sliders in post, instead of dicking with adding color profiles and gamma correction to every image, and changing the color picker and everything about how you've spent years lighting and surfacing?' Trying to explain why 'its better' heads down a bumpy road of 'linear-log-LUT-color-space-flow-gamma-voltage-color-bits-profile-srgb-linear-tristumulus-absolute colorimetric... wuh? I just want brighter mids, right?... then what if I dont prefer the way that looks?... and what if the other facility we have to work with is not doing this, or has a different approach or color requirement?... how do we make sure we are all looking at the exact same value on all the apps on all the displays and platforms?'

biliousfrog
01-29-2012, 04:56 PM
I'll never understand why it's so hard for software developers to ask some "normal" people "Does that make sense and work for you?" but it obviously is hard for them because they never seem to.

hehe...well, I wish I had a penny for every time I've heard, "we've been listening to our users and..."

I guess the problem is that the users aren't specific enough. They'll say, "I wish that we had this..." and that's what you get. Perhaps they should say, "I wish that we had this...and it should work by doing this...".

stiff paper
01-29-2012, 04:56 PM
"You can remove the curve from all your images and from all your color settings on everything, then do a render like that, then afterwards you can put the curve back on your finished render and it will look a lot better."

If I read that, I would only wonder 'why remove the curve then put it back... dosent that put you back where... (TRIMMED)

Yeah, well I shortened it a bit for the sake of a post that wasn't eight miles long. Having said that, probably all that really needs adding is "Because the render engine does its math all wrong on the images unless you remove the curve, and it gets shadow values particularly wrong."

My base point was (attempting to be) that all I needed was a simple, straightforward outline of "This is going on" and "This is what you do to fix it" and I could be off fooling around with it to see what it actually did. In that sense, having then read Gerardo's node class, I found the 9.6 LWF to be... well... sensible... and easy to understand.

Cageman
01-29-2012, 05:06 PM
"You can remove the curve from all your images and from all your color settings on everything, then do a render like that, then afterwards you can put the curve back on your finished render and it will look a lot better."

If I read that, I would only wonder 'why remove the curve then put it back... doesnt that put you back where you started? Why not simply drag a few level sliders in post, instead of dicking with adding color profiles and gamma correction to every image, and changing the color picker and everything about how you've spent years lighting and surfacing?' Trying to explain why 'its better' heads down a bumpy road of 'linear-log-LUT-color-space-flow-gamma-voltage-color-bits-profile-srgb-linear-tristumulus-absolute colorimetric... wuh? I just want brighter mids, right?... then what if I dont prefer the way that looks?... and what if the other facility we have to work with is not doing this, or has a different approach or color requirement?... how do we make sure we are all looking at the exact same value on all the apps on all the displays and platforms?'

In such cases you have carfully calibrated monitors with a custom LUT that is used throughout the pipeline.

In any case... I'm done with this thread. If people want to ***** about something that is super-easy to understand and use, then... by all means... count me out.

:)

EDIT: Btw... by enforcing LCW, you are also adding more information into the darker areas of a render, so if you are to adjust it in comp, you have way more information compared to when you are not using LCW.

:)

evolross
01-29-2012, 05:18 PM
If I read that, I would only wonder 'why remove the curve then put it back... doesnt that put you back where you started? Why not simply drag a few level sliders in post, instead of dicking with adding color profiles and gamma correction to every image, and changing the color picker and everything about how you've spent years lighting and surfacing?' Trying to explain why 'its better' heads down a bumpy road of 'linear-log-LUT-color-space-flow-gamma-voltage-color-bits-profile-srgb-linear-tristumulus-absolute colorimetric... wuh? I just want brighter mids, right?... then what if I dont prefer the way that looks?... and what if the other facility we have to work with is not doing this, or has a different approach or color requirement?... how do we make sure we are all looking at the exact same value on all the apps on all the displays and platforms?'
There's actually a heap of benefits to using LWF. Gerardo Estrada wrote several articles for HDRI3D that explain. It's not just shadow falloff. It's light falloff, DOF and bokeh effects, motion blur, edge color blending, accurate texture brightness, better in-texture anti-aliasing, reflection brightness in motion blur and DOF.

In a nutshell the reason to do it is because LW's renderer's mathematical computations are all in linear gamma. So if you're inputting a bunch of 2.2 gamma textures from the web and light colors/levels you picked on your 2.2 gamma monitor, it's all going into a mathematical formula that assume 1.0 levels to return "accurate" and "natural" results. If you ignore all this, your render will obviously still turn out okay, especially if you tweak it, but if you want to emulate the true phenomenon of light behaviors, blending, falloffs, etc., you should use LWF. You may not see the difference in every single shot you do, but overall you'll achieve a more accurate and realistic result. As a 3D artist, I feel I have no choice but to do everything possible to achieve realism (if realism is the style I'm going for - which in VFX it always is).

I personally think the workflow in LW10 is excellent and quite simple. Yes, there's a lot of dropdowns and switches on that CS tab, but like anything in LW (and 3D software), once you read and learn what they all do you'll understand it.

And doing a LWF in LW9.X was a pain. Gamma correcting every image in the Image Editor, adding the gamma correction on the processing panel, remembering to turn it off on final render... ugh.

LWF in LW10 is setting one dropdown to "sRGB" on the CS tab and changing the output space to "Linear". That's it. How is that more complicated than doing it in LW9.X? :stumped:

geo_n
01-29-2012, 05:24 PM
What's the confusion? Nobody tried to use linearworkflow with vray or kray before?
Its the same and vray has had it for ages. Lightwave 10.1 is actually easier with presets. In vray and kray you have to put numbers in the cs parameters. I would never do lwf in lw 9.6. Its tedious to change parameters one by one. It doesn't mean renders won't look good without linearworkflow in lw 9.6 though. LWF is not an absolute requirement all the time. Even some comments from BSG artist says what the heck is linearworkflow and who needs it. But its a must for archiviz where realism is pure and not blurred to death like in vfx.

Cageman
01-29-2012, 05:30 PM
LWF in LW10 is setting one dropdown to "sRGB" on the CS tab and changing the output space to "Linear". That's it. How is that more complicated than doing it in LW9.X? :stumped:

I said I was done with this thread, but I just wanted to say: Thank you, evolross. Good explanation!!!!

Cheers!

Lightwolf
01-29-2012, 05:43 PM
Here's an example of how I use colours spaces (which differs from Cageman) - and my reasoning for it:
101302
This is designed for assets and contents created in 10.x and higher.

First of all... I'm not converting anything automatically. Since the image textures I use come from different sources and are saved with or without gamma, I tend to assign a CS manually to them in the image editor.

Picked colour and Light colours are something I keep linear. This makes sure that the values stored in surfaces and scenes are linear, which I regard as an absolute measure.
It also reduces the risk of accidentally using assets that were saved in Layout with a different Picked Colors setting.
To be perfectly honest, I consider both of these settings to be too confusing as well as dangerous. Their only reason of existance are legacy assets - and I'm sure there could have been a more elegant way to convert the colour values stored in them (which, in older LW versions, were technically linear but picked and stored at the display colour space due to the lack of colour space support).

If I need to change them manually to match something, I go through the colour picker anyhow, which is colour corrected (as seen at the bottom). (plug!) I've also written a small generic plugin to convert single colours from one colour space to another.

Finally, the Output Color is set to sRGB as well, but that only affects temp images that I save (i.e. PNGs for clients) since I (obviously) save finals as linear using exrTrader anyhow.

And yes, as was pointed out earlier, the reason for linear is that the maths used by the renderer doesn't produce the correct results in any other case.

Cheers,
Mike

Matt
01-29-2012, 05:47 PM
In LW10? No. I find it ridiculous and wrong-headed and backwards.

It's the same process but in one panel, no need to jump all over the UI adding plugins.

It's really quite simple:

Cageman
01-29-2012, 05:53 PM
But we, collectively, seem to keep using "It's completely insane but once you adapt you can use it" as an excuse as to why Newtek can carry on making things be non-intuitive and clumsy, and I honestly think it's not a helpful thing to keep doing. Surely it would be much better all 'round for everybody if everybody pointed at the things that don't make sense and shouted about them. That way, if those things are then altered so they do make sense and are intuitive, we might be able to pull in some new users who otherwise would be off to intuitive and nicely explained "other-3D-land".

Sorry... I must have missed this post...

The number of people who were confused by LCW in LW10.x when first initated to it was large, the number of people today has shrunk to about a handfull.

Sure, every new user might be confused, but it is also about reading and learning. A new feature needs a certain ammount of reading and understanding before becomming usefull. This goes for everything in any 3D application or other tool.

So... your point is moot, at best... because you have learned how to do it in one way, and when a feature is introduced that somehow conflicts with what you have learned (and, btw... LCW in LW9.x is a huge nest of workarounds), you oppose it, rather than learn how to use it... and.. again, look at the labeling in CS-window... it clearly says what to do. The ONLY thing you have to know is wether your source material is Linear or sRGB, or if it is created with a custom LUT (palette) and if using a cutom LUT, you use that instead of sRGB. That is about what you need to know.

:)

geo_n
01-29-2012, 06:04 PM
The confusion seems to be not only with the implementation but what the heck is lwf for some.
"why remove the curve then put it back... doesnt that put you back where you started?"

Forgive my probably confusing logic. Here's why it doesn't go back where you started from.

Remove curve before input to linear renderer. Output(linear exr) is now perfectly equal and linear. Adding anything in post is adding to an equalize output. That's good.

An input with curves that is higher, FED to a linear renderer. Output has some values that are not perfectly equal and linear because we didn't remove the curve in the first place. Adding to this in post will probably result in some higher values that result in overbrights, contrasty areas. We compensate thru a lot of brightness contrast adjustment. Not bad but could be better.

Linearworkflow will make things consistent and predictable.

Cageman
01-29-2012, 06:10 PM
Linearworkflow will make things consistent and predictable.

+1

You hit the nail on that one! Thanks for explaining that so well. Yes.. we did see this a lot in our LW9.x renders (not using LCW since it is a tedious process when you have hundreds of textures where some were linear, some were sRGB etc, not to mention all the lights that would have required a custom colorpicker).

LW10.x (and certanly LW11) has been very good for us within our pipeline, and it is so much faster to setup.

:)

biliousfrog
01-29-2012, 06:14 PM
Sure, every new user might be confused, but it is also about reading and learning. A new feature needs a certain ammount of reading and understanding before becomming usefull. This goes for everything in any 3D application or other tool.

So... your point is moot, at best...

I think that the point being made is that the presets contradict what they seem to suggest. The confusion is not about what LWF is or does but how the preset for LWF is called sRGB and vice-versa.




LWF in LW10 is setting one dropdown to "sRGB" on the CS tab and changing the output space to "Linear". That's it. How is that more complicated than doing it in LW9.X? :stumped:

Again, you have missed the point. The process is not more complicated than 9.6 but the application of the process is more confusing because of how the LCS settings are labelled.


How? It's the same process but in one panel, no need to jump all over the UI adding plugins.

It's certainly not ridiculous, wrong-headed or backwards at all.

It's really quite simple:

...and finally...read the above.

Also, the argument that Kray and Vray also works like this is possibly incorrect. As far as I can remember Kray automatically adjusts the input gamma and outputs to linear, you don't need to change anything by default. In order for Lightwave to work in the same way, as has been mentioned, twisted and ignored, you need to change the default preset (LINEAR) to sRGB. But it doesn't stop there...the sRGB preset doesn't save 32bit images so you have to change the output to Linear.

I'll repeat that.

In order to work in LINEAR colour space the user needs to change the default preset of having everything set to LINEAR to sRGB.

LINEAR = sRGB

Really?...technically, yes it makes sense but it is obviously causing confusion, even for people that have been using LWF for a looong time.

Cageman
01-29-2012, 06:18 PM
I think that the point being made is that the presets contradict what they seem to suggest. The confusion is not about what LWF is or does but how the preset for LWF is called sRGB and vice-versa.

Again... read the labeling: "Convert Colorspace to Linear"

Colorspace in this sense is reffering to your input... is your input sRGB, then, set it to sRGB so that LW can "Convert Colorspace sRGB to Linear".

How hard is that to understand?

Matt
01-29-2012, 06:24 PM
For those that don't "get it", seriously, look at these slides:

Linear_Workflow_in_LightWave.zip (http://www.pixsim.co.uk/downloads/Linear_Workflow_in_LightWave.zip)

Matt
01-29-2012, 06:26 PM
I think that the point being made is that the presets contradict what they seem to suggest

They are 100% correct though, labelling it the other way so when selecting "Linear" you're in "Linear Workflow Flow" would be wrong.

geo_n
01-29-2012, 06:28 PM
Also, the argument that Kray and Vray also works like this is possibly incorrect. As far as I can remember Kray automatically adjusts the input gamma and outputs to linear, you don't need to change anything by default.



See there's the confusion again
In order to work in linearworkflow in kray, you put kray quicklwf masterplugin which has a value 2.2. That's similar to srgb in lw 10.1. But this parameter is not fixed. You can adjust it for other platforms. Kray DOES NOT automatically adjust inputs to linear. This also confused some kray users of which linearworkflow method to use with the release of lw 10.1. Some accidentally activated both and resulted in double values.

In vray its the same. You activate gamma and lut and add gamma 2.2(srgb) to your Input, check affect colors, material editor. Output is not changed and stays in 1.0. To add:If you use vrayframe buffer you can add srgb to your imagepreview render just like lw 10.1 set display to srgb but still save renders in linear(recommended).

Now how is lw 10.1 any different to all "degamma your inputs" workflow? :D

Matt
01-29-2012, 06:31 PM
My tutorial for Kray for those interested:

Gamma_Correction_Options_in_Kray.zip (http://www.pixsim.co.uk/video_tutorials/Gamma_Correction_Options_in_Kray.zip)

Cageman
01-29-2012, 06:35 PM
For those that don't "get it", seriously, look at these slides:

Linear_Workflow_in_LightWave.zip (http://www.pixsim.co.uk/downloads/Linear_Workflow_in_LightWave.zip)

That is a very good slide... :) Thanks for sharing! :thumbsup:

Cageman
01-29-2012, 06:40 PM
My tutorial for Kray for those interested:

Gamma_Correction_Options_in_Kray.zip (http://www.pixsim.co.uk/video_tutorials/Gamma_Correction_Options_in_Kray.zip)

Lots of golden stuff comming from you lately (not to even mention LW11...)

:thumbsup:

jasonwestmas
01-29-2012, 09:29 PM
Thanks Matt.

jasonwestmas
01-29-2012, 09:45 PM
So uh, what do you guys do for tone mapping without Kray? =)

geo_n
01-29-2012, 11:00 PM
So uh, what do you guys do for tone mapping without Kray? =)

What do you mean? Kray is not needed for tonemapping

jasonwestmas
01-29-2012, 11:01 PM
What do you mean? Kray is not needed for tonemapping

I know, but are there time saving techniques out there without having to tweak the image a bunch in PS?

Edit: I suppose most people just do something similar to this:

http://photoshoptutorials.ws/photoshop-tutorials/photo-manipulation/layered-hdr-tone-mapping.html

not with a real camera obviously but through layering up images?

geo_n
01-30-2012, 12:25 AM
Ah a tonemapper. There's some appz that do tonemap but haven't tried them. Photomatix, etc. But mostly you can save money buying adobe suite and do tonemap in ps or ae using adjustment layers or do tonemap in fusion, nuke ,etc. Its overkill for most though and adobe is just really cheap and capable of motion as well.

biliousfrog
01-30-2012, 02:33 AM
They are 100% correct though, labelling it the other way so when selecting "Linear" you're in "Linear Workflow Flow" would be wrong.

Oh sure, I'm not suggesting that it's incorrect, it's just confusing initially and that could be a problem for many new users as it has been for many people that already used Lightwave.

For starters, "Convert color space to linear" and "Apply color space" could have been called something like "working or display color space" and "output color space". That wording alone would instantly make more sense to me personally. Also, perhaps if there were presets included called Legacy LW and Linear Workflow just for simplicity?...I'm just playing with ideas.

Actually, you know what would be really useful? If Lightwave was set up for LWF with sRGB from the start so that the user doesn't need to set it all up unless they want to work in a different CS.

bazsa73
01-30-2012, 03:24 AM
Thank you everybody, now I get the idea. Or I think I get it.

Lightwolf
01-30-2012, 04:16 AM
For starters, "Convert color space to linear" and "Apply color space" could have been called something like "working or display color space" and "output color space".
But at least the first two would be wrong. The working colour space (as in, the colour space that LW operates in - or presumes to) is always linear.

The headlines only remind you of what the prefs below them do (and you also have the display and output colour space labels there).

One could think about changing the first heading to "Default Source Color Space for:" - but imho that's as far as it goes really.

Cheers,
Mike

biliousfrog
01-30-2012, 04:51 AM
One could think about changing the first heading to "Default Source Color Space for:" - but imho that's as far as it goes really.

Cheers,
Mike

Well that seems like a better heading to me :)

I'm not against educating the user but the learning process should be more linear (excuse the pun). Having a working knowledge of gamma correction and colour spaces shouldn't be a requirement to create a balanced render in LW10+, it should be an option. In much the same way that I didn't want or need a crash course in raytracing and sampling patterns to create my first render.

Imagine starting up a driving game like Need for Speed for example. You want to load the game and play. You don't want to go through the process of learning how to drive first. The argument that, "that's how it is" seem even more ridiculous in that context but it's not dissimilar. Ideally further education and training should enhance the experience not be a requirement.

If you can make the software easier to use from the start then you'll win more users. If you complicate matters by insisting that users understand 'why' something is done a certain way so that they can interpret the interface then the software has failed. NT has always made a big thing about the text based menus which are easier to understand but then confuse people by requiring a manual to interpret the jargon.

Anyway, this has all been said before regarding various aspects of the LW interface from nodes to bizarre tool names to materials that require extra nodes to work as expected...and the response is always the same, it's like that because it's how it is and you need to learn how to use it.

Lightwolf
01-30-2012, 05:00 AM
I'm not against educating the user but the learning process should be more linear (excuse the pun). Having a working knowledge of gamma correction and colour spaces shouldn't be a requirement to create a balanced render in LW10+, it should be an option.
And it isn't. All the users really need to do is tell LW what kind of images they're feeding into it... and what they want out of it (and what it's being viewed on. And yes, I'd prefer LW to automatically use monitor profiles as defined in the OS)...

However, compared to colour management options in packages that are primarily designed for print (here's looking at Adobe), it's a piece of cake.


You want to load the game and play. You don't want to go through the process of learning how to drive first.
If you know how to drive. This is a case where, apparently, many don't.

There's also nothing stopping anybody from just leaving everything as it is by default. You'll get the same renders as in the LW versions before that.

The requirement to learn something (which I can't imagine taking more than half and hour to grasp the basics of which options to set to which
values) only arises if you want to move beyond that.

And you need that requirement because there's plenty of stuff that is completely outside of the control of LW (such as detecting the colour space of source images, which it attempts to do anyhow. So far it never managed to do so for any of the images I loaded).

Cheers,
Mike

jasonwestmas
01-30-2012, 08:09 AM
Ah a tonemapper. There's some appz that do tonemap but haven't tried them. Photomatix, etc. But mostly you can save money buying adobe suite and do tonemap in ps or ae using adjustment layers or do tonemap in fusion, nuke ,etc. Its overkill for most though and adobe is just really cheap and capable of motion as well.

Yeah that makes sense. . .thanks.

jburford
01-30-2012, 08:27 AM
Matt,

Thanks for the great links and slides!

evolross
01-30-2012, 10:30 AM
But it doesn't stop there...the sRGB preset doesn't save 32bit images so you have to change the output to Linear.
The output color space has nothing to do with the bit depth of the image that gets saved out.

The output color space simply sets what color space is burned into the image. "sRGB" burns the sRGB gamma/LUT into the image. "Linear" leaves the saved image in linear 1.0 gamma. Either of which can be saved to any bit depth image format. Though if you save linear to an 8 bpc format you can forget about re-LUT'ing in comp as the colors will all crunch because it's only 8 bpc. So technically this would be wrong and bad, but you can still do it if you want.

Whether or not the image is 8-bit (or more accurately 8 bpc (bits per channel)), 16 bpc, or 32 bpc all depends on the image format selected in the render globals panel on the output tab.

8 bpc files would be LW_JPEG, LW_TGA32, LW_TIFF32, LW_PNG32. 16 bpc would be LW_OpenEXR_RGBAHALF. 32 bpc would be LW_TIFF32FP, LW_OpenEXR_RGBAFP, etc.

On a side note, the way LW names its file formats, though accurate, is admittedly confusing. You have to remember, it's not the "32" in the name - that's referring to the fact that is has an alpha channel (RGB at 8 bpc = "24" - RGBA at 8 bpc = "32"). It's the "FP" (floating point or full precision) that determines that it's 32 bpc.

Actually isn't LW_TIFF32FP incorrect? If it's four channels (RGBA) at 32 bpc (thus FP) wouldn't the correct name be LW_TIFF128FP? I think LW should rename all it's file format labels from "24" to RGB and from "32" to RGBA. This would be much less confusing to unknowing users.

hydroclops
01-31-2012, 09:41 AM
...And yes, I'd prefer LW to automatically use monitor profiles as defined in the OS)...

This is where I get confused. Doesn't a linear workflow require hardware calibration and monitor profiles? It's almost never mentioned in these threads.

Lightwolf
01-31-2012, 09:48 AM
This is where I get confused. Doesn't a linear workflow require hardware calibration and monitor profiles? It's almost never mentioned in these threads.
It certainly would if you have a wide gamut display (unless you calibrate that down to sRGB).
However, most other displays do sRGB at most - more or less accurately.
So, while not perfect ... it's close.

Cheers,
Mike

Matt
01-31-2012, 11:11 AM
This is where I get confused. Doesn't a linear workflow require hardware calibration and monitor profiles? It's almost never mentioned in these threads.

Yes, sRGB or Gamma 2.2 is a standard most monitors are set to (many other electronic devices with displays actually) this is so images look consistent across devices.

So in order to ensure your monitor is accurate, you need to calibrate it to get to as close to sRGB standard as possible.

I have this (now discontinued) device: http://www.xrite.com/product_overview.aspx?lang=en&region=94&ID=788

Cageman
01-31-2012, 02:21 PM
Actually, you know what would be really useful? If Lightwave was set up for LWF with sRGB from the start so that the user doesn't need to set it all up unless they want to work in a different CS.

The reason it isn't is (and this is me guessing here) because this would make scenes created in LW9.x and earlier look extremely funky and completely broken when rendering. The best thing to do, imho, is to start using LCW on a fresh project, because it is a can of worms trying to convert an old non LCW project into LCW (depending on the complexity of the scene, of course).

One of the things I do first when having to reinstall or, for some reason clean the configs, is to start LW and set things up with LCW in mind, close LW to save those settings to the config.

jasonwestmas
01-31-2012, 02:27 PM
The reason it isn't is (and this is me guessing here) because this would make scenes created in LW9.x and earlier look extremely funky and completely broken when rendering. The best thing to do, imho, is to start using LCW on a fresh project, because it is a can of worms trying to convert an old non LCW project into LCW (depending on the complexity of the scene, of course).

One of the things I do first when having to reinstall or, for some reason clean the configs, is to start LW and set things up with LCW in mind, close LW to save those settings to the config.

Oh yeah. . .I've brought in plenty of materials and surfaces that I lit and shaded and created textures using the linear color space and it looks awful every time under the srgb model.

biliousfrog
01-31-2012, 02:41 PM
The reason it isn't is (and this is me guessing here) because this would make scenes created in LW9.x and earlier look extremely funky and completely broken when rendering. The best thing to do, imho, is to start using LCW on a fresh project, because it is a can of worms trying to convert an old non LCW project into LCW (depending on the complexity of the scene, of course).

One of the things I do first when having to reinstall or, for some reason clean the configs, is to start LW and set things up with LCW in mind, close LW to save those settings to the config.

I suspect that most people that use v.10+ are using the sRGB settings. It would make more sense IMO if users had to switch to 'legacy' mode if they needed legacy content...in the interests of moving things forward and making the app 'ready to go' for new users and anyone wanting to take advantage of new features. Again, the thinking behind this seems backward, promote a new feature and have it disabled by default...although I'm sure that some will argue that it makes perfect sense.

jasonwestmas
01-31-2012, 02:45 PM
Well there are some people that are dead set against anything that is new (workflow wise) and choose to either wait till the workflow is perfected or has become the norm, them being the last one to adopt the new technology just because it's not perfected which is kinda contradictory to think that way if you ask me. I think some are just not willing to devote the time to learn new stuff (I know it isn't easy).

however, when one adopts new graphics technology it does tend to transform the end results, transforms the overall appearance regardless of how much time the new methodology saves them. So in that regard I guess I can understand it if you are very particular about how your stuff looks in the end and choose to stick with what one knows will get the preferred "style."

biliousfrog
02-01-2012, 02:04 AM
Well there are some people that are dead set against anything that is new (workflow wise) and choose to either wait till the workflow is perfected or has become the norm, them being the last one to adopt the new technology just because it's not perfected which is kinda contradictory to think that way if you ask me. I think some are just not willing to devote the time to learn new stuff (I know it isn't easy).

however, when one adopts new graphics technology it does tend to transform the end results, transforms the overall appearance regardless of how much time the new methodology saves them. So in that regard I guess I can understand it if you are very particular about how your stuff looks in the end and choose to stick with what one knows will get the preferred "style."

It is very contradictory if anyone thinks along those lines, to upgrade to newer software but not want anything to be different...but, at least with the LWF features, they can be set to legacy.

It seems that LW10.1 reverts to the default settings when loading old scenes anyway, I'm not sure if this is a bug or not? It's fine as a feature but I have had to change back to sRGB a few times because it has 'reset' itself.

Lightwolf
02-01-2012, 02:09 AM
It is very contradictory if anyone thinks along those lines, to upgrade to newer software but not want anything to be different...
Which isn't the same though. There's always bound to be areas that some people are perfectly happy with... or where they even think that recent changes made things worse.
An upgrade is a sum of different features... and each one of them can be reviewed on its own.

Cheers,
Mike

biliousfrog
02-01-2012, 02:51 AM
Which isn't the same though. There's always bound to be areas that some people are perfectly happy with... or where they even think that recent changes made things worse.
An upgrade is a sum of different features... and each one of them can be reviewed on its own.

Cheers,
Mike

My thoughts are generally to supply a new product with all the new features enabled so that the benefits of them are instantly available, especially to new users or users who are used to the feature from another package. The option to revert back to the old way is there if needed but it isn't something that new users would probably ever want to do.

Lightwolf
02-01-2012, 03:02 AM
My thoughts are generally to supply a new product with all the new features enabled so that the benefits of them are instantly available, especially to new users or users who are used to the feature from another package. The option to revert back to the old way is there if needed but it isn't something that new users would probably ever want to do.
No doubt... However, here we have a case where having those features enabled would screw up the look of old assets.
Which means that you either need a conversion (which would have been my preference but that also implies that assets won't be backward compatible any more) or a legacy mode that is automatically turned on (which is the current behaviour).

However, even if you start with an sRGB based scene and then add legacy assets you may still run into problems.

Even worse, a conversion wouldn't completely work either, since the visible behaviour of lights changes once you add colour spaces.

Cheers,
Mike