Welcome, Guest. Please Login or Register
Home Help Search Login Register
Page Index Toggle Pages: 1
Send Topic Print
Gamma as a property of the monitor and LDR images (Read 9204 times)
Andy
Junior Member
**
Offline


I love YaBB 1G - SP1!

Posts: 5
Gamma as a property of the monitor and LDR images
01/12/07 at 10:34:57
 
I realize it's maybe a little early to be making suggestions, but I noticed that SDR seems to be keeping track of gamma alongside the high dynamic range images, but not alongside the low dynamic range images.  In my mind, this is backwards, as the HDR images encode data linearly, such that it is independent of gamma.  The gamma associated with the HDR image is actually only dependent on the monitor, as it is the function required to make the HDR data show up properly on a display.  For example, the same HDR image needs a 1.8 gamma on a Mac and a 2.2 gamma on a PC.  Encoding 2.2 alongside the HDR image suggests that it should be 2.2 regardless, or that a 1.8/2.2 correction gamma needs to be applied, which is not really the case.

On the other hand, the low dynamic range images encode their data using a predetermined gamma, such as 2.2 on a PC, such that the data has linear bit density against the perceptual density of the monitor.  So, in this case, it would be appropriate to encode gamma information alongside the image so that proper 1.8/2.2 (for example) gamma corrections can be applied when the image is used on a different platform.  Or so that 2.2 gamma can be removed if the image is passed into a linear rendering workflow (as we currently do with most of our texture data).  In fact, I believe some of the newer image formats, like .png actually are capable of encoding this as a tag in the header (though from what I understand, it's rarely set properly, and none of the widely available applications, like web browsers, make use of it).

I know you guys have all been thinking about this longer than me, so maybe there's some good reason for things being the way they are...  Let me know.

Thanks,
Andy
Back to top
 
 
IP Logged
 
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Re: Gamma as a property of the monitor and LDR ima
Reply #1 - 01/12/07 at 19:27:12
 
Hi Andy.

You got that just right.

LDR images have the Gamma baked in, HDR doesn't.

If you guys have adopted a linear workflow, I can only congratulate you! This is the right way, and the gamma in the HDRs should be ignored.
However, most people don't have that, and leave all their textures in gamma distorted space. Which is technically wrong, but gets entirely screwed up when lit by a linear HDR. It might not be the ideal solution to apply the Gamma to the HDRs only, instead of ripping it out of all other images, but it fits into the current workflow for most people. It doesn't force them to change their entire pipeline, and gives at least an acceptable result.

It boils down to the choice of Gamma-First or Gamma-Last workflow. Straight linear is the more accurate, and makes post in linear space possible. But it also enforces post, at least applying the Gamma - which is an entirely new concept to a lot of people.
Gamma First is still more convenient, because you see what you get. Not only home and hobbyists work that way, in fast paced TV stuff we are getting by with it very well. And in our case, we have a huge asset library of pretextured objects that we can keep using.

Actually, I don't mind the idea of tagging the LDR image with an Gamma, to allow a linearization. Even though I believe that doing that in 8 bit is screwing up the image - medium tones get crunched together at the dark end, and if that is quantized in 8bit they are all gone.
I have no idea how Mental Ray handles this, just checked it out in LW and if the texture itself is loaded in as 8 bit, the gamma pre-adjustment happens in 8 bit too. No matter if the renderspace is 32 or 64 bit or whatever. Try the extreme to see it: Any image, pre-gamma with 0.1. Put in as a backdrop, and throw in post-gamma 10. Should be back to where it was, but in LW it isn't.

...

So, for a truely linear pipeline all the way through, you would ideally have all your LDR images as EXRs. Which is again a huge pull on the ressources, and doesn't work for everyone.

Blochi
Back to top
 
WWW  
IP Logged
 
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Re: Gamma as a property of the monitor and LDR ima
Reply #2 - 01/12/07 at 19:46:58
 
ai ... maybe I should have shown the LDR image before the scramble, to see what it should have gotten back to  Wink

...

So, yeah, the idea is here to align the HDRs with the rest of the scene instead of the other way around. Just getting them aligned at all is already a huge thing, because most people don't.

Blochi
Back to top
 
WWW  
IP Logged
 
Andy
Junior Member
**
Offline


I love YaBB 1G - SP1!

Posts: 5
Re: Gamma as a property of the monitor and LDR ima
Reply #3 - 01/12/07 at 23:19:48
 
Ah yes...  I'm all too familiar with the old gamma first workflow.  It took me months to finally convince myself that it was definitely "less correct," given how ubiquitous it is.  And I'm in complete agreement that if SDR is to be useful to the majority of users, it needs to support that workflow as an option (at least until the applications support linear workflow better).

On the other hand, I think one of the goals of something like this should be to help lead people down the right path when possible, so I would really love to see the format support all the data necessary to make transitioning to linear workflow possible.

So, in an ideal world, what I would propose would be to have a way to store a universal system gamma in a single location somewhere on the machine, or as an option on the importer, and the option to store gamma alongside each image in the sdr file (but it should be the gamma that is already applied to the data, not the gamma that needs to be applied for it to look right on a particular computer.  i.e., the default if the option is omitted would be 1 and most ldr data would have 2.2).

It seems to me that this would be the most consistent way to encode the data, and would still allow you to apply the same sorts of gamma-first operations to allow that workflow.  I'm mostly just afraid that a few years down the road, everyone will be doing linear workflow, and there will be a backwards-compatibility problem when hdr images are listed as having a gamma of 2.2 instead of 1.

The way we currently implement a linear workflow in XSI is to apply a gamma strip operation after the texture data is loaded into a color struct, which has floating point values.  It looks really simple in the interface -- just a texture node piped through an exponent node.  For post-processing, we render out linear exr (usually just 16-bit) but for preview renders we put another exponent node on the lens shader to get the desired result.  We have some other tools in the pipeline that make it easy for artists who don't necessarily understand the intricacies of gamma to work with the system.

I actually gave a presentation on this technique at the most recent XSI LA usergroup meeting.  I'm pretty sure I bored and confused a lot of folks, but others were very interested.  And Softimage has been talking to me some about trying to help them get the software to support the workflow a little better.  It's a pretty hot topic these days.  Actually, I've noticed that on the "comment on my work" user forums, lately one of the most common things people say is "You need to apply proper gamma" or something of the sort.

Like I said though, I'm completely sympathetic to the need for a gamma-first workflow.  I just don't want to see the format be limited to it (or, even built around it, really).

Let me know what you guys think.

-Andy
Back to top
 
 
IP Logged
 
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Re: Gamma as a property of the monitor and LDR ima
Reply #4 - 01/13/07 at 00:51:22
 
Oh, I am so jealous at XSI right now!  Grin

I have always been fighting against windmills, both in the Lightwave world as well as internally in the company. TV shows that run for a couple of seasons are not easy to restructure. You never have a chance to start fresh. It sucks. That is why at this time, SDR has been laid out to optimize the Gamma-First way of doing stuff. It needs to work right now, to get people hooked. I don't intend to educate people with this software, tried that before, it never works out. Stuff has to work, or everybody turns away.

Quote:
I'm mostly just afraid that a few years down the road, everyone will be doing linear workflow, and there will be a backwards-compatibility problem when hdr images are listed as having a gamma of 2.2 instead of 1.


But I don't see any problem with future compatibility (or your present... Cry ) . It's not listed as "having" that gamma, but "getting adjusted" with that gamma.

Given the fact that a linear workflow is in fact LESS complicated gamma-wise, I would rather leave it this way around.

The Gamma-First workflow is the one that needs serious tweaking. Because it's not just always 2.2 or 1.8, unfortunately. It should ideally be kept as low as possible to maintain the range, and as high as it needs to be for looking similar. It's kind of abused as contrast control. That's why it stands as "target adjustment" tag in there. It's easy to find the right ballpark with the sdrEdit generator. When you look at the new HighRes SDRs, you will see that the gamma tag has been set very carfully, and not just arbitrary 1.8 or 2.2. Nowadays Macs don't do the 1.8 anyway, at least mine is 2.2 as well.

Problem with tagging the gamma that is IN the file is, that this would always be 1 for an HDR. Doesn't do us old-schoolers any good. We loose the granularity of this control.

What it boils down to is this, I think:

If XSI allows a linear worflow, you should give it as an option. Well, since this is what your pipeline is, you'd do that anyway. Let the user choose (Linear Workflow / Old School Workflow). In case of Linear, you'd ignore all gamma tags, and apply a 0.454545 / 0.55555 to the LDR background instead, depending on the system. But if they choose to go with old school, you'd do them the favor of setting it up as good as it allows it, and use the gamma from the SDR. The gamma tag is a legacy thing all together anyway, and I don't see anyone stumbling over it even if everything will happen in linear at some point (which I don't see, but that's probably just me).

And as soon as Lightwave allows me to do so, I will do the same. And if they don't come out of their ass soon, I switch to XSI or Modo.

Would that work for you, Andy?

What are the others saying? Dschage, Volx, Katachi, Chris?

cheers,
Blochi
Back to top
 
WWW  
IP Logged
 
Dschaga
Ex Member


Re: Gamma as a property of the monitor and LDR ima
Reply #5 - 01/23/07 at 23:44:46
 
hmm ..  Undecided

I never had any problems with the *now called* linear workflow since 3dsMax r1.
If you ever aswered the question why the same image look on one monitor  bright and on the other monitor dark, you have a point of view and take care of it inside every application ..not only photoshop or Xpress. Wink
btw ..but good to know that apple jumps on the 2.2 train ..this will make things easier.


A gammavalue for the LDR images sounds fine for me, since some panoramas could be adjustments inside the SDR format if needed even inside the LWF ..why not?

I then would suggest to add some code to the SDR loader , which is checking if any other maps/textures are loaded with a specific gamma and then ask the user if he wants the LDR image to be loaded with a gamma or not.
Back to top
 
 
IP Logged
 
Gerardo
Senior Member
****
Offline



Posts: 74
Re: Gamma as a property of the monitor and LDR ima
Reply #6 - 04/05/07 at 13:37:42
 
In Lightwave, we can also linearize colors, textures and images through nodes, shaders and image filters in preprocessing, and preview our results through pixel and image filters by way of basic LUT's tools.
 
I think if we apply the inverted gamma exponent to a gamma-encoded 8bit image, we shouldn't have problems to apply its previous gamma back. Let's say we have used 2.2 gamma monitor for a textue (or background or whatever), if we linearize the image with its exact value (.4545), we get the proper result at the end.  This work for LW or any other 3D app

...

Problem comes with 8bit images when we surpass this range

...
 
Now, if for some reason we need to adjust a gamma correction very superior to its original gamma-encoded value, we can make a blank 32bit image with the same size than our texture (or background...) and apply it the 8bit image through TexturedFilter.  This allow us to keep better all 8bit data in a floating point space. 

...

This trick is very useful also if we want to fake HDR lighting with a LDR image (it's more suitable for IBL light rigs) 
 
 

Gerardo
Back to top
 
 
IP Logged
 
tischbein3
Ex Member


Re: Gamma as a property of the monitor and LDR ima
Reply #7 - 04/10/07 at 11:59:59
 
Quote:
In Lightwave, we can also linearize colors, textures and images through nodes, shaders and image filters in preprocessing, and preview our results through pixel and image filters by way of basic LUT's tools.


AFAIK preprocess filters in lw are applied to their original colorspace. So messing with gamma there will certainly result in data loss.

Well anyway, I'll try to add a gamma value to the bg image in sdr edit this week (with a slightly different color to the controls, so its clear this is an "optional" feature.)
Back to top
 
 
IP Logged
 
Page Index Toggle Pages: 1
Send Topic Print