PDA

View Full Version : Maya's Linear Color Space Management vs Lightwave's



DCjr
02-07-2016, 10:35 PM
Is it just me? or is Lightwave easier to work with when it comes to working in Linear Color Space?

I was going through some tutorials on Maya's Linear Color Management on Digital Tutors and I have to repeat the lesson not once but maybe a few times to understand it!

Any thoughts?


Daniel

Surrealist.
02-07-2016, 10:45 PM
It depends what version I suppose. I think it is much more streamlined from around 2014 or 15 on. As I recall for MR you just enable it in the Render options and then choose convert to linear for the images in the Attribute Editor. For Renderman you have to add a Renderman attribute for images, but that is it.

I find LightWave's method, completely and utterly *** backwards as far as naming. Why for example would you choose the sRGB preset when you want a linear color space? And by defalut you open up the CS panel and everything says Linear... great! Took me a week or so before I realized something was wrong.

Anyway, rant over. Everything is fine in LW. It is fairly simple.

But currently in Maya it is too. Just make sure your tutorial is for current versions.

DCjr
02-08-2016, 01:33 AM
thanks!
Yes, I was watching an older lesson. Im using 2015 at the moment. Great!

Surrealist.
02-08-2016, 02:11 AM
Cool, it looks like it is a tad more involved than I described. But it is still fairly manageable and makes sense.

I found this:

https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-F7A7FC66-4D36-4544-9DBD-24FA35C66C2C-htm.html

Gives all the needed info in one place.

spherical
02-08-2016, 02:57 AM
I find LightWave's method, completely and utterly *** backwards as far as naming. Why for example would you choose the sRGB preset when you want a linear color space? And by defalut you open up the CS panel and everything says Linear... great! Took me a week or so before I realized something was wrong.

This still confuses me, so I try not to think about it. Perhaps Gerardo could offer a treatise. Until then, I just go with the flow and use the sRGB preset to get a Linear workspace. Duh.

Surrealist.
02-08-2016, 05:35 AM
lol yeah.

I have worked it out like this:

Top half of panel is convert (whatever your source is) to Linear.

The Bottom half is convert linear (of course what is happening internally) to... whatever your choice is for display or output.

Here is a video:

https://www.youtube.com/watch?v=D2iDv9hnQiw

Probably you've seen it. But maybe it will make more sense now. Maybe not.

I pretty much set it all to default and if I am saving to EXR I choose Linear.

spherical
02-08-2016, 02:44 PM
I pretty much set it all to default and if I am saving to EXR I choose Linear.

Well, there it goes again... :) "Default" is Disabled, which is Linear everything.

Surrealist.
02-08-2016, 03:18 PM
lol sorry. I mean the preset sRGB to its default which I believe has output and display to sRGB. Which is actually sRGB not Linear like in the panel above. So I am switching the output to Linear. Yep actually Linear, here. It says Linear and I am actually setting it to Linear.

But yeah the labeling is *** backwards. You look at that panel and you think. Yep. Linear workflow. That is what I want. It is all set to Linear. Done. I wonder how many people do that?

But in defense of the system as it has it, it is because there is more than one non linear profile. And it additionally gives you the option to recognize that the incoming source could also be Linear and not some kind of gamma correction.

So it is best to think of the top half as "what are my input profiles?"

And each one has a list of common profiles, including the Linear option which assumes no gamma correction at the source.

gerardstrada
02-08-2016, 09:16 PM
Is it just me? or is Lightwave easier to work with when it comes to working in Linear Color Space?l

Yes, in LW is far more easier because all is basically centralized in a single panel. In Maya's MentalRay things are a bit convoluted because one have to go from Render Settings (for input textures/output render passes global adjustments) to Hypershade (for individual per-texture corrections, shaders corrections and picked color corrections of every single input color) and Render View (for preview), so there's no "quick preset" unless is mel scripted (good luck with that!). In LW the per-texture adjustments are done in Image Editor, but it's just a matter of selecting multiple textures and correct them all at once. If good policies for image naming is used, one just filter the correct name and all is done in a couple of clicks. But something interesting is the possibility to generate internal custom matrix-based profiles, though in Maya this is limited to basic gamma curves only and for more complex parametric curves one need to use expressions (remap value can be used for clipping values in ranges beyond 0 and 1).


So it is best to think of the top half as "what are my input profiles?"

Totally agree. The LW CS presets naming assumes the purpose of the CS panel is to work in linear light, that is to say, idea is to convert non-linear colors to linear colors. And which are the colorspaces of these non-linear colors that we need to linearize? and which is the colorspace we are gonna output? There one have the name of the preset.

This is why -for the input colorspaces- the CS panel says: "Convert Color Space to Linear". If we pick Linear for any of those options, it means that nothing is gonna change (because linear = linear) and no conversion would be made.

If the sRGB preset would be called "Linear", how would we call a preset for input colors coming from HDTV or from DPX for example? how to differentiate them from sRGB? As you say, there's more than one non-linear profile, A LOT more than one, I'd add http://forums.newtek.com/images/icons/icon7.png

Of course we can create another preset with the name we think is more appropriate.



Gerardo

spherical
02-08-2016, 11:07 PM
Thanks, Gerardo. I knew you'd come through. :) Ok, so to chew this and spit it out in a different way:

LightWave always works internally in Linear and, as Surrealist says, the presets are chosen based upon what one's input data color spaces are. Similarly, the output device Color Space follows. The BIG question is (having loaded Modeler just now to check something), WHY/HOW have I completely missed the "Convert Color Space To Linear" and "Apply Color Space" labels on that panel all this time?????! D'oh!

Surrealist.
02-09-2016, 12:22 AM
I think the interface could be rearranged to be less confusing.

Something like this would be clear as day:

SOURCE TYPE_________SOURCE COLOR SPACE________CONVERT TO LINEAR

8 BIT_________________DROP DOWN LIST_____________BOOLEAN CHECK BOX
FLOATING _____________DROP DOWN LIST_____________BOOLEAN CHECK BOX
COLOR PICKER__________DROP DOWN LIST_____________BOOLEAN CHECK BOX
ETC.

Options under Convert To Linear obviously simply a checkbox to enable it or disable it.

Options for the source drop down would be:

Most common existing color spaces NOT including Linear.

And this also more closely matches what is happening.

Having Linear as a Source option is not only incorrect, it is misleading and confusing because it is redundant.

If an input is some kind of Gama curve and you have this setting to Linear, then it means LightWave is doing nothing to that source. Meaning it is treating it as if it is Linear. And traditionally this was the way of things prior to having Linear Workflow in interfaces. So in other words, none or off.

Yet in the same breath you are trying to say that this is the source profile, which it isn't. So you are in effect asking the user to make an "incorrect" setting to be "correct". And justifying this by saying that LightWave is treating it as if it is Linear. Which is the same thing as saying "none".

So if you have a source that is already Linear then you don't have to do anything to it, or rather, off or none. Linear is not needed as a source option.

Rather, the thing to do is if "Convert to Linear" checkbox is on, then it gives you the Gama options under source profile. If the checkbox is unchecked, then the Gamma source list is greyed out and unavailable. This would be the same as having the Linear setting as it is now. But far less confusing. If you know your source is Linear there should be no reason to do anything. So uncheck and conversion is off (Linear) for that input.

I don't know if this is some programming feat to change but it seems like it could hook up to the code in the same way. But I have no way of knowing.

The output options are fine as they are because it is closer to what we are doing. We are displaying or saving out to a profile. Linear or some kind of Gamma depending on the target.

gerardstrada
02-09-2016, 05:40 PM
Spherical, yeah well, I've seen some excellent VFX Supervisors overlooking this same thing in the CS panel. Probably if that part would be labeled as "Input/Output Colors" or something like that, it could be more clear. But think there are more important things to be implemented to bring LW CM to a next level.


Surrealist, yes, linear is the same thing as none conversion in the context of Convert Color Space to Linear. After that, Linear also means none conversion for output or display spaces. Then it's not really a justification saying that LightWave is treating it as if it is Linear, because that's precisely what it's doing in the context of the CS panel.

Though a "Linearize input space" or "remove gamma" checkbox is not a bad idea and it just adds an additional click. Maybe other option could be just rename "Linear" as "Raw" or something like that.

I get your point about linear as input space in the current LW context, but conceptually speaking, having linear as a input space is not incorrect because the input space can be indeed linear and one could even have linear versions of any colorspace. "Linear" is not a single colorspace as one might think, and one may need to convert from one linear colorspace to another linear colorspace. The situation is that in current LW version, the linearization of input colors is done at "gamma" level only and in such case yes, there's a single linear gamma space. Thing that might change (be improved) eventually.



Gerardo

spherical
02-09-2016, 07:02 PM
Spherical, yeah well, I've seen some excellent VFX Supervisors overlooking this same thing in the CS panel. Probably if that part would be labeled as "Input/Output Colors" or something like that, it could be more clear. But think there are more important things to be implemented to bring LW CM to a next level.

Enervating to know I'm in good company. :D

All it would have taken for me is to make the two lines bold, as in more of a section heading. I just totally glossed over it... how many times now; with all of these versions installed and having to be set?


Maybe other option could be just rename "Linear" as "Raw" or something like that.

"No Correction" works for me; way better than "Disabled", as the former says what isn't happening. Now that the realization that LightWave always works internally in Linear (I knew that...), "Disabled" does make sense of sorts, but unless those full concepts are known and considered, "Disabled" doesn't seem like an active choice, if you will. IOW, I want to choose something to be done, even if it is "Don't do Anything". Choosing "Disabled" just seems like a negative rather than a positive choice.

gerardstrada
02-09-2016, 08:29 PM
Just in case, the "Raw" name idea was for the linear profile, not for the quick preset.

As for the "Disabled" or "No Correction" as an inactive preset, I think it might have to do with the fact that LW doesn't want to risk to make assumptions about the user's color flow. Though is not easy, I think they should. Not easy because just consider the display aspect only. One can work in sRGB standard, or aRGB standard, or P3-D60 standard, or DCI-P3, or Rec. 709, or Rec. 2020, etc. If LW assumes sRGB display standard as default, people who don't work with that display standard would have things wrongly setup just out of the box without even opening the CS panel and probably wouldn't know they are having the wrong preview. Leaving things "disabled" let people at least to know there's "something" they NEED to do (or learn).

They could add a warning about a default "active" preset, but there will be always people complaining about why LW is taking wrong decisions for them instead of letting them decide what to do. Even so, I think the sRGB preset can be the "less problematic" default preset.

If you ask me, I think the CS panel is one of the easier to use that I've tried (and it works very decently correct in its context boundaries) but again, there are more important aspects to improve, for expanding its CM capabilities, flexibility and automation.



Gerardo

jeric_synergy
02-09-2016, 08:33 PM
Enervating to know I'm in good company. :D
"Enervating"? Interesting.

spherical
02-09-2016, 09:51 PM
Damn autocorrect, anyway!

Surrealist.
02-10-2016, 12:52 AM
Apparently this is a very confusing subject. It does not seem confusing at all to me. But this interface in its current form breeds confusion, even as pointed out, with people who know this subject. Which I did.

In all of the other interfaces I use there is a simple Check Box. Next to it it says something to the effect of "Linearize...Images, inputs or whatever.

In Renderman it is like so:

https://rendermansite.pixar.com/ca_twopointo_cms_data/images/15089_6415.jpg

https://renderman.pixar.com/view/LinearWorkflow

If you notice it is very clear what you are doing and you even have the option to change the the input space. Yes it is in another panel someplace else. Convoluted, but correct.

Now LightWave has "simplified" this process by putting it all in one panel.

But it is like that Hemingway quote. "The operation was successful but we lost the patient".

Less convoluted but misleading and not really representative of what is really happening with current technology and general understanding of color space.

Linear should not be an input option. It is redundant and confusing. A check box might be one more thing to click but it is clear and not confusing and it also is in line with other apps and they way we understand it.

You are either correcting gamma or you are not. And additionally there is more than one gamma. Presently that is all we need to know. And presently Linear is not a gamma space. It is not an option it is not a choice and it should not be there. The only option that applies is "off", "Disabled" or better, a Boolean.

And this is how you get an interface that (by default mind you!) shows everything as Linear.

And that is just wrong.

gerardstrada
02-10-2016, 05:52 PM
Renderman assumes only sRGB when linearizing input images, which is only correct for sRGB images, but not for everything else. FP images are automatically assumed linear. If we want to change any of this, we need to use Maya color profile drop down - where - you also have Linear input space options for sRGB and Rec.709.

http://s10.postimg.org/dhqnevfa1/maya_CP.png

So linear IS an input option in Maya too (and in other 3d and compositing packages), and it's not misleading and it's indeed representative of what's happening in LW when we read what the parameter is doing: "Convert Color Space TO Linear". Then if it's Linear to Linear, nothing is going to happen. That clearly means, you are not correcting gamma and that's why that preset is called "Disabled". Guess the confusion comes when people don't read that sentence in the CS panel and think that "Linear" means "Linearized". In such case, an additional "Linearize space" checkbox is an option.

However, Linear colorspaces ARE real input options, and Linear IS a gamma space too, which means that the power of energy than enters is the same than the power of energy than exits.



Gerardo

Surrealist.
02-10-2016, 08:52 PM
lol yes. But LightWave does not have Linear... sRGB now does it? No. It just has Linear option. And it is not doing anything with it but nothing. Which is redundant and misleading.

Now if it had Linear sRGB That'd be perfectly fine.

And the whole point I am making here is that of course yes, once you learn what is meant by "Convert to Linear" and then you see there are drop downs, you get that you are making input options.

All the way up to the point where one of them is Linear which is misleading and confusing. And also redundant. You don't need it. Because you already know if your input is in Linear space it needs no conversion.

But the biggest confusion of all is when you first open the panel to have a look at color spaces.

Because of this bad design, you can be lead immediately to believe that you are operating in Linear space. That is just wrong.

On the other hand. If you opened the panel and saw that all the inputs were unchecked or greyed out or whatever, then it'd be immediately clear. And you'd know you have to do something.

Further if you looked at the default presets and it said something like it says now which is "Disabled" and also confirmed by Booleans off, greyed out or whatever, it would be further clear.

And then if you had a preset that said something like sRGB to Linear etc. Then you'd again know what you are doing.

Now mind you all of this is coming from my experience as a user with a very basic level understanding of this and how I reacted when I first opened up this panel.

My very first opinion and exasperation when I finally understood what this panel was about was how *** backwards it was.

This is not a discussion in my opinion about color space as much as it is about what I think most users would expect.

And LightWave in this case is way off the mark.

gerardstrada
02-11-2016, 02:14 AM
In practice, Maya is really providing just a single linear option out of the box, but with two different names (Linear sRGB and Linear Rec. 709). Both colorspaces have same primaries and white points and in the context of its usage these are not display profiles so black points doesn't count. Therefore, both linear versions are exactly the same. But there's a reason for this naming convention. In Maya one can specify other colorspace characteristics more than just the gamma. Which means that if conversions would be taking into account the gamma only, no other colorspace specification for Linear would be needed. And that's precisely what LW is doing, and this lets you know immediately what's going on behind the scenes, seeing that if you know this subject and see just a single Linear, you'll know automatically that these conversions are just at gamma level.

So same as in LW, Maya users know that if a given 16-bpc image is in linear space, they need to use Linear sRGB (or Linear Rec. 709? anyway, it's the same thing!). This is because in Maya, same as in LW (and in almost any other CM-based app), user needs to specify the input space, and if the input space is linear, Linear should be set up.

I understand one may overlook the "Convert to Linear" sentence in the CS panel, I understand one may not know what it means, but what would really lead to mislead is to assume we comprehend something that we know we don't really understand. First thing we need to assume is that CM IS a complex topic, and many different approaches can be implemented in every single app (correct or incorrect) and I wouldn't dare to just skipping what the manual or the developers have to say about how this topic works specifically in their apps. So my advise for people who know that they know about this subject and for people who know they don't know about this topic is: RTMF! (read the manual first) http://forums.newtek.com/images/icons/icon7.png

And what's what the LW manual has to say about this?

"By default, LightWave is set not to do any conversion - the Linear setting,
but to better suit work for the monitor, switch to sRGB. For better work for
cinema choose Cineon and for widescreen high definition TV choose Rec.709.
These choices will help convert images that may already have color space
definitions and keep their colors pure."

(the bold in the text was added by me)

So it's very clear here that Linear setting does not do any conversion. And there's also other interesting hint, keeping "pure" the colors means that LW is performing these color conversions at gamma level only and other colorspace definitions are in hands of the user. And other solutions are necessary for that.



Gerardo

Surrealist.
02-11-2016, 03:14 AM
Again you further bolster my point. Just as you did the last time. And in fact the more light you shed on this topic the more it is clear that the interface is wrong.

And I will have to you know the very first thing I did was go to the flipin' manual!
And that made it even all the more confusing.

That paragraph you posted is a prime example. If LightWave by default is doing nothing then why should I have to set it to Linear? That is just *** backwards.

And I already understood that there are other color spaces than sRGB. And I understood, once I got past the poor interface, that was causing me to get confused over something I already knew, how the damn thing works!

And prior to this I also had done tutorials, watched videos, read both the Renderman and the Maya Manual. As a user I already understood how this was all supposed to work. And had been using Linear color space quite comfortably and happily. That is until I opened up this panel for the first time.

But we are not talking about reading manuals and being good little boys and girls. Nor are we even talking about understanding color space.

We are taking about feedback you get from an interface.

And you can justify it all day long with as many intelligent responses that show you can talk circles around anyone on the subject. But it does not change my feedback on the interface.

And the interface is there for users, not engineers and geeks. But the average user.

And most people or I should say, most common users would agree with me. It breeds confusion on first encounter.

I can not say that at all about Renderman or Maya. It was very simple and clear to understand.

There is no way LightWave has to have the interface this way.

I gave my feedback and even posted a good solution as to an alternative.

LightWave can have all the features it has. Just tweak the interface so it is not confusing.

gerardstrada
02-11-2016, 03:37 AM
Well, the feedback you get from the interfase in pretty clear if you know this subject, and if you don't, there's the manual, and what's what both say?

"Convert Colorspace To Linear"

If input is Linear, then linear needs to be chosen. If it's not linear, then other colorspaces need to be setup there.

The scenario where one can get this wrong is if one don't know what "Convert ColorSpace to Linear" means or just overlook it. And if the problem is that many people overlook it (as it seems is the most probable thing), then they can make it more visible, or add an additional "Linearize colorspace" checkbox as you are suggesting. But it doesn't mean that what's there is misleading, because the terms are defined and correct, in the interface and in the manual.



Gerardo

Surrealist.
02-11-2016, 07:01 AM
Well sure yeah I understand where you are coming from. I just don't agree from the point of view of an interface design. I think your thoughts are clear and informative. Just not appropriate for being sensitive to feedback on an interface from users.

I am a user. I am giving feedback. I understand the process. I looked in the manual, tried to understand the interface, searched the forums, google, everything. Even wound up talking to a friend and just asked him point blank what are the setting supposed to be.

That is the feedback. You might not agree it is valid for your own reasons.

Software designers can't make assumptions about what people are doing or have done or understand or don't understand based on only their level of expertise or the level they expect people to be at.

Software designers have to listen to feedback from users to find out their inclinations and expectations. And that is what drives interface design.

But feedback on design needs to come from users. Not engineers.

And I have already made my case as to why I feel the way I do and there is no point in repeating it. I feel what I have said stands on it own as valid feedback.

djwaterman
02-11-2016, 08:46 AM
The problem is that if you change the labeling you will get an equal amount of complaints from tech heads who have no issue with the current set up, so best to stick with what's technically correct to avoid any confusion to what is a confusing subject to begin with. Lightwave makes it very simple if you let go of trying to second guess things and just use the preset. I think LW has the easier color management compared to Maya.

Ztreem
02-11-2016, 09:29 AM
The problem is that if you change the labeling you will get an equal amount of complaints from tech heads who have no issue with the current set up, so best to stick with what's technically correct to avoid any confusion to what is a confusing subject to begin with. Lightwave makes it very simple if you let go of trying to second guess things and just use the preset. I think LW has the easier color management compared to Maya.

I agree. I think the color management in LW is very straight forward and easy to use. A while ago when I tried to do some color management in After Effects I only got confused, not as clear as in LW.

spherical
02-11-2016, 03:15 PM
The problem is that if you change the labeling you will get an equal amount of complaints from tech heads who have no issue with the current set up, so best to stick with what's technically correct to avoid any confusion to what is a confusing subject to begin with. Lightwave makes it very simple if you let go of trying to second guess things and just use the preset. I think LW has the easier color management compared to Maya.

Well, the default "Disabled" could still be changed to "No Correction" (which makes it a positive choice, not "no workie") and it would be more clear, intuitive, technically correct and not change the underlying functionality. What I want to know is, why is Modeler's CS panel in General Options, not Display Options?

djwaterman
02-11-2016, 04:35 PM
I agree on that, see image.

132387

bobakabob
02-11-2016, 04:47 PM
So for linear could somebody kindly confirm what the settings in LW should be? :)

spherical
02-11-2016, 04:51 PM
Gaaahhhhhhhh!!!!! Linear what? Linear workflow using Linear input data. Linear workflow using sRGB input data? If the former, Disabled. If the latter sRGB.

djwaterman
02-11-2016, 06:23 PM
Use the sRGB preset in almost all cases, it is unusual to have linear inputs on your texture maps. The sRGB preset will leave any floating point (HDR) inputs at linear. The only thing you have to do is set any normal maps to linear.


If you want to work like in the 80's then don't use the preset and pump lots of light into the scene and beef up under-lit surfaces with luminosity, I'm joking of course but I still see people doing this so it's no joke really. Use the preset.

Surrealist.
02-11-2016, 08:25 PM
So for linear could somebody kindly confirm what the settings in LW should be? :)

This is what I am talking about. And this is exactly what I simply asked my friend to do. Just cut to the crap and tell me what the settings are.

Because the more I looked at the manual and the more I looked at the interface the more confused I was. And this is coming from someone who understands what the settings should be.

The problem is this.

"Convert to Colorspace to Linear" Even if you read it. Understand what it means. Applies only to the inputs that are set to any kind of choice that is gamma, of which sRGB is only but one.

The mistake is this naming. And then adding one of the choices to be Linear. Because there is no conversion happening if you set the input to Linear.

So this results in an interface that is giving you the feedback of everything saying Linear when it is not "Converting Colorspace to Linear"

Not sure why there should be so much contention over something to obviously wrong and misleading.

And sure if you dig in and finally understand it, yeah you can work with it.

A better title if you wanted to leave everything just as it is would be:

Select the Color Space of your input sources"

Or something to that effect.

Then you go down the list and do just that.

If you know your images are Linear then make that setting choice.

An even better set up would be the one described earlier.

Keep the title the same and simply add a Bollean check box to say yes convert to Linear and a heading to let you know that you are chosing which profile you have as far as Gama.

Linear is not needed as a setting, just as in other apps because you are not doing anything. Or in other words. It is off. That is why Maya and Renderman have boolean check boxes.

The preset is further misleading as it tells you sSRB. It should say something like "Convert sRGB to Linear"

lightscape
02-11-2016, 10:28 PM
Renderman assumes only sRGB when linearizing input images, which is only correct for sRGB images, but not for everything else. FP images are automatically assumed linear. If we want to change any of this, we need to use Maya color profile drop down - where - you also have Linear input space options for sRGB and Rec.709.

http://s10.postimg.org/dhqnevfa1/maya_CP.png

So linear IS an input option in Maya too (and in other 3d and compositing packages), and it's not misleading and it's indeed representative of what's happening in LW when we read what the parameter is doing: "Convert Color Space TO Linear". Then if it's Linear to Linear, nothing is going to happen. That clearly means, you are not correcting gamma and that's why that preset is called "Disabled". Guess the confusion comes when people don't read that sentence in the CS panel and think that "Linear" means "Linearized". In such case, an additional "Linearize space" checkbox is an option.

However, Linear colorspaces ARE real input options, and Linear IS a gamma space too, which means that the power of energy than enters is the same than the power of energy than exits.



Gerardo



Agree people should look at different appz and renderers.
The key point is to apply colorspace to stuff that goes into the 2d/3d package.
In lw its clear that you're applying srgb when you pick srgb preset.
In 3dmax you check gamma and put 2.2 so that's basically srgb, too. Which means linearizing inputs, materials, colorpickers like lw "srgb preset" . :D
In modo its exactly the same as lw but with more LUT options.
Understanding linear workflow comes from experience with other appz and renderers.
They should not change the setting in lw.

gerardstrada
02-12-2016, 05:42 AM
Well sure yeah I understand where you are coming from. I just don't agree from the point of view of an interface design. I think your thoughts are clear and informative. Just not appropriate for being sensitive to feedback on an interface from users.

I am a user. I am giving feedback. I understand the process. I looked in the manual, tried to understand the interface, searched the forums, google, everything. Even wound up talking to a friend and just asked him point blank what are the setting supposed to be.

That is the feedback. You might not agree it is valid for your own reasons.

Software designers can't make assumptions about what people are doing or have done or understand or don't understand based on only their level of expertise or the level they expect people to be at.

Software designers have to listen to feedback from users to find out their inclinations and expectations. And that is what drives interface design.

But feedback on design needs to come from users. Not engineers.

And I have already made my case as to why I feel the way I do and there is no point in repeating it. I feel what I have said stands on it own as valid feedback.

Notice I haven't disagreed with your interface design suggestions, I've said here (http://forums.newtek.com/showthread.php?149714-Maya-s-Linear-Color-Space-Management-vs-Lightwave-s&p=1465475&viewfull=1#post1465475): that's not a bad idea, here (http://forums.newtek.com/showthread.php?149714-Maya-s-Linear-Color-Space-Management-vs-Lightwave-s&p=1465610&viewfull=1#post1465610):it's an option and here (http://forums.newtek.com/showthread.php?149714-Maya-s-Linear-Color-Space-Management-vs-Lightwave-s&p=1465648&viewfull=1#post1465648): (they can) add an additional "Linearize colorspace" checkbox as you are suggesting.

But what's incorrect are the technical reasons you are addressing for grounding a change in the interface design. Because Linear IS a real valid gamma value and using Linear IS a valid space used in CM panels of 3D packages, renderers and compositors (either as Linear, Linear "Something", or Gamma 1.0) and in ALL of them, Linear or Gamma 1.0 to Linear means no colorspace correction.

Giving incorrect technical reasons about why the interface should be changed is not going to help, because if users show misconceptions about the technical structure of a subject, it delegitimizes their requests in detriment of them and probably other users. In such case is far better to circumscribe the fundamentals just in real reasons, even if these are not technical but rather perceptual. So for requesting interface changes, one don't need to mess with the structure of how tools work. You can just go with your perception about how you think the things can be presented better and get a valid feedback according to that.

So let's go to extremes and say I don't know ANYTHING about color management (CM), moreover, I don't wanna know. I just want this interface to guide me through the settings I need in the most possible intuitive way, even when I know CM is a very technical complex topic and bla, bla, bla. That's what I want. - Ok. That's a real reason from that point of view. It might have in the other side of spectrum people who need more capabilities, flexibility and automation.

Then, developers may design an interface that fulfill those requirements in a realistic way according to the current technology available and the correct operation of the tools, or approach an interfase that changes from basic (light) to advanced (heavy) settings, etc. This means developers INDEED need to know not only what people that know their stuff are doing, but also what users understand (to address any misconceptions in the manuals) and define according to that how to provide useful tools and documentation for their correct purpose and usage. CG work has two unavoidable aspects: the artistic and the technical one, and we can not choose to not take care about them. So is the responsibility of the user to get interested in both topics and a basis knowledge is always necessary.



So for linear could somebody kindly confirm what the settings in LW should be? :)
"to better suit work for the monitor, switch to sRGB."

Kindly,

the Manual http://forums.newtek.com/images/icons/icon7.png



Agree people should look at different appz and renderers.
The key point is to apply colorspace to stuff that goes into the 2d/3d package.
In lw its clear that you're applying srgb when you pick srgb preset.
In 3dmax you check gamma and put 2.2 so that's basically srgb, too. Which means linearizing inputs, materials, colorpickers like lw "srgb preset" . :D
In modo its exactly the same as lw but with more LUT options.
Understanding linear workflow comes from experience with other appz and renderers.
They should not change the setting in lw.

Understanding linear workflow comes first from investigating how real light behaves, how our eyes perceive light and color, how we reproduce it in different image mediums and how image devices handle color, then developing our own CM frameworks, workflows and pipelines. There is when you really know if a given app is implementing correctly or not its color management.

Anyway, there are several ideas to improve the CS panel interfase. Think also than an "input colors" sentence above the input colorspaces drop-down list is a viable idea too.



Gerardo

Surrealist.
02-12-2016, 10:16 AM
Notice I haven't disagreed with your interface design suggestions, I've said here (http://forums.newtek.com/showthread.php?149714-Maya-s-Linear-Color-Space-Management-vs-Lightwave-s&p=1465475&viewfull=1#post1465475): that's not a bad idea, here (http://forums.newtek.com/showthread.php?149714-Maya-s-Linear-Color-Space-Management-vs-Lightwave-s&p=1465610&viewfull=1#post1465610):it's an option and here (http://forums.newtek.com/showthread.php?149714-Maya-s-Linear-Color-Space-Management-vs-Lightwave-s&p=1465648&viewfull=1#post1465648): (they can) add an additional "Linearize colorspace" checkbox as you are suggesting.

But what's incorrect are the technical reasons you are addressing for grounding a change in the interface design. Because Linear IS a real valid gamma value and using Linear IS a valid space used in CM panels of 3D packages, renderers and compositors (either as Linear, Linear "Something", or Gamma 1.0) and in ALL of them, Linear or Gamma 1.0 to Linear means no colorspace correction.

Giving incorrect technical reasons about why the interface should be changed is not going to help, because if users show misconceptions about the technical structure of a subject, it delegitimizes their requests in detriment of them and probably other users. In such case is far better to circumscribe the fundamentals just in real reasons, even if these are not technical but rather perceptual. So for requesting interface changes, one don't need to mess with the structure of how tools work. You can just go with your perception about how you think the things can be presented better and get a valid feedback according to that.


That is exactly what I have done and I have not stated anything incorrect or technically wrong. You have only interpreted it that way.

And again in the same breath you are saying what I am saying. Here: "Linear means no color space correction"

That is exactly what I have been saying from the begging. When I said Linear was not a color space I meant it is not gamma color space in the sense we are talking about.

If you want to get down to the raw basics, sure it is all a color space. Great. So now what? We are still left with a clear division of terms. On the one side there is gamma correction and on the other side it is none. And for the intents and purposes of this conversation and the interface, not to mention Linear workflow, that is the most important division. And LighWave muttles this by putting Linear (on the wrong side of this important division) in the choices for color spaces in the 2.2 range that need correction. Because again. For Linear NO CORRECTION IS NEEDED.

And what is the title of the panel?

"Convert Color Space to Linear"

There is nothing technically wrong with saying that putting Linear in the choices of Gama 2.2 ish Color Space is misleading and confusing and also redundant. And that does not make one sound as if he does not know the subject. Quite the opposite. I know the subject well enough to break it down into the basics that most people need to know. And that is it. Does it need correction or not? That is really all you need to know. You don't need to be a CS export to see that.

So you don't need to put Linear in that list. It is just confusing the issue. And if anything it is far too technical than it needs to be.

Additionally no other apps I am aware of actually make you do this. For convert to Linear it is on or off. And thus none of the options are Linear. Because you don't need it. If Linear is on. Then you choose your input profile.

And that is all there is to it.

In LightWave on the other hand, going all the way back to one of my very first points on this has it set up so that the default (Dissabled) has all of the inputs as Linear.

That is just confusing as hell on first encounter. Even if you read the label. "Convert Color Space to Linear" And in fact even more so if you do. I read that. I thought immediately, great. All my inputs are set to convert to Linear. Wonderful. Great that the devs finally made this the default.

Then I want on my merry way. When my renders were coming out amiss I went back to look at this panel again. I looked at the presets. There was Dissabled, sRGB and a few others. Well, none of those look like what I want!

On to the manual. The Manual on this is poorly written. Now looking back at it of course I am able to interpret what they meant. On first encounter it was not clear. And they don't approach it from the point of view that this is totally different from anything else.

So then on to tutorials and google and from there just had to ask a friend.

Finally I found that video I posted. And there I got the first definitive answer. THAT should be hot the manual is written. Concise and clear and to the point as to actualy HOW YOU USE this pannel.

So then I was good to go.

But it was no fun going from the first encounter of that panel to finally, finally being able to use it correctly and with confidence.

That can and should be avoided.

spherical
02-12-2016, 05:19 PM
For me, it really seems best that the default, when LightWave is installed, should be sRGB; as that is where the vast majority of users are as far as CS workflow is concerned, whether they realize it or not. If that's where you want us to go, then show us that first. If someone knows CS and/or is in a specific field, and therefore is familiar with Rec.709 and Linear, they also know enough about what to choose apart from the provided default. Having "Disabled" as default (which usually means: applicable in most cases—you don't need to mess with this) is misleading. The question immediately pops into the user's mind: "Why should I deviate from the default as first presented by the software? They know more than I do, right?". And people end up using the wrong settings until they do learn, at least in part, what proper CM is and why. After that, the panel becomes clear. That clarity should come right outta the gate.

lightscape
02-12-2016, 09:53 PM
For me, it really seems best that the default, when LightWave is installed, should be sRGB; as that is where the vast majority of users are as far as CS workflow is concerned, whether they realize it or not.

It should be disabled by default which means no color management applied.
People who don't understand color management or using in lw 9,8, old stuff will load and render and see their scene all washed out if srgb was on by default in latest lw. They will be more confused why their scene looks ***** not knowing their old stuff is not set up for linear workflow.

Just watch Matts linear workflow video. Its super clear for lw users.

spherical
02-12-2016, 11:51 PM
Old stuff and not understanding the new stuff is.... old thinking. Accommodating and continuing to enable that small sub-set of circumstances is misdirected. Get over it. Learn how the new model works, along with everything else that is current in this imaging world. Where's my killfile?

lightscape
02-13-2016, 01:30 AM
Old stuff and not understanding the new stuff is.... old thinking. Accommodating and continuing to enable that small sub-set of circumstances is misdirected. Get over it. Learn how the new model works, along with everything else that is current in this imaging world. Where's my killfile?

Unfortunately there are many artists up to now who can't grasp linear workflow. That's fine, people were creating good work without linear workflow before. The younger artists understands it easily though. Old artists call it mumbo jumbo.

A common thing that happens is when artists TRY linear workflow without understanding and they render out their image sequences and import to a compositing package. They don't know how the image sequences should be saved and imported for comp.
They either burn in the srgb in the exr, which makes linear workflow less useful, OR they save the linear exr and import to fusion, etc and wonder why their images are dark or they get a plate with a completely different profile not match. Which add to the complication that they need to know how to use their comp package. You can't go with your gut feeling on this.

Surrealist.
02-13-2016, 01:31 AM
For me, it really seems best that the default, when LightWave is installed, should be sRGB; as that is where the vast majority of users are as far as CS workflow is concerned, whether they realize it or not. If that's where you want us to go, then show us that first. If someone knows CS and/or is in a specific field, and therefore is familiar with Rec.709 and Linear, they also know enough about what to choose apart from the provided default. Having "Disabled" as default (which usually means: applicable in most cases—you don't need to mess with this) is misleading. The question immediately pops into the user's mind: "Why should I deviate from the default as first presented by the software? They know more than I do, right?". And people end up using the wrong settings until they do learn, at least in part, what proper CM is and why. After that, the panel becomes clear. That clarity should come right outta the gate.

Actually I agree it should be the default as well. Up to the point that the person looks at the panel for the first time. In which case the confusion will happen in reverse. They will read "Convert Color Space to Linear" and then look down and see all of their inputs apparently set to sRGB.

Just take a step back and be objective now for a moment. Even knowing color space, and how to use it. With no other information, what is the provided information telling you?

Nothing. It is telling you that this is the panel where you convert your color space to Linear.

And below is a list of items. Next to them is a drop down list. The drop down list is set to display sRGB. (assuming the current settings and a proposed default of sRGB.)

Now up to this point nothing more is known. You don't know that this is actually an input.

Additionally you don't even know what the input is. Think about it. With no other information. You have to wipe your memory of having used this panel, all you know about color space and what you have been able to glean from the manual and other sources. And just look at this panel, objectively for the first time.

And you realize - I would hope - that the panel tells you nothing.

And god help you if you understand color space already... :D because it will be worse... lol

So what is the missing information?

1) What the list actually is: Your input sources.
2) That "convert... to Linear" relates to these inputs.

Solved by:

Changing the Title to "Convert Input Color Space to Linear"

And

A sub heading above the list:

"Input Sources"

Now if you did not understand Color Space fully you might have an issue or two at this point. In which case a trip to the manual or other readily available resources would clear this up.

If you understand color space already, an interface such as this does not have to send you to the manual to get the inside scoop.

This panel reads pretty much like a developers test interface where they are the only ones who know what this is.

Additionally there is the other issue of Linear as a choice in this panel. It should not be there.

This is the definition of the word Convert:

First definition:

1.
cause to change in form, character, or function.
"production processes that converted raw material into useful forms"
synonyms: change, turn, transform, metamorphose, transfigure, transmute

So this assumes that whatever is in that list, assuming you know these are color spaces of your inputs, will have an action performed on them. Conversion.

All fine up to the point that Linear is an option.

Here is the manual Page on this:


Since LightWave 10, LightWave has been able to use Color Space information to give better results, above all with images used for texturing . Color space conversion is performed in four places in LightWave .


1) On loading, an image can be converted from its native color space format to linear .

2) When sent to the Image Viewer, an image can be converted from linear to another color space .

3) When saved from the Renderer, an image can be converted from linear to another color space .

4) When picked from the Color Picker, a color can be converted from and then to linear color space .

By default, LightWave is set not to do any conversion - the Linear setting, but to better suit work for the monitor, switch to sRGB . For better work for cinema choose Cineon and for widescreen highdefinition TV choose Rec .709 . These choices will help convert images that may already have color space definitions and keep their colors pure .

LightWave provides presets for sRGB and rec .709 but a personalized mix can be set up with the dropdown choices for each of the different elements and saved as a preset for future use . You can also load in color space definitions to exactly match existing setups . A color table can be loaded by using Load Table from the pop-up . The color tables are stored in the project directory, in a directory called ColorTables .


The options are as follows:

Convert Color Space to Linear • Picked Colors - Colors chosen from the LightWave or other color picker
•Light Color - The color chosen for lights
•Palette Files - Palettes loaded into LightWave
•8-bit Files - 8-bit here refers to images that are 8 bits per channel such as JPGs, PNGs or TGAs, previously known as 24-bit or 32-bit . These benefit the most from color space conversion .
•Float files - Images using floating point colors schemes don’t benefit from color space conversion, indeed it would cause severe banding and thus this should always be left on Linear
•Alpha - Again, alpha images need to be preserved exactly as they are since the level of gray indicates distance . As such they don’t require or want color space conversion

Now this is all good information and very informative.

But what information is missing here?

1) A screen grab of the CS panel
2) Explanations as to what each section is.
3)And relating this to the options it is describing. Where they are. And explicitly how to set them

Without those bits of information, and even still going back and forth to the manual and the interface it is still rather confusing.

If there is not a Boolean check box to turn on and off converstion, then the Linear option should be changed to:

"No Conversion"

This way it stays more true to what is not happening and does not conflict directly with the interface itself which is telling you it is converting.

So you say, but yes, there can be Linear inputs. OK. So you understand color space and you know no conversion is happening, so you should be good to go.

That way even with no checkbox. You can have a default of do nothing and it all looks correct in the interface. Dissabled preset would display "No Conversion" rather than the confusing and milseading Linear.

At least this much change and the inteface changes I have proposed as well as a Manual that is far more clear, I think would be keeping the information and the interface in step with the strength of the design of the software here.

MichaelT
02-13-2016, 01:52 AM
I wonder if some of you are confusing what this is really about?

I think this will explain things quite well. Read it thoroughly or you'll be confused. (https://renderman.pixar.com/view/LinearWorkflow) (update: saw that Surrealist posted this link.. oh well ;) )

Also, old artist used to work in linear only. There was no thing like working in sRGB in the early 90s (it wasn't even invented then) :) Just saying.

gerardstrada
02-13-2016, 06:03 AM
That is exactly what I have done and I have not stated anything incorrect or technically wrong. You have only interpreted it that way.

And again in the same breath you are saying what I am saying. Here: "Linear means no color space correction"

That is exactly what I have been saying from the begging. When I said Linear was not a color space I meant it is not gamma color space in the sense we are talking about.

If you want to get down to the raw basics, sure it is all a color space. Great. So now what? We are still left with a clear division of terms. On the one side there is gamma correction and on the other side it is none. And for the intents and purposes of this conversation and the interface, not to mention Linear workflow, that is the most important division. And LighWave muttles this by putting Linear (on the wrong side of this important division) in the choices for color spaces in the 2.2 range that need correction. Because again. For Linear NO CORRECTION IS NEEDED.

And what is the title of the panel?

"Convert Color Space to Linear"

There is nothing technically wrong with saying that putting Linear in the choices of Gama 2.2 ish Color Space is misleading and confusing and also redundant. And that does not make one sound as if he does not know the subject. Quite the opposite. I know the subject well enough to break it down into the basics that most people need to know. And that is it. Does it need correction or not? That is really all you need to know. You don't need to be a CS export to see that.

So you don't need to put Linear in that list. It is just confusing the issue. And if anything it is far too technical than it needs to be.

Additionally no other apps I am aware of actually make you do this. For convert to Linear it is on or off. And thus none of the options are Linear. Because you don't need it. If Linear is on. Then you choose your input profile.

And that is all there is to it.

In LightWave on the other hand, going all the way back to one of my very first points on this has it set up so that the default (Dissabled) has all of the inputs as Linear.

That is just confusing as hell on first encounter. Even if you read the label. "Convert Color Space to Linear" And in fact even more so if you do. I read that. I thought immediately, great. All my inputs are set to convert to Linear. Wonderful. Great that the devs finally made this the default.

Then I want on my merry way. When my renders were coming out amiss I went back to look at this panel again. I looked at the presets. There was Dissabled, sRGB and a few others. Well, none of those look like what I want!

On to the manual. The Manual on this is poorly written. Now looking back at it of course I am able to interpret what they meant. On first encounter it was not clear. And they don't approach it from the point of view that this is totally different from anything else.

So then on to tutorials and google and from there just had to ask a friend.

Finally I found that video I posted. And there I got the first definitive answer. THAT should be hot the manual is written. Concise and clear and to the point as to actualy HOW YOU USE this pannel.

So then I was good to go.

But it was no fun going from the first encounter of that panel to finally, finally being able to use it correctly and with confidence.

That can and should be avoided.

This is an incorrect technical reason:

"And presently Linear is not a gamma space."

When it actually IS.

"It is not an option it is not a choice"

Linear is an option, because if input color is linear, Linear should be defined and yes, in the context of working in linear light, it means no correction. This happens in all CM packages (3d, 2D, compositing, etc) when the input space is the same than the output space. No app use "none" for the input gamma space, because if the resulting operation is no gamma correction, it's precisely because the input space is linear.

The only apps that don't use the linear space as input space option are the ones that, or are able to recognize automatically the embedded input space (which can be also linear), or the ones that assume just one single input non-linear space for everything (which is very limited). And in the first case, one is still able to assign custom profiles (including linear) and in the second case one is still able to set the gamma at 1.0 for linear images.

And again, the scenario where someone could get confused is overlooking the "Convert Color Space to Linear" sentence or not understanding it. That's why adding the "input" term to the sentence is a viable option too.

Maybe another option would be to add a an script running as a "wizard" helper that guides to the neophytes in this subject to have this LW basic setup properly set up.



Gerardo

p.d. Agree, Jarrod Davis video is spot on!

djwaterman
02-13-2016, 07:58 AM
You don't want sRGB to be the default, that would be a presumption of the software setting up what the artist is trying to achieve, sometimes it's not wanted or needed for the look they are going for, particularly non photo real styles. The artist should know why they need to use the sRGB preset and make that decision based on what they are trying to achieve. A beginner may not even have the means to post process their renders and be seemingly stuck with washed out images. The whole point of the sRGB color space preset is to output High dynamic range images that can be adjusted in post and that's not always needed.

Surrealist.
02-14-2016, 12:43 AM
This is an incorrect technical reason:

"And presently Linear is not a gamma space."

When it actually IS.

"It is not an option it is not a choice"

Linear is an option, because if input color is linear, Linear should be defined and yes, in the context of working in linear light, it means no correction. This happens in all CM packages (3d, 2D, compositing, etc) when the input space is the same than the output space. No app use "none" for the input gamma space, because if the resulting operation is no gamma correction, it's precisely because the input space is linear.

The only apps that don't use the linear space as input space option are the ones that, or are able to recognize automatically the embedded input space (which can be also linear), or the ones that assume just one single input non-linear space for everything (which is very limited). And in the first case, one is still able to assign custom profiles (including linear) and in the second case one is still able to set the gamma at 1.0 for linear images.

And again, the scenario where someone could get confused is overlooking the "Convert Color Space to Linear" sentence or not understanding it. That's why adding the "input" term to the sentence is a viable option too.

Maybe another option would be to add a an script running as a "wizard" helper that guides to the neophytes in this subject to have this LW basic setup properly set up.



Gerardo

p.d. Agree, Jarrod Davis video is spot on!


Actually no. What I say is technically correct, and you are even agreeing with me that it is. You have each time.

Your information about compositing apps is incomplete and misleading. It is not quite as simple as you are describing it. Additionally not all LightWave users even use a compositing application. So even if you have a Linear setting in Nuke for example on the input image, there is likely more things going on there. But even if for example it is "generally agreed to be OK" to use Linear as a redundant "do nothing setting" that does not make it technically correct. It just makes it accepted to think with - for Nuke users. And that is not the same thing as technically correct. And it comes particularly to light in LightWave. This flawed thinking raises its ugly head.

Now you can say. well Nuke is the king of the hill and if it has it like so and so, then it can't be bad for LW. OK fine. But that does not make it technically correct. Just widely - in that circle - accepted. Additionally it is not set up in an interface that breeds confusion.

That is of course assuming there is not in reality more to it. I am going to guess that there is. And that there is more than one profile you can set up in Nuke. In which case it would make sense to have Linear as an option there. I don 't use Nuuke. So it is not on my desktop to further investigate. In Fusion the Linear workflow is reportedly more convoluted. I have not set that up yet in Fusion either. So I can not comment. And I am not going to go through that just to make a point.

AE is however on my desktop.

In AE for example you set up a working color space. Linear is an option here. It is a Boolean check box. Just as it is in Renderman. If you do not set up a working color space you can not assign an input profile. And if you do, you can also disable color management for that item in the Interpret Footage dialog. As well as turn on "Interpret as Linear Light".

So it is not nearly as simple and straightforward as you are describing in order to make your point.

The technical correct point here is that it is redundant to choose Linear as an input profile in a system such as LightWave that natively will respect the Linear input as Linear without doing anything. And all 3D apps that I use are set up this way.

In the case of Renderman. If you know your footage/Image etc is Linear coming in. You leave that box unchecked. If you know you have a profile that needs conversion, you check the box that is clearly labled... "Linearize...."

If I am going to lean in any direction, I am going to lean in the direction of how other 3D apps are set up.

Because the the flaw in this assumed "technically correct reasoning" comes to light in how the LW interface is set up.

This results in unnecessary confusion.

And it could be corrected in any number of ways. And some of those I have proposed that allow the technically incorrect yet perhaps (I say only because I have not fully investigated yet) generally accepted - in some circles - linear option.

gerardstrada
02-14-2016, 04:25 AM
Also, old artist used to work in linear only. There was no thing like working in sRGB in the early 90s (it wasn't even invented then) :) Just saying.

On the contrary http://forums.newtek.com/images/icons/icon7.png old artists used to work in mixed non-linear spaces (sRGB, 2.2, 1.8, 2.5, 2.8 gammas, etc) because precisely there was no proper context for linarizations yet.



Actually no. What I say is technically correct, and you are even agreeing with me that it is. You have each time.

Your information about compositing apps is incomplete and misleading. It is not quite as simple as you are describing it. Additionally not all LightWave users even use a compositing application. So even if you have a Linear setting in Nuke for example on the input image, there is likely more things going on there. But even if for example it is "generally agreed to be OK" to use Linear as a redundant "do nothing setting" that does not make it technically correct. It just makes it accepted to think with - for Nuke users. And that is not the same thing as technically correct. And it comes particularly to light in LightWave. This flawed thinking raises its ugly head.

Now you can say. well Nuke is the king of the hill and if it has it like so and so, then it can't be bad for LW. OK fine. But that does not make it technically correct. Just widely - in that circle - accepted. Additionally it is not set up in an interface that breeds confusion.

That is of course assuming there is not in reality more to it. I am going to guess that there is. And that there is more than one profile you can set up in Nuke. In which case it would make sense to have Linear as an option there. I don 't use Nuuke. So it is not on my desktop to further investigate. In Fusion the Linear workflow is reportedly more convoluted. I have not set that up yet in Fusion either. So I can not comment. And I am not going to go through that just to make a point.

AE is however on my desktop.

In AE for example you set up a working color space. Linear is an option here. It is a Boolean check box. Just as it is in Renderman. If you do not set up a working color space you can not assign an input profile. And if you do, you can also disable color management for that item in the Interpret Footage dialog. As well as turn on "Interpret as Linear Light".

So it is not nearly as simple and straightforward as you are describing in order to make your point.

The technical correct point here is that it is redundant to choose Linear as an input profile in a system such as LightWave that natively will respect the Linear input as Linear without doing anything. And all 3D apps that I use are set up this way.

In the case of Renderman. If you know your footage/Image etc is Linear coming in. You leave that box unchecked. If you know you have a profile that needs conversion, you check the box that is clearly labled... "Linearize...."

If I am going to lean in any direction, I am going to lean in the direction of how other 3D apps are set up.

Because the the flaw in this assumed "technically correct reasoning" comes to light in how the LW interface is set up.

This results in unnecessary confusion.

And it could be corrected in any number of ways. And some of those I have proposed that allow the technically incorrect yet perhaps (I say only because I have not fully investigated yet) generally accepted - in some circles - linear option.

Again, it's not technically correct saying that "Linear is not a gamma space" and "It is not an option it is not a choice".

It's not my information about compositing apps, it's production-proven pipelines. And I'm not talking about Nuke only, but also about Fusion, Ae, PS, Maya, LW, Max, VRay, Modo, Mari, Blender, you name it. All have linear input as an option and it's correct not because major apps are implementing it (all they are a lot improvable and I've found mistakes in ALL of them) but because linear is indeed an input space as well. Our input colors can be linear, and again, in such case, linear should be set up.

But let's talk about the Ae case. You are confusing things there because the linear chekbox in AE is NOT AT ALL like in Renderman. First, in renderman the checkbox is for linearizing only a single input (source) space, just one. In Ae the checkbox is for Linearizing a working (target) space which can be ANY profile. Totally two different things.

Moreover, In Ae you can use an already Linear color profile and you don't need the "Linearize Working Space" chexbox, in fact when working according to AMPAS framework you should NOT use the linearize chexbox because that will overwrites your custom linear space according to ICC framework. So in Ae we can use a linear working space profile without using the checkbox.

When the thing is similar in Ae to what happens with input colors in 3D packages? when we assign the profiles of input images. THERE is the same scenario, and THERE we can indeed pick a Linear profile if the image is linear, and if both (input and working) are the same colorspace, no color conversion will be performed. Just like LW! Moreover, if the working space is non-linear, and you pick the same space as input space for an image in AE, no color conversion will be performed either.

So again, linear IT IS an input gamma space option. If the word "Linear" confuses you because you overlooked the CS panel sentence or because you didn't understand at first that those were input spaces, that's another topic that can be addressed. You can say, it's confusing for neophytes. Ok. But you can not say that's technically incorrect, because IT IS NOT. Again, this is a problem of user perception, not about technical incorrectness. CS panel has other technical incorrectness but this is not one.



Gerardo

bobakabob
02-14-2016, 01:04 PM
Gerardo, one purpose of a forum is to discuss issues that may not be entirely clear from the manual. In my case I was hoping to confirm recommended colour space settings for the best possible outcome, implicit in my question.

Rather than giving a supercilious response to any other LWers desirous of clarification there are some really helpful videos here:

http://youtu.be/9jM44iCCkEw

http://youtu.be/D2iDv9hnQiw

gerardstrada
02-14-2016, 06:05 PM
Gerardo, one purpose of a forum is to discuss issues that may not be entirely clear from the manual. In my case I was hoping to confirm recommended colour space settings for the best possible outcome, implicit in my question.

Rather than giving a supercilious response to any other LWers desirous of clarification there are some really helpful videos here:

http://youtu.be/9jM44iCCkEw

http://youtu.be/D2iDv9hnQiw

Pointing out what manual says it's not a supercilious response. Rather than discussing or asking how linear workflow works (which as you say, is one purpose of a forum), you have asked what the settings in LW should be. Without even provide info about your context of work. In such case, the most possible outcome implicit in your question is precisely what manual says:

"to better suit work for the monitor, switch to sRGB."

Just in case, the first part of the video you link confuses gamma with gamma correction in the graphics. Just noticed the second video does it too.



Gerardo

lightscape
02-14-2016, 06:41 PM
Also, old artist used to work in linear only. There was no thing like working in sRGB in the early 90s (it wasn't even invented then) :) Just saying.

Not to confuse people, when you say old artist work in linear, the "linear" does not mean linear workflow(LWF). They worked mixed non-linear as gerardo posted. People didn't linearize inputs or had corrected colorpickers, light values, etc back then. Still produced great work though.
As for when, Vray made it mainstream with off the shelf rendering that people can buy. Its not the first probably but its the most popular renderer people used and learned LWF.

MichaelT
02-15-2016, 12:06 AM
Not to confuse people, when you say old artist work in linear, the "linear" does not mean linear workflow(LWF). They worked mixed non-linear as gerardo posted. People didn't linearize inputs or had corrected colorpickers, light values, etc back then. Still produced great work though.
As for when, Vray made it mainstream with off the shelf rendering that people can buy. Its not the first probably but its the most popular renderer people used and learned LWF.

The only ones talking about gammas etc.. back then, where people who worked with printing (and we considered them talking mumbo jumbo) And as you mention, no corrections etc.. (at least not in this way) And lighting was a great issue, especially in the dark ranges (hence all the games with horrid blocks etc.. when anything at all was dark. We knew about color correction etc.. but there were no real tools for it (at least good ones) However, any corrections arose from a need to fix issues with images behaving "weirdly", not because of a common understanding as to why an image started "glowing" etc.. It was a real mess in general.

Surrealist.
02-15-2016, 11:30 PM
On the contrary http://forums.newtek.com/images/icons/icon7.png old artists used to work in mixed non-linear spaces (sRGB, 2.2, 1.8, 2.5, 2.8 gammas, etc) because precisely there was no proper context for linarizations yet.




Again, it's not technically correct saying that "Linear is not a gamma space" and "It is not an option it is not a choice".

It's not my information about compositing apps, it's production-proven pipelines. And I'm not talking about Nuke only, but also about Fusion, Ae, PS, Maya, LW, Max, VRay, Modo, Mari, Blender, you name it. All have linear input as an option and it's correct not because major apps are implementing it (all they are a lot improvable and I've found mistakes in ALL of them) but because linear is indeed an input space as well. Our input colors can be linear, and again, in such case, linear should be set up.

But let's talk about the Ae case. You are confusing things there because the linear chekbox in AE is NOT AT ALL like in Renderman. First, in renderman the checkbox is for linearizing only a single input (source) space, just one. In Ae the checkbox is for Linearizing a working (target) space which can be ANY profile. Totally two different things.

Moreover, In Ae you can use an already Linear color profile and you don't need the "Linearize Working Space" chexbox, in fact when working according to AMPAS framework you should NOT use the linearize chexbox because that will overwrites your custom linear space according to ICC framework. So in Ae we can use a linear working space profile without using the checkbox.

When the thing is similar in Ae to what happens with input colors in 3D packages? when we assign the profiles of input images. THERE is the same scenario, and THERE we can indeed pick a Linear profile if the image is linear, and if both (input and working) are the same colorspace, no color conversion will be performed. Just like LW! Moreover, if the working space is non-linear, and you pick the same space as input space for an image in AE, no color conversion will be performed either.

So again, linear IT IS an input gamma space option. If the word "Linear" confuses you because you overlooked the CS panel sentence or because you didn't understand at first that those were input spaces, that's another topic that can be addressed. You can say, it's confusing for neophytes. Ok. But you can not say that's technically incorrect, because IT IS NOT. Again, this is a problem of user perception, not about technical incorrectness. CS panel has other technical incorrectness but this is not one.



Gerardo

Again you are overlooking the most important thing. And that is the context within which this conversation is taking place. And the reasons for my initial comment you for some reason decided to pick up on and say was technically wrong. I don't have a problem with selecting Linear as an input color space. And it is not at all confusing to me. Never has been. Not by itself.

In Renderman you are not required to select Linear as an input color space. You add an attribute and use a checkbox to Linearize the incoming image in the case where you need it. If you don't you leave that alone and you are fine. This works. With doing just this alone. My images are properly converted and the renders come out fine. And it is perfectly clear what is happening. (if my images were Linear nothing is required because it is already treating the images as Linear by default which is, well the problem in the first place. ;))

But in all of the applications in which you are asked to select Linear, it is clear and not confusing as what you are doing. Because there is nothing really wrong with choosing Linear as a color space in a panel where you are only being asked to select what the color space of the image is.

Purely technically speaking, yes. I stand by that it does not even have to be an option. Because technically speaking, it doesn't. Since you could more aptly have the option of "Do nothing" and it would convey more realistically what is actually happening. Unless of course there are more options you have for Linear. But in this case, in LightWave, we don't.

And you are not correct in saying this is not a technical reason. You keep confusing that with technically acceptable. Which is just as non technical as saying sRGB is the same as gamma. People can get tripped up in that as well.

But again the most important thing here is the context of the panel in question which breeds confusion. The reason is not in the hands of the neophyte or the uninitiated. It is clearly in the hands of the devs for a poor interface design.

And the reason again is simply this:

"Convert Color Space to Linear"

This at the most basic level is what is wrong.

To be technically correct and more clear as to what is happening in this panel it could say:

"Input Color Spaces"

And that would be the most simple and concise way to solve the whole thing and make everyone happy.

I believe I mentioned this in one of my first posts.

Getting into an argument (that you can not win by the way) that what I say is technically wrong is a red hearing. It is not only technically correct it is technically purest. Which is even better. :)

But I would be completely fine with the generally accepted notion that you could chose "Linear" as an input color space. As long as the interface is clear that this is what your are doing. Which it is in all other apps.

I never would have had any question about that panel or any confusion if it had saide just that from the beginning. And it was only when I understood all I was doing with that panel is when it made any sense.

gerardstrada
02-17-2016, 11:53 AM
Again you are overlooking the most important thing. And that is the context within which this conversation is taking place. And the reasons for my initial comment you for some reason decided to pick up on and say was technically wrong. I don't have a problem with selecting Linear as an input color space. And it is not at all confusing to me. Never has been. Not by itself.

In Renderman you are not required to select Linear as an input color space. You add an attribute and use a checkbox to Linearize the incoming image in the case where you need it. If you don't you leave that alone and you are fine. This works. With doing just this alone. My images are properly converted and the renders come out fine. And it is perfectly clear what is happening. (if my images were Linear nothing is required because it is already treating the images as Linear by default which is, well the problem in the first place. ;))

But in all of the applications in which you are asked to select Linear, it is clear and not confusing as what you are doing. Because there is nothing really wrong with choosing Linear as a color space in a panel where you are only being asked to select what the color space of the image is.

Purely technically speaking, yes. I stand by that it does not even have to be an option. Because technically speaking, it doesn't. Since you could more aptly have the option of "Do nothing" and it would convey more realistically what is actually happening. Unless of course there are more options you have for Linear. But in this case, in LightWave, we don't.

And you are not correct in saying this is not a technical reason. You keep confusing that with technically acceptable. Which is just as non technical as saying sRGB is the same as gamma. People can get tripped up in that as well.

But again the most important thing here is the context of the panel in question which breeds confusion. The reason is not in the hands of the neophyte or the uninitiated. It is clearly in the hands of the devs for a poor interface design.

And the reason again is simply this:

"Convert Color Space to Linear"

This at the most basic level is what is wrong.

To be technically correct and more clear as to what is happening in this panel it could say:

"Input Color Spaces"

And that would be the most simple and concise way to solve the whole thing and make everyone happy.

I believe I mentioned this in one of my first posts.

Getting into an argument (that you can not win by the way) that what I say is technically wrong is a red hearing. It is not only technically correct it is technically purest. Which is even better. :)

But I would be completely fine with the generally accepted notion that you could chose "Linear" as an input color space. As long as the interface is clear that this is what your are doing. Which it is in all other apps.

I never would have had any question about that panel or any confusion if it had saide just that from the beginning. And it was only when I understood all I was doing with that panel is when it made any sense.

This is a discussion about technical facts, nothing more http://forums.newtek.com/images/icons/icon7.png and the fact is that once again, linear IS a gamma space (the power that enters is the same than the power that exists) and IT IS an option (if input space is linear, Linear should be selected as input space). If no conversion is performed in the context of LW CS panel (or any linearization in any other package for that matters) is precisely because both, the input and the working space are linear. This is even more transparent in the case of LW where it's clear (as stated before) that we deal at gamma (TRC) level only. So in LW context (or ANY other package) IT IS technically correct selecting Linear as input space when the working space is also linear.

Renderman lacks of linearizations for any other space different than sRGB, that's why you have a checkbox there. For everything else you need Maya color profile drop down.

You say "there is nothing really wrong with choosing Linear as a color space in a panel where you are only being asked to select what the color space of the image is" and that's precisely what happens in LW, you are being asked in that part of the panel to select what the input image space is, and not only images, but also about any input color. Then Linear is an option because the selection is performed precisely in a color management context, and that's technically correct.

The confusion doesn't come from selecting or not selecting Linear as input space, the confusion comes from people who overlooked or don't understood what the sentence "Convert Color Space to Linear" means. Just to clarify things up, converting an space to another implies two things: First that the given space is the source (because for converting "TO" you need a "FROM"). Second, the "TO" (the Linear space) is the target space. So you have clearly an input and an output. And all the type of colors listed there are input colors anyway.

"Do Nothing" would be an option in another context, but not in this one where you have a drop down list of colorspaces (we can even load tables, LUTs and ICC profiles there - this last one it's not correctly implemented and THAT IS INDEED one of the REAL technically incorrectness I was referring before). Then, what is there is not a list of conversion actions, it's a list of colorspaces where Linear IS a correct technical option, because linear is a real input space, like any other one.

Of course this is not a technical problem about Linear as input space (which is correct in CM context), it's a perception problem on how to make the things in the UI more understandable and clear for users not very familiarized with linear workflows. And the ideas shared here are all very plausible for improve the UI. I really like the idea about a "wizard" helper script, naming the list as Input Colors would help to clarify things as well. Probably, if the name of the Quick preset would be visible (which for the all Linear input spaces is named "Disabled") it would allow also to realize more clearly what's happening with the default preset.



Gerardo

Surrealist.
02-19-2016, 09:14 AM
This is a discussion about technical facts, nothing more http://forums.newtek.com/images/icons/icon7.png and the fact is that once again, linear IS a gamma space (the power that enters is the same than the power that exists) and IT IS an option (if input space is linear, Linear should be selected as input space). If no conversion is performed in the context of LW CS panel (or any linearization in any other package for that matters) is precisely because both, the input and the working space are linear. This is even more transparent in the case of LW where it's clear (as stated before) that we deal at gamma (TRC) level only. So in LW context (or ANY other package) IT IS technically correct selecting Linear as input space when the working space is also linear.


There is no such thing as a pure discussion about technical facts. Everything has a context. And there are a number different variables between apps as well.

Linear is a color space. But it is also being used to delineate (as in the manual and in the interface with "disabled" ) that LightWave is doing nothing with the input.

So same energy in and same energy out is just a fancy way of saying that the feature is disabled. (does not matter if that fancy phrase has truth in engineering behind it or not) And ALL INPUTS are treated as if that have a Linear source. And ALL INPUTS are having no action performed. Just as if LightWave had no CS option. And why Disabled is actually an apt name. But poorly named within the context of the interface design.

So again it is all about context. And in the context of this panel and the manual and what you have insisted is true - several times. It is equally correct to say "is doing nothing" "disabled" (as in the manual and preset) or any other description you care to give it.

There is no absolute here. It has to be taken within the context.

And this interface context breeds confusion for all of the reasons I have outlined already.

When you have a title that says "convert to Linear" Which is an ACTION phrase and all of the inputs show Linear, you have conflicting and confusing interface feedback right off the bat.

An assumption that people should read the manual it is not at all realistic to assume they will. And therefore not an apt defense when the interface design is poor.

An interface design should not breed unnecessary confusion.

As to the rest of my comments about other apps and your responses it can be summed up succinctly as this:

In the context of an interface that asks you to "Choose the color space of an image", Linear is appropriate. (even if internally it means do nothing or same in same out of whatever). It is the context.

And in the context of "Convert Color Space to Linear" , Linear is not appropriate. Because again purely technically speaking nothing is happening.

However as I said, if the interface heading reads:

"Choose Input Color spaces" it make all the difference.

That the devs missed this little, however all important point of context, is kind of odd. And it is no wonder people get tripped up.

gerardstrada
02-19-2016, 07:47 PM
There is no such thing as a pure discussion about technical facts. Everything has a context. And there are a number different variables between apps as well.

Linear is a color space. But it is also being used to delineate (as in the manual and in the interface with "disabled" ) that LightWave is doing nothing with the input.

So same energy in and same energy out is just a fancy way of saying that the feature is disabled. (does not matter if that fancy phrase has truth in engineering behind it or not) And ALL INPUTS are treated as if that have a Linear source. And ALL INPUTS are having no action performed. Just as if LightWave had no CS option. And why Disabled is actually an apt name. But poorly named within the context of the interface design.

So again it is all about context. And in the context of this panel and the manual and what you have insisted is true - several times. It is equally correct to say "is doing nothing" "disabled" (as in the manual and preset) or any other description you care to give it.

There is no absolute here. It has to be taken within the context.

And this interface context breeds confusion for all of the reasons I have outlined already.

When you have a title that says "convert to Linear" Which is an ACTION phrase and all of the inputs show Linear, you have conflicting and confusing interface feedback right off the bat.

An assumption that people should read the manual it is not at all realistic to assume they will. And therefore not an apt defense when the interface design is poor.

An interface design should not breed unnecessary confusion.

As to the rest of my comments about other apps and your responses it can be summed up succinctly as this:

In the context of an interface that asks you to "Choose the color space of an image", Linear is appropriate. (even if internally it means do nothing or same in same out of whatever). It is the context.

And in the context of "Convert Color Space to Linear" , Linear is not appropriate. Because again purely technically speaking nothing is happening.

However as I said, if the interface heading reads:

"Choose Input Color spaces" it make all the difference.

That the devs missed this little, however all important point of context, is kind of odd. And it is no wonder people get tripped up.

Yes, everything has a context. And the technical facts discussed in my previous post are precisely in concordance with the basic LW's linear workflow context. "Do Nothing" as you suggested can not be used as input space because that's an action description, not a colorspace description. "None" can not be used either as input in LW context for the technical reasons I'm gonna explain later on.

Finally you recognize that Linear is a color space. It's more properly a gamma space in LW CS panel context, since its work scope is limited to deal with TRC only, but seeing that LW assumes that the color definitions are in hands of the user, the term "color" space can be still valid.

You just have said: "However as I said, if the interface heading reads: "Choose Input Color spaces" it make all the difference." Which means that if that sentence would be added, CS panel would be fine, and I agree because those spaces are precisely input colors! which means that what LW is doing internally IS technically correct. But since that phrase is missed, people not familiarized with linearizations get lost. Which, once again, means that this is not a problem of technical incorrectness but a perceptual problem that can be solved by adding more explanatory descriptions in the UI.

Now let's talk about the technical context with more detail and why Linear input is technically correct in LW CS panel context. To manage "something" we need an asset to be managed. In color management these assets are color descriptions. In LW context, the CS panel manages only one aspect of all possible color descriptions, this aspect is tone reproduction (Linear gamma, sRGB curve, Rec.709 curve, Cineon curve and any other curve defined in a table). In this context, LW assumes that all other color definitions are in hands of the user. In hands of the user means that all other aspects of color definitions are managed and introduced by the user's input colors. Because remember, LW only manages the gamma/curve aspect, nothing more.

Then, is in this context that LW performs the linearization operation. For this, we need a source space description and a target space description to be managed. This means that at least one color space description is necessary to properly define color. In a linearization operation, the target space is known (Linear), but remember, LW only handles curves, not all other color definitions necessary to describe color and at least one source of color definitions are needed, because we can not get something from nothing.

Since LW's Linear target space can not describe all the necessary color definitions, that is to say, it can not provide a complete meaning for the colorspaces, the color definitions relapse on the input colors in LW context. And in this context (and read this slowly and carefully), Linear is not the same than None. None means nothing, empty, not at all. If LW would REALLY implement a "none" option as input space (and I mean a technically correct "none" input option) results would be different than assigning Linear in a CM context. Since there's no color definitions, any image set up as "none" input color could NOT be displayed properly, with or without display management. It would be always obscure, dark and dull. Because it has no color definition, it's out of color management paradigm. Would be NOT even considered "linear", so it couldn't be later corrected for preview. It's nothing.

This would be worst than having linearization disabled, or not having a CS panel. And this is the reason why no color conversion is made when precisely the source and target spaces are equal (Linear in LW case), and why defining input linear colors in LW (if they are really linear) is technically correct, and why saying otherwise is technically incorrect in LW context.

Of course LW could rename the Linear input as None, but it wouldn't be really "none". And that would be REALLY technically incorrect and not a transparent representation of what's really happening behind the scenes.

Again, this why saying that "purely technically speaking nothing is happening" is also technically incorrect, because something is INDEED happening when input and output colorspaces are the same. No conversion in color management means "something". In linearizations, it defines that the input space is indeed Linear, and that's useful for defining later on how to manage this source of color. Because again, linear is a valid input space, also in LW context.



Gerardo

Surrealist.
02-20-2016, 02:25 AM
All I can say at this point is that you are really going out of your way to fit a square peg in a round hole with what is in fact very abstract reasoning.

Doing nothing is in fact doing something...lol

What are you smoking?

Funny to hear from someone who seems so well educated. If you really think that everything you just said is logic. Then there is nothing I can say to dissuade you.

I'll just stand by what I have pointed out thus far in all of my posts and leave my response as that.

But I will add that you are making a grave error in your assumption that anyone "truly" familiar with color spaces would not be confused with this panel.

Unless thinking in a purely abstract manor is something that comes that that territory. But I doubt it. It sounds more like a programmer or engineer. And again how this interface reads. Like something some programmers cooked up just to have an interface that worked for them in testing. But never bothered to actually refine it for even the well educated user much less the common user.

And thus the interface remains an enigma.

I am more than just a common user. I am a fairly well educated LightWave user and fairly familiar with other CS workflows. I would not call my self an expert. But I'd say I represent the average 3D Package user in my knowledge of this coming in.

So that needs to be taken into account as feedback.

It can not be just swept off as "well you were not well enough educated in CSM..."

Sorry. Nope. That does not fly at all. In fact that notion is more of an arrogant elitist response.

I am not saying this about you as a person as I don't know you. But as a response and a solution to a problem such as this it is not appropriate.

gerardstrada
02-20-2016, 02:57 AM
Nope. this is funny to hear for someone who SEEMED so well educated:

"What are you smoking?" :D

Again, for me this is just a discussion about technical facts, nothing more http://forums.newtek.com/images/icons/icon7.png

In any linear CM context, doing no conversion doesn't mean doing nothing, because in a CM context you need to define input spaces in order the system knows how to handle the color data. If at the end no conversion is performed, is precisley because the input and the working space are the same, and the system needs to know that they are the same. How? well we need to specify the input space. And again, if the input space is linear. Linear should be selected.

Using "none" as input space is not an option if you want to color manage that input color because that would leave the color definition of the input space precisely undefined, not considered, empty for the color management context. This is what already happens in raw developers. When we not specify input chromaticities, nor working space definitions, we get an oscure image that can not be properly displayed. It's always dark because it's not even considered linear. CM is OFF for that image. And this is a technical fact in LW context too.

Notice I'm not disagreeing with your suggestions about improvements in the UI are necessary for making it more understandable for people not familiarized with how linear workflows really works. But addressing incorrect technical reasons is not going to help to change this in the correct way. This is a perceptual issue, not a problem about technical incorrectness. The UI needs improvements, yes, but these need to be done in such way it can be understandable and ALSO technically correct. And that's the challenge.



Gerardo

spherical
02-20-2016, 03:26 AM
Funny to hear from someone who seems so well educated.
<snippage>
Sorry. Nope. That does not fly at all. In fact that notion is more of an arrogant elitist response.

WOW. Perhaps one might take a step back and reconsider one's position and attitude. After reading this discourse (which I have thoroughly enjoyed, BTW, as I always learn many things from Gerardo) there seems to be one person here who protests too much. Essentially consider this:

If you can keep your head when all about you are losing theirs, perhaps you've misunderstood the situation.

There are concepts on both sides of this discussion that are absolutely correct in their own (I hesitate to use the word, as it has been so overused).... context.

Would the panel benefit from refinement? Yes.
Is the LightWave CS workflow broken? Not really, as far as it goes.
Could the CS panel be better designed so as to be less ambiguous? Yes.
Does the LightWave CS workflow go as far as it should/could? No.
Should it go farther? Couldn't hurt.
Is there room for improvement? No doubt. There most always is.

How about giving it a rest?

Surrealist.
02-20-2016, 05:13 AM
Again, in the Manual is states the default is Disabled and that LightWave the same as doing nothing. I said that before. I said it many times. And the manual agrees with that.

That is what it says. And it is not only technical correct but it is accurate as to what is happening, or rather not happening. And again the default is "disabled"

But when you use the default "disabled" the interface lights up with Linear. And the interface Says "Convert... to Linear"

There is no other explanation

Where I come from words mean what they mean especially in a technical context. Disabled by definition means disconnected or rather turned off. It does not carry with it some other abstract meaning. "do nothing" Does not have some other hidden meaning that is abstract. Both are stated in the interface and in the manual.

And if the argument is that this is merely about technical facts. Then fine. This is also my position. But also within a context. As it is now the interface asks you to make an abstract connection of these facts completely out of context.

That has been my position from the beginning.

And saying this is not technically correct goes directly against what the manual says. There is nothing non-technical about my position. And I will say again. Nothing but a red hearing and should be dropped.

My proposal to leave the inputs as Linear makes everyone happy.

And all that would need to change to have it work as it is with the minimal change to the interface.

Rather than saying "convert to"

It only needs to say something to the effect of "Choose Input Color Space"

That is my feedback and critique. Along with a proposal (of many I am sure are possible) for an improvement.

gerardstrada
02-20-2016, 03:55 PM
Spherical, Totally agree with your questions and answers!



Surrealist, The manual is correct when it says that "Disabled" preset does not do any conversion. That's out of discussion. The last discussion was because you proposed to change the name of the Linear input space to "Do Nothing" which is incorrect because it describes an action in a profiles list, or "None" which is also technically incorrect because it leaves a given image outside of the color management context. Which means this given image could not be even corrected for display later.

About this last case (the "None" concept), let's use an analogy to make it more understandable: A client like or not like your work. But for liking it or not liking it, they need to know your work and evaluate it. If they don't know your work they can not say if they like it or not. It just doesn't exist for them. In the same way, the CS panel linearizes or not linearizes an input color, but to know if it linearizes it or not, it needs to know what input colorspace is this. If it's non-linear, it linearizes it, if it's linear, it doesn't. But the input color needs to be defined (known by the system) in order to be "evaluated". And that's means that "something" is really going on even when no conversion is being performed and apparently "nothing is happening". Using "none" is not letting the system knows which colorspace is this, and therefore, it won't handle it. It just doesn't exist in the CM context and it won't be taken correctly into account later for display corrections.

Gladly, you are not insisting with these ideas anymore. Your idea about adding the sentence "Choose Input Color Space" sounds very good and it's in concordance with what's happening behind the scenes and IT IS technically correct and perceptually clarifying as well. But perhaps it would better (rather than change it instead) to use it additionally with a "Convert Input Color Space to Linear" sentence in order the users can know also what's happening with the input space they are choosing. Additionally, the quick presets names can be visible, so users can more clearly see what a given setup is for.



Gerardo

Surrealist.
02-21-2016, 12:45 AM
lol I have not wavered from my position at all. I only proposed a reasonable change to the interface.

You keep harping on this red herring. For an interface, none, do nothing, etc are all as equally technically valid as a Boolean.

Going back to why I said Linear is "Not a Color Space" I honestly was not thinking that through in the purest sense. What I meant was it is not a color space that needs correcting.

In LightWave there are a set number of options. Linear (or do no conversion) is one of them. That could be accomplished with a Boolean. And it does not need to be in the drop down for inputs. And not having it there is not an issue of technical correctness. It does not even matter.

This is all about context and language. And we don't get ourselves hung up over what the code is. Sure under it all there is a code that is always doing something. But we don't need to see it. And we can live with an interface that gets us working with the application. That is the whole point of an interface.

And the manual is not out of discussion. It tells you exactly what I have been saying from the beginning. I know that what I have said may have been interpreted as something else. (or even I have not been careful enough to word it in such a way that someone would not latch on to it) But what else is new? This is the internet.

The manual backs up exactly what I mean which was that there is no conversion happening or needed. Thus Disabled.

But this hard fact, absolutely correct technical truth. Backed up my the manual is not conveyed in the interface.

And there are any number of solutions available, including keeping Linear as an option, as long as the interface is worded so that it is clear to the user on first go.

gerardstrada
02-21-2016, 01:12 AM
In linearizations, yes, linear doesn't need to be corrected, but it doesn't mean linear is not a colorspace, because again, "Do nothing" or "None" are not technically correct options in this CM context for the reasons explained before.

Boolean is also an option, but only if implemented correctly. Remember, the interface needs to be not only understandable and as intuitive as possible, but it should be also technically correct and transparent about what's really happening.

Manual is correct when it says that "Disabled" preset does not do any conversion, but that's different than saying that "nothing is happening", and it's not a license to use "None" as input space, because again, in order to not do any linearization, input colors should be defined (including linear) and that's "something" in CM context.



Gerardo

Surrealist.
02-21-2016, 01:41 AM
Well like I said it is all about context. If you have a title that asks "Convert Color Spaces to Linear "Do nothing" is just as appropriate as a Boolean. I am not even seriously suggesting that and I never have, seriously. It was just to illustrate the point. I think there are other better options.

For "None" To be appropriate the interface would have to ask something like. "Gamma Correction to Linear" In which case there is no gamma correction, this would be appropriate. And it is not the best choice for the current interface but it would be more correct than Linear.

You don't have to have everything say Linear just for the sake of some technical correctness.

Unless the interface is asking you specifically what the color space is. I think, depending on the interface, people are going to know what is happening and it does not need to explicitly state it. But that is a case by case basis. And in the case of the wording of this interface, as I said, anything else would be better. But again, I was just using that in an illustrative fashion.

There are many ways to skin a cat.

And so like I keep saying, this whole thing about technical correctness is a red hearing. A color space management interface only has to mention Linear when it is appropriate.

And the output options are a perfect example.

Or changing the title to read something that makes it make sense to have Linear in the list.

As the interface is now, anything other than Linear would be better and more technically correct. Because the interface is just contradicting itself. And it is in that context that I have made those suggestions.

gerardstrada
02-21-2016, 04:17 AM
Nope. It's not the same than the boolean case by depending on where and how you use the boolean in the CS panel context, but I'll explain that later on.

For an interface, "none" or "do nothing" are not technically correct in the way you proposed. Because "Do nothing" is not appropriate if it goes in an input colorspace list. Because "Do Nothing" is an action, not a colorspace (two different contexts). Well, you say that that was not a serious suggestion and I agree (it can't be serious). For "None" (and same as "do nothing") it should not be in a colorspace list, because input spaces need to be defined in ANY CM context.

In the linearization case, no conversion is performed precisely when all input spaces are linear. And if a list of input colorspaces are shown, they should show Linear, because that's precisely what's happening behind the scenes, and remember, UI needs to be easily understandable but ALSO transparently correct. This is a main criteria.

So let's talk about boolean. Let's say you put a boolean to a "Convert Color Spaces to Linear" option or to a "Gamma Correction to Linear" option as you say (which is different context than previous "Do Nothing" and "None" for the already mentioned reasons). You would need yet to define input spaces when the boolean is disabled for these input spaces. And which would be these default input spaces? Well, Linear. And we are again with the same Linear input spaces list besides the fact of adding an additional click. Could be even more confusing for neophytes in linear workflow.

Another option (that could be a smaller compromise than all your other boolean ideas) would be if the boolean is not in the linearization action, nor in the input colorspace list, but rather in the preset "Disabled", but ONLY when this preset is selected. In order it works properly, the interface should show that ALL colorspaces as Linear (because this is what it's technically correct), but they would be grey out just in order the user can do nothing yet. The key difference is that ALL colorspaces should be grey out, not only the input spaces but ALL of them. In order to make all colorspaces list active, the user would be obligated to change to any other preset. A "Custom" preset should added besides the ones already there in order the users can freely customize their setup and this preset should be able to pick Linear for all spaces without greying out the drop down lists. That would probably be best compromise you could get. It also adds an additional click, but the users would have at least the option to pick another preset different than "Custom" as an immediate first choice and in such case, wouldn't be an additional click for them.

Once again, in an input spaces list, in a linearization context, Linear is obviously an appropriate and technically correct space and saying otherwise it's what's incorrect. But it seems, the problem for people that overlooked the sentence "Convert Color Spaces to Linear" or for people who don't understand it, is that they think the Linear spaces are the result of a conversion and not the definitions of the input spaces (even when those are clearly input colors). So adding the "Select Input Color Space" besides a ""Convert Input Color Space to Linear" and making the quick presets names visible as mentioned before, should do the trick too, and would be less clicks to set up the same thing.



Gerardo

Surrealist.
02-21-2016, 05:59 AM
I never said put "do nothing" or anything of the sort into an input field that is asking you for a color space.

You are the one saying that. Not me. You may have thought that is what I mean. But it isn't.

I may have stated that you don't need Linear as an input choice. And yeah you don't really. It is not a hard fast requirement. Boolean is off and it is treating it as Linear. Done.

I have only stated that if the interface says, "Convert to Linear" it would be appropriate. Because that is in fact logical and technically correct.

However that is not how the CSM is designed in LightWave. So since it is in fact wanting (not asking or stating but rather needing) a color space input, then the most simple thing to do would be to change the wording so that it is.

And this is precisely what is wrong with the interface deign. It does not follow a clear and logical wording that represents what it is doing.

There are any number of ways it could be designed. A Boolean would work. Since it is a given that LightWave is in Linear space you could just as easily have an input choice that said no conversion. There are a multitude of options that would get the job done.

And all these examples within the context of what they are intended are technically correct.

It is all about the context. Really.

But now you can go on and keep putting things I say out of context, and I am down with repeating myself.

Care to have another go?

gerardstrada
02-21-2016, 06:13 PM
|
I never said put "do nothing" or anything of the sort into an input field that is asking you for a color space.

You are the one saying that. Not me. You may have thought that is what I mean. But it isn't.

(!) No. You said that here (http://forums.newtek.com/showthread.php?149714-Maya-s-Linear-Color-Space-Management-vs-Lightwave-s&p=1465885&viewfull=1#post1465885):

"If there is not a Boolean check box to turn on and off converstion, then the Linear option should be changed to: "No Conversion""

(the bold was added by me)

The only linear option in the panel to be chosen is input Linear colorspaces.

Immediately after that you said:

"This way it stays more true to what is not happening and does not conflict directly with the interface itself which is telling you it is converting.
So you say, but yes, there can be Linear inputs. OK. So you understand color space and you know no conversion is happening, so you should be good to go."

Again, you were referring about Linear inputs. And immediately after that you said:

"That way even with no checkbox. You can have a default of do nothing and it all looks correct in the interface. Dissabled preset would display "No Conversion" rather than the confusing and milseading Linear.""

(the bold was added by me)

Which is the only Linear displayed? the ones in the input profiles. So yes, you have been talking about the input colors.

Other example here (http://forums.newtek.com/showthread.php?149714-Maya-s-Linear-Color-Space-Management-vs-Lightwave-s&p=1466079&viewfull=1#post1466079):

You said about the Linear inputs and why Linear was not a real space:

"Purely technically speaking, yes. I stand by that it does not even have to be an option. Because technically speaking, it doesn't. Since you could more aptly have the option of "Do nothing" and it would convey more realistically what is actually happening. Unless of course there are more options you have for Linear. But in this case, in LightWave, we don't"

(the bold was added by me)

Again, those options we have for Linear are the input colors, and you say it's more "aptly" to have the option of "Do Nothing".

But if you are saying now that you didn't say that, well, that's up to you. But don't put words that I haven't said.


I may have stated that you don't need Linear as an input choice. And yeah you don't really. It is not a hard fast requirement. Boolean is off and it is treating it as Linear. Done.

Again, you are referring here about Linear as input space (just in your last post!). And what you have just said is technically incorrect again. You are saying that you don't need linear as an input choice. Linear IS an input choice in order the CM panel can be technically correct, because linear SHOULD be selected if the input space is actually Linear and in order the panel can be transparent to users about what's really happening. So IT IS a requirement in this context because that's precisely the way the system can determined that no conversion is performed. The only reason why a general boolean (affecting all spaces, not only the input ones) could be a compromise (because it's not totally correct) is just in order neophytes don't get confused. But it shouldn't be necessary once they know what's really happening.


I have only stated that if the interface says, "Convert to Linear" it would be appropriate. Because that is in fact logical and technically correct.

Actually, "Convert Input Color Space To Linear" is correct because that's precisely what's CS panel is doing.


However that is not how the CSM is designed in LightWave. So since it is in fact wanting (not asking or stating but rather needing) a color space input, then the most simple thing to do would be to change the wording so that it is.

Again, in ANY CM context, the system needs input colorspaces to be specified to know how to handle conversions.


And this is precisely what is wrong with the interface deign. It does not follow a clear and logical wording that represents what it is doing.

"Convert Colorspace to Linear" states what it is doing. All the listed type of colors there are input colors (picked colors, images, lights, palettes, etc). The sentence that is lacking so that it can be more understandable is that those are input spaces. Well, people who know the basics of a color conversion know already that those are input colors.


There are any number of ways it could be designed. A Boolean would work. Since it is a given that LightWave is in Linear space you could just as easily have an input choice that said no conversion. There are a multitude of options that would get the job done.

You are talking in circles. A boolean with a "No Conversion" term IS NOT technically correct in the context of an input space choice because ONCE again, it's not a list of actions, but a list of colorspaces and it would leave a given input color outside of the color management context. Which means this given image could not be even corrected for display later. I've already explained that here (http://forums.newtek.com/showthread.php?149714-Maya-s-Linear-Color-Space-Management-vs-Lightwave-s&p=1466515&viewfull=1#post1466515). Please, pay more attention.


And all these examples within the context of what they are intended are technically correct.

Sorry, but not all they are.


It is all about the context. Really.

Yes! REALLY!



But now you can go on and keep putting things I say out of context, and I am down with repeating myself.

Again, re-read what you wrote, and even more useful, also what I've written.



Gerardo

Surrealist.
02-21-2016, 07:38 PM
Well, now how about read what I actually did say. ;)

Did you actually read this?

"I never said put "do nothing" or anything of the sort into an input field that is asking you for a color space."

You are confusing the way the LightWave CSM works and what the interface is asking for. Not what it wants and not how it functions.

The interface does not say as it does in some other apps, "What is the input color space?"

From the places I learned English "Convert Color Space To Linear" is not asking anything. It is telling you to do something. And where I learned English, disabled means disconnected and turned off. And do nothing means that and only that. Do nothing.

So again it is all about context. If the manual is telling you the default is disabled which means do nothing, then that is pretty clear. Nothing is happening when all of the inputs say Linear. Meaning that yes a code is running, "doing something" but there is no conversion happening.

So in the context of the technical correctness of the manual and what it says, Do nothing, Off, anything you care to say, is correct.

If and only if the interface is not specifically asking you for a color space. Which it isn't currently.

Now read what I said carefully "asking for", as in posing a question or asking for a response, literally. As in "choose input color space"

And as the interface functions now, it could go either way. If it is good enough for the manual it is good enough for the interface. And they have even named the default, "Disabled".

However, if the interface was worded differently Linear would be appropriate. But as it is now, it isn't.

And that is all I have been illustrating from the beginning. And no none of it has been technically incorrect. It has been keeping right with the manual. But to illustrate this I have said all kinds of things, just to bring the concept to light. Within the context of what I said and more importantly what I was trying to clarify, I have kept exactly with what the manual states.

You have put other context to my meaning and intention from the beginning.

But I am sure this is not the end.

Because after all all I have done here is say the same thing again. Yet another way.

I can keep going

Another round?

gerardstrada
02-21-2016, 08:48 PM
Well, now how about read what I actually did say. ;)

Did you actually read this?

"I never said put "do nothing" or anything of the sort into an input field that is asking you for a color space."

Actually yes, in all references I posted here in my previous post:

"the Linear option should be changed to: "No Conversion""

The only Linear option there is the input space.

"Dissabled preset would display "No Conversion" rather than the confusing and milseading Linear.""

Again, the only Linear options in the "Disabled" preset is the input spaces.

"it does not even have to be an option"

When you were ferring to Linear gamma as "not even a gamma space"

"you don't need Linear as an input choice"

when talking about the boolean idea. And this is just recent.


The interface does not say as it does in some other apps, "What is the input color space?"
From the places I learned English "Convert Color Space To Linear" is not asking anything. It is telling you to do something.

Yes, but it doesn't mean that the options there are not input colorspaces. What's is saying there is that those are Clorspaces not actions. And any person with a minimum of knowledge about a color conversion know that images, picked colors, lights, palettes files, etc are input colors in a linearization context. And the interface tells you what's happening with those colors: Convert Colorspace To Linear. That's the action that's being performed with those input colors. A "Select Input Colorspace" will help to make it even more understandable for neophytes or people who overlooked the sentence, of course.


And where I learned English, disabled means disconnected and turned off. And do nothing means that and only that. Do nothing.

Btw, where you learned English? because again, this is precisely about CONTEXT, and in this context, Disabled means No linearization. Which is different than "Do Nothing".


So again it is all about context. If the manual is telling you the default is disabled which means do nothing, then that is pretty clear. Nothing is happening when all of the inputs say Linear. Meaning that yes a code is running, "doing something" but there is no conversion happening.

Again, you are losing the context. In this context Disabled means No Conversion which is different than "Nothing is happening" because in order no linearization takes place, the system needs to know which is the input space, and this will define later how to manage this color. So no conversion doesn't mean that "nothing is happening" and this is the reason WHY input spaces (including linear) need to be defined.


So in the context of the technical correctness of the manual and what it says, Do nothing, Off, anything you care to say, is correct.

Again, you are putting words in the "manual's mouth" that it also doesn't say. The manual is correct not because it says that the Disabled preset is "doing nothing" (because it doesn't say that), it is correct because it's SPECIFIC in saying that LW is not doing "any conversion", which as explained before (sooo many times) is different than doing nothing".


If and only if the interface is not specifically asking you for a color space. Which it isn't currently.
Now read what I said carefully "asking for", as in posing a question or asking for a response, literally. As in "choose input color space"
And as the interface functions now, it could go either way. If it is good enough for the manual it is good enough for the interface. And they have even named the default, "Disabled".
However, if the interface was worded differently Linear would be appropriate. But as it is now, it isn't.

It is appropriate because even when it's not explicitly defined, the sentence "Convert Colorspace to Linear" means that those are precisely Colorspaces, NOT actions. How one can think that Linear, sRGB or Cineon are an actions??? you need to be very lost either in attention or knowledge.


And that is all I have been illustrating from the beginning. And no none of it has been technically incorrect. It has been keeping right with the manual. But to illustrate this I have said all kinds of things, just to bring the concept to light. Within the context of what I said and more importantly what I was trying to clarify, I have kept exactly with what the manual states.
You have put other context to my meaning and intention from the beginning.

I haven't put anything in other context, but in-context. If you are now saying that you didn't say it, have you thought for a minute that you haven't explain yourself well? You are recognizing that you have said "all kind of things" and when one says "all kind of things" inappropriate terms are commonly used. Again, the manual doesn't say "Do Nothing" as you say (which is incorrect), The manual says No Conversion. Which is different. Just in case, RTMF (read the manual first):

"By default, LightWave is set not to do any conversion - the Linear setting"

the bold was added by me.



Gerardo

lightscape
02-21-2016, 09:15 PM
Wow so much confusion.

Disabled means no linearization or no conversion. as in like lightwave 9 and below.
It is the same in other appz. You pick srgb, etc, if you want to, but disabled is default or no conversion is being done.

I think its not known to some peeps that the renderer itself is linear even lightwave 9 and below, but the stuff we put in was not linearized. So to linearize everything, you need to convert stuff, and that became known as linearworkflow(LWF).
More confusing? :D

Surrealist.
02-21-2016, 09:51 PM
Well if you are going to quote me at least put it in the proper context.


I think the interface could be rearranged to be less confusing.

Something like this would be clear as day:

SOURCE TYPE_________SOURCE COLOR SPACE________CONVERT TO LINEAR

8 BIT_________________DROP DOWN LIST_____________BOOLEAN CHECK BOX
FLOATING _____________DROP DOWN LIST_____________BOOLEAN CHECK BOX
COLOR PICKER__________DROP DOWN LIST_____________BOOLEAN CHECK BOX
ETC.

Options under Convert To Linear obviously simply a checkbox to enable it or disable it.

Options for the source drop down would be:

Most common existing color spaces NOT including Linear.

And this also more closely matches what is happening.

Having Linear as a Source option is not only incorrect, it is misleading and confusing because it is redundant.

If an input is some kind of Gama curve and you have this setting to Linear, then it means LightWave is doing nothing to that source. Meaning it is treating it as if it is Linear. And traditionally this was the way of things prior to having Linear Workflow in interfaces. So in other words, none or off.

Yet in the same breath you are trying to say that this is the source profile, which it isn't. So you are in effect asking the user to make an "incorrect" setting to be "correct". And justifying this by saying that LightWave is treating it as if it is Linear. Which is the same thing as saying "none".

So if you have a source that is already Linear then you don't have to do anything to it, or rather, off or none. Linear is not needed as a source option.

Rather, the thing to do is if "Convert to Linear" checkbox is on, then it gives you the Gama options under source profile. If the checkbox is unchecked, then the Gamma source list is greyed out and unavailable. This would be the same as having the Linear setting as it is now. But far less confusing. If you know your source is Linear there should be no reason to do anything. So uncheck and conversion is off (Linear) for that input.

I don't know if this is some programming feat to change but it seems like it could hook up to the code in the same way. But I have no way of knowing.

The output options are fine as they are because it is closer to what we are doing. We are displaying or saving out to a profile. Linear or some kind of Gamma depending on the target.

This is clear and concise.


Apparently this is a very confusing subject. It does not seem confusing at all to me. But this interface in its current form breeds confusion, even as pointed out, with people who know this subject. Which I did.

In all of the other interfaces I use there is a simple Check Box. Next to it it says something to the effect of "Linearize...Images, inputs or whatever.

In Renderman it is like so:

https://rendermansite.pixar.com/ca_twopointo_cms_data/images/15089_6415.jpg

https://renderman.pixar.com/view/LinearWorkflow

If you notice it is very clear what you are doing and you even have the option to change the the input space. Yes it is in another panel someplace else. Convoluted, but correct.

Now LightWave has "simplified" this process by putting it all in one panel.

But it is like that Hemingway quote. "The operation was successful but we lost the patient".

Less convoluted but misleading and not really representative of what is really happening with current technology and general understanding of color space.

Linear should not be an input option. It is redundant and confusing. A check box might be one more thing to click but it is clear and not confusing and it also is in line with other apps and they way we understand it.

You are either correcting gamma or you are not. And additionally there is more than one gamma. Presently that is all we need to know. And presently Linear is not a gamma space. It is not an option it is not a choice and it should not be there. The only option that applies is "off", "Disabled" or better, a Boolean.

And this is how you get an interface that (by default mind you!) shows everything as Linear.

And that is just wrong.

This is a further explanation. And yes I said Linear is not a Gamma space. But within the context you can see my meaning was that it is not to assume anything other than it is not a Gamma space that needs correcting. And that is easy to understand. And all that needs to be understood here.

And yes I said should not be an input and not be an option. Because it does not have to be. That is optional.

If you have an interface that asks you to choose a color space, then yes, It makes sense.

And there are some cases in which this does make sense, and others not so much. And there are already various examples in software that illustrate this. Namely the Renderman example above. Pretty clear cut.

Now that that is out of the way you are left with LightWave's current interface.

And in view of the fact that it is asking for a color space, well it should be stated as such.

And that seems to make the most people happy.

Would have worked for me. :)

gerardstrada
02-21-2016, 09:52 PM
Wow so much confusion.

Disabled means no linearization or no conversion. as in like lightwave 9 and below.
It is the same in other appz. You pick srgb, etc, if you want to, but disabled is default or no conversion is being done.

I think its not known to some peeps that the renderer itself is linear even lightwave 9 and below, but the stuff we put in was not linearized. So to linearize everything, you need to convert stuff, and that became known as linearworkflow(LWF).
More confusing? :D

Indeed! Disabled means no conversion. Not "do nothing".

And in a CM context, the CS panel (which is ALWAYS globally active) needs to know which the input spaces are to determine if it converts (linearizes) or not.



Gerardo

gerardstrada
02-21-2016, 09:58 PM
Well if you are going to quote me at least put it in the proper context.



This is clear and concise.



This is a further explanation. And yes I said Linear is not a Gamma space. But within the context you can see my meaning was that it is not to assume anything other than it is not a Gamma space that needs correcting. And that is easy to understand. And all that needs to be understood here.

And yes I said should not be an input and not be an option. Because it does not have to be. That is optional.

If you have an interface that asks you to choose a color space, then yes, It makes sense.

And there are some cases in which this does make sense, and others not so much. And there are already various examples in software that illustrate this. Namely the Renderman example above. Pretty clear cut.

Now that that is out of the way you are left with LightWave's current interface.

And in view of the fact that it is asking for a color space, well it should be stated as such.

And that seems to make the most people happy.

Would have worked for me. :)


Well, being a gamma space that doesn't need to be corrected doesn't mean it should not be specified. Not in a CM context.

Notice also that input color corrections in LW are globally and locally. And you are comparing a Global panel app (LW) with a local panel app (Maya). Two different UIs. and again. in the case of Renderman only assumes sRGB curve. Very limited.



Gerardo

pinkmouse
02-22-2016, 01:48 AM
I thought I understood LW's colour spaces until I read this thread...:(

bobakabob
02-22-2016, 01:09 PM
Me too, I was advised to read the manual...

Surrealist.
02-22-2016, 02:30 PM
Which is lacking. I had some trouble deciphering it as well.

And sorry Robert I was going to actually answer your question directly. And never got to it.

So the only reason the interface is confusing is that there is a disconnect between what you need to do and what you are being asked to do.

So for your sake, let's just reset for a moment.

The top half of the panel is asking you to tell LightWave what the color space is for your inputs.

From Top To Bottom.

Picked Colors.

The first thing to understand is your monitor is displaying in a Gamma color space that has a curve applied to it so it will look correct. Basically all monitors as far as I know work this way. So when programming a color picker it has to display proper RGB colors. All things being equal (calibration and whatnot) the same RGB values will look the same from monitor to monitor. And from program to program. So there is a bit of a standard here. Right?

So the problem is that this data then goes into the program as digital information that is processed. And since it is asking you to input values and these values are being displayed in a curve on your monitor, the values you are inputting are in the color space of your monitor. Usually sRGB.

So this is an input that then needs to be converted to Linear color space. Which is as the name suggest, no curve. So that internally LightWave will not apply the wrong values you have entered into the render mix if you will.

And the same goes for Lights basically. You are adjusting values and color in sRGB space.

Pallete Files.

Never used those. But I imagine you are starting to get the idea.

Then for your images, you want to know what color space they are.

from the manual:


8 Bit Files-8-bit here refers to images that are 8 bits per channel such as JPGs, PNGs or TGAs, previously known as 24-bit or 32-bit . These benefit the most from color space conversion .
Float files - Images using floating point colors schemes don’t benefit from color space conversion, indeed it would cause severe banding and thus this should always be left on Linear

Basically it is just asking you to give them the color space of your images. Most will be sRGB but you can make other choices.

From Apply Color Space down.

Now this should start to make sense. You want to make sure you are displaying back to sRGB. So when your render you will see the proper feedback.

Try switching this to Linear and open a color picker. And then set it back to sRGB and look again.

This will tell you a lot and clear of a lot of confusion.

But if you are saving images to a float format usually you will choose Linear.

Hope this helps. :)

gerardstrada
02-23-2016, 04:59 PM
Pinkmouse, if you know how to operate the CS panel, there-s nothing to worry bout. The issue discussed is not really a technically incorrectness in how the CS panel works, but how the UI is presented to the user in order it reflects better what's happening behind the scenes. Something that might be improved by changing 3 things:

http://s9.postimg.org/w3jx3t727/LWCSpanel.png

1. Quick Preset panel visible.
2. Input space clarification in the action that is being performed.
3. Clarification that the input spaces are indeed input spaces.

Wondering how things could get really confusing when LW implements ACES framework. Hope they provide a nodal solution too.


bobakabob, you was advised to read the manual because you asked for a preset without providing any info about your work context (and pitifully there's no "magic button" in CM), but if you ask any specific question about linear workflow in your specific work context, I'm sure you'll get an specific answer, instead of a generic one that might not apply for your case.

For example, people commonly say use sRGB preset or talk about the sRGB linearization, and most of the times that's the way to go. But what if by chance you have an aRGB monitor, or a HDTV monitor? which are so common these days. You won't get a proper display with the sRGB preset. However, using the sRGB preset would be better than not using nothing if you don't know what to do. And this is what the manual recommends if you have a computer monitor.

One real reason why linearizations are needed, is not actually because of your monitor, but rather because of files with low bits depth, being the most common the 8-bpc images. Since non-linear corrections was the most efficient way to store 8-bpc images when higher bit depths were not available.

The fact that old CTR monitors presented also a typical 2.2 gamma response is just a happy coincidence. Because if CTR monitors would have been linear in that time, gamma corrections should have been invented anyway just in order to store 8-bpc images efficiently.

These days, new LED monitors are able to display linear responses. The irregularities can be compensated with the current technology, so we are able now to have linear monitor responses even with and without HDR display values. The reason why this doesn't happen yet is precisely (and mostly) due to 8-bpc files. Since we still need to encode those images in order to store them appropriately, this is, without loss in darker tones.

And this bring us to another common misconception which pitifully LW CS panel has implemented in its sRGB preset too. This (together with the improper interpretation of display ICC profiles) is one of the technical incorrectness I was referring before and hope they also solve it eventually. Picked colors (and Light colors) are not really in sRGB space. sRGB is an output encoding for images only. It's not really a display response. Display response for sRGB standard is defined through gamma, not through the sRGB curve as many people think. So what would be more correct in the CS panel for light colors and picked colors is to assume 2.2 gamma, not the sRGB curve. Moreover, the correction should be done in the picker (like happens in SG_CCPicker or the original version of Jovian Color Picker). For other standards, a generic gamma field would be more useful, so the users may define the gamma of their monitors' standards.



Gerardo