32 bit images

[dblhelix]

this is a pre-emptive strike;

i was just wondering if anyone is currently working with floating point images and has experience and perhaps dos and don'ts to share? i'm sure it's a breeze to find render settings etc pin pointy info on these boards but was just curious of all the other stuff that usually pops up along the way.

 

i'm on a pc, vista home, don't mind the renders and recently bought the subscription to 15h. i'm used to AE but this is my first time in A:M.

the project is fantastically devoid of visual detail, nearly black&white&grey with a little blue and green.

have just spent a couple of hours watching cutout animations on the net and as a result, have an acute allergy to blur&glow.

i want the depth from 32bpc to oomph my blacks and whites with the brutality glow can't give.

blacks=some bgr+shadow; white=characters "made of" paper.

 

any thoughts? or is it just smooth sailing?

[Fuchur]

A:M can render to OpenEXR-files.

Have a search for OpenEXR or LightBuffers and you should find some useful informations.

 

See you

*Fuchur*

[robcat2075]

OpenEXR is A:M's high dynamic range format. It is a floating point format. All the others are conventional 8 bit formats.

 

 

and recently bought the subscription to 15h.

 

Make sue you download the v15j+ update

[dblhelix]

been surfing here quite a bit and i've this board with yellow post-its pinned on for reminders.

among them one says i've chosen OpenEXR "with PIZ" (i think, i've MD in illegibility) as only viable renderer without writing down why.

now i know. he he. also found two bookmarks for light buffers, new term there.

slowly building context..

 

upgrade to j+, check.

 

thank you!

[robcat2075]

This Technical Introduction to OpenEXR covers the various compression options available in OpenEXR.

[dblhelix]

- - - !

got up to read my yellow render section and sitting down, you've replied. unreal, gunslinger.

 

thank you so much!

 

 

edit;

attempting to contribute, maybe someone wonders 'why 32?' for the first time so here's a really good tutorial for AE explaining the principle. you can click the 'HDon' button on the right so it becames 'HDoff' and an easier load to buffer.

http://vimeo.com/6916475

[NancyGormezano]

attempting to contribute, maybe someone wonders 'why 32?' for the first time so here's a really good tutorial for AE explaining the principle. you can click the 'HDon' button on the right so it becames 'HDoff' and an easier load to buffer.

http://vimeo.com/6916475

 

nice link - thanks

[ypoissant]

This vimeo is a very good demonstration. But there are one inaccuracy. The author keeps on repeating the advantages of 32 bits. In fact, the real advantage comes from the fact that this is a floating point mode. Not from the fact that this is 32 bits mode. OpenEXR has a 16-bits floating point mode that would provide exactly the same functionalities for all practical purposes. And OpenEXR also provide a 32-bits integer mode that would have the same issues with clamped white as the so called 16-bits mode. I believe this inaccuracy is beacuse the author's point of references is a very specific application for which 32-bits is necessarily floating point. Just be aware of that. Apart from that, that demonstrate very well the situations where floating point mode brings details that would not be present in integer modes.

[Fuchur]

This vimeo is a very good demonstration. But there are one inaccuracy. The author keeps on repeating the advantages of 32 bits. In fact, the real advantage comes from the fact that this is a floating point mode. Not from the fact that this is 32 bits mode. OpenEXR has a 16-bits floating point mode that would provide exactly the same functionalities for all practical purposes. And OpenEXR also provide a 32-bits integer mode that would have the same issues with clamped white as the so called 16-bits mode. I believe this inaccuracy is beacuse the author's point of references is a very specific application for which 32-bits is necessarily floating point. Just be aware of that. Apart from that, that demonstrate very well the situations where floating point mode brings details that would not be present in integer modes.

 

Very interesting.... so what I dont understand:

Floating-Point-Channels provide obviously a very high amount of different possible values for a channel but wouldn't a 32bit-integer-values although provide much more information than a 8bit-integer? Why cant I create the effects / "deeper" color-values with that too (so a bit less accurate than a floating-point)?

 

*Fuchur*

[robcat2075]

Very interesting.... so what I dont understand:

Floating-Point-Channels provide obviously a very high amount of different possible values for a channel but wouldn't a 32bit-integer-values although provide much more information than a 8bit-integer? Why cant I create the effects / "deeper" color-values with that too (so a bit less accurate than a floating-point)?

 

 

 

 

As i understand it,

 

8 bits represents values from 0 (black) to 1(full white) in 256 steps

 

16 or 32 bit integers still represent 0 to 1 but with more steps.

 

but floating point can represent values greater than 1.0 so, for example, your HDRI global illumination map can make the image of the white sun be much brighter than a white cloud.

 

I think floating point can also do negative values although I can't think of a use for that.

[dblhelix]

I believe this inaccuracy is beacuse the author's point of references is a very specific application for which 32-bits is necessarily floating point.

inaccurate enough to leave me mixing the terms, as you can tell from my post! not a techie..

 

In fact, the real advantage comes from the fact that this is a floating point mode. Not from the fact that this is 32 bits mode. OpenEXR has a 16-bits floating point mode that would provide exactly the same functionalities for all practical purposes.

this is interesting, have to test this. thank you!

 

 

for those of you who, like me, had to read the above three times before understanding, el stupido account of 32bpc in action: i tried to publish a film on youtube. the film was made not according to the publishing requirements, but to honor the story. this time it resulted in a foolproof list of "top three don'ts for internet publishing":

+ miniature detail

+ large black&white gradients

+ motion blur

that there is also a comprehensive list of the film's visual components.

 

didn't work. the look on youtube was dancing squares, rectangles, and an odd appeareance of a character in the cubistic mess. it was disgusting. yes i tried different renders!

 

i googled for a week full time: "no problem" "here look, this is how well it turns out" "no i never had that".

during the second week i stumbled upon the term 32bpc in a chapter on black&white. almost an association, not a remedy. and though i've forgotten today's breakfast i remember the sound of my jaw hitting the floor two years ago when watching the gradient background uploaded in 32bpc.

 

the image had become a space.

the first experience was that of beauty. if the addition was about information, then the information was light. even in solid black areas. the second experience was the tangible 3D quality (gradient=shadow).

after the first render, the difference on youtube was clear as day. there were artefacts, but now you could actually see the film. Coincidentally, vimeo was brought to my attention at that time, and there, only a couple of stripes bulked up in the background.

(all this was prior to youtube's HD-option)(but i maintain their compressor is a vendictive fanged abomination)

 

in the tutorial he instructs you to use a photo of your own and see what happens. that's probably a good way of getting a practical sense of what channel depth can do. it's not necessary for everything, but there might come a time it'll save you hide.

[ypoissant]

8 bits represents values from 0 (black) to 1(full white) in 256 steps

 

16 or 32 bit integers still represent 0 to 1 but with more steps.

 

but floating point can represent values greater than 1.0 so, for example, your HDRI global illumination map can make the image of the white sun be much brighter than a white cloud.

All correct.

 

I think floating point can also do negative values although I can't think of a use for that.

Me neither. Although there are some color space corrections that require negative values during transformation. But that is usually only relevant to the conversion algorithm and only held internally. That said, I could imagine one could want to save an image in CIE-XYZ color space, which requires negative values. But really, for all practical purpose, negative colors are not relevant.

 

One interesting aspect of HDR data that the demo failed to show is in the segment where he shows he can retrieve the sky and background colors behind a tree by reducing the exposure. He could also have shown that he can retrieve plenty of details in the tree trunk hole by increasing the exposure. Retrieving details in the darkest spots is not a property of floating point representation, though, but a property of higher precision. So those details would also be available in a 16 or 32-bits photo.

 

And also, HDR data is inherently linear color space in nature. Not warped color space by some gamma correction.

[dblhelix]

And also, HDR data is inherently linear color space in nature. Not warped color space by some gamma correction.

 

this i also recall, after failure and pre-32, changing to "north american web" in PS and deciding it made a difference but not big enough. still, i think i left it on in PS but continued in sRGB etc, the old monitor friendly space in AE. maybe here is the root to some of the evil?

 

what about color space for a film to festivals that accept DVD/miniDV and use reasonably priced projectors that munch up half your film's saturation?

 

and AE color space after A:M, for web? "use 'none'" is the only advice i've gotten on this, repeatedly. but the list at "working space" is so long?

[ypoissant]

The nice ball motion blur that the demo shows is possible because of the linear color space. That is just one advantage of linear color space. Even when using 32-bits and floating point, if the image data was in sRGB color space, he wouldn't get that. There are plenty of demo of working in linear color space vs sRGB in PS on the web.

 

In PS, the color space you choose is the one for your display. It does not change the color space of your images. But it makes sure whatever the color spaces of the images, they map correctly to the one you chose for your display. So whatever your selected display color space in PS, if you do not take specific steps to linearize your image, they will stay warped in sRGB color space and the filters, effects and compositions you will apply to them will add off to less than sparkling results.

 

The point is you keep all your data linear for the whole workflow and color space correct only when outputing for a specific medium at the very end when all the post processing is finished. You loose less information by doing it that way than by working is sRGB color space (which as I mentioned, gravely polutes your colors during post pro) and converting from sRGB to whatever the display you are outputing to requires. If you are already worying about loosing saturation, then working in sRGB color space is not going to lead you in the right direction.

 

You are looking at 32-bits floating point because you care about the filtering, effects, color shifting/correction, compositing results, etc. I'm sure you wouldn't choose to render to 8-bits jpeg compressed file because you care about your preciously rendered data. But if you still keep your workflow in sRGB, you are sabotaging the effort of working in floating point. You are adopting only half of the solution.

[Fuchur]

I think I got why it is necessary to use negative values... I understand that there are colors not seen at first which can however be used to bring more informations into visible-color-space in postproduction or being used by algorithms like post-pro-dof, etc.

 

What I couldnt wrap my head around is, why I couldn't specify a value of (ie) 150 as black and n (representing the possible color-space - a certain amount) as white (just and example)...

but when I think about it, this would not let me much space to shift down (only 150 values).

With negative values I am able to shift my numberspace of 32bits even further down if needed.

 

Okay... I think I got it.

 

Thank you for all the informations about that and explaining it to me

*Fuchur*

[dblhelix]

The point is you keep all your data linear for the whole workflow and color space correct only when outputing for a specific medium at the very end when all the post processing is finished.

 

(i've been using AE as a hammer and what happened two years ago was i got served a cold one.)

this quoted sentence brought an image of ancient analog times, of watching a color/lighting corrector work on a film. in the now, this would be TGAs, a couple from each scene, being corrected for final values/unity before applying values to the whole scene, per scene, before final render. more than self-explanatory, really. and yet there was so much trouble.

--

a good teacher not only answers the question but fuels further curiosity. thank you ypoissant!

Fuchur, i've no idea what you said there, and it still feels like my brain just took a shower. ok the allowance but the concept of negative color.. and that was not a question, because

robcat, hand at the holster, posting wishful tutorial thinking in a new thread. in case you have a minute?

 

and, umm, if someone could please make time increase as exponentially as curiosity?

[robcat2075]

The point is you keep all your data linear for the whole workflow and color space correct only when outputing for a specific medium at the very end when all the post processing is finished.

 

Since there are no linear color space display devices ( not in wide use) doesn't this mean all your work looks "wrong" until you do that the last conversion?

 

I have Photoshop set to "Color Management Off" which sets the "working space" to "sRGB". My 128,128,128 grays appear as proper middle grays in this set up. Is that not what I'm supposed to see?

[ypoissant]

Since there are no linear color space display devices ( not in wide use) doesn't this mean all your work looks "wrong" until you do that the last conversion?

The point of applications offering color management settings is so that you can vew your colors properly color corrected. So you keep all your data in linear color space but setup all your applications so they color correct for the display. But they color correct only before displaying. They do not color correct the data itself. With this workflow, you can choose whatever color space you like for your display monitor and keep all your data linear for the whole workflow and still see all your colors properly corrected.

 

I have Photoshop set to "Color Management Off" which sets the "working space" to "sRGB". My 128,128,128 grays appear as proper middle grays in this set up. Is that not what I'm supposed to see?

Yes. This is what you are supposed to see.

[robcat2075]

I have Photoshop set to "Color Management Off" which sets the "working space" to "sRGB". My 128,128,128 grays appear as proper middle grays in this set up. Is that not what I'm supposed to see?

Yes. This is what you are supposed to see.

 

 

So when I create a decal in Photoshop ( with my "Color Management Off") I'm working in linear workflow, right?

 

And when I use that in A:M, A:M is working in linear color space, right?

 

And when I render in A:M... I should leave Gamma>Value set to 1? To me that sounds like linear color space and this is what I've been doing all along and the results have looked right.

[robcat2075]

I did some more experimenting. I made a set of gray bars in Photoshop

 

It has five bars filled with gray values from top to bottom of 255, 192,128,64 and 0. On the right side I added small intermediate bars. The red numbers are the value you'd get if you sampled the original image with the eyedropper in Photoshop. On my (uncalibrated) monitor the grays bars seem evenly distributed in brightness from white to black.

 

The image also has a stripe of 50% transparency down the middle in the alpha channel.

 

 

I exported that in five formats and applied them to white and black surfaces in A:M.

 

 

 

The TGA decals render exactly as I would expect. The grays appear exactly as they did in photoshop and the alpha is handled as I would expect. If I take this render back into PS and sample the grays they are exactly the numbers I would expect. So far, so good?

 

The JPGs also show correct grays. JPG doesn't handle alpha channels so the transparent stripe is gone.

 

The PNG is much brighter in A:M than it was in PS. I've read that PNGs have a gamma change of 2.2 applied to them. PS seems to compensate for this when I reload the PNG into PS, but A:M seems to take the saved values literally and doesn't compensate. PS doesn't translate alpha channel transparency properly when writing PNGs so that is gone in the A:M decal.

 

When I save an EXR image from PS it presents me with a dialog box saying it will apply the inverse of the gamma setting to the image. The default is 2.2. The decal with that inverse of 2.2 on it loads and displays much darker in A:M than the way it appears in Photoshop.

 

If I save my image to EXR with that gamma setting changed to 1.0, the resulting decal displays with correct grays in A:M, matching the result of the TGA and the JPG.

 

However, notice the 50% transparent stripe down the middle isn't correct on either of the EXR decals. I don't know if this is a problem with the way PS writes the alpha channel or if it is a problem with the way A:M interprets the alpha channel.

[ypoissant]

I have to leave for work so I can't reply apppropriately. I'll reply later tonight. In the meantime, I'd like to suggest another experiment: Place 4 lights in a row spaces apart at equal distance with the same intensity. Then place a plane that occludes the lights casting their illumination on the ground. As light on the ground add-up, you will get a similar gray scale on the ground. This should scale linearly. See what results you get.

Diagram:

 

lights			   o  o  o  o



occluder -----------------



ground--------------------------------------

[robcat2075]

Four lights looked right , so to torture test the idea I did it with 16 sun lights set to 6.25% intensity. i also set the ground to 0 diffuse falloff so the light angle wouldn't be a factor.

 

 

 

When I sample the numbers in photoshop, every gray has the right value.

 

On my Cintiq, which is an LCD, I can see all 17 shades and they look about right. (My second monitor is a CRT, on that the black and near black look the same.)

 

Here's where I get confused... This monitor ( the Cintiq) is not calibrated, not according to any gamma calibration chart i've ever tried on it.

 

If I try to calibrate it with the Adobe Gamma utility, the setting that makes the chart look right makes the three darkest shades all look black.

 

If I try to calibrate with the gamma utility in my video card control panel, it makes the image brighter and although I can still see all the shades, the jump from black to near black seems pretty big.

 

My best viewing result is when I leave those at the "wrong" settings.

 

The same story, with slight variations, if I try to calibrate the CRT monitor.

 

So something must be wrong in my process somewhere. My monitors, A:M, Photoshop, the Adobe gamma control and/or my video card control. That's too many variables.

[ypoissant]

- Indeed, the values as picked by photoshop should read exactly as they should.

- Take care of loading the image in Photoshop to view it. There is always the possibility that PS will color correct it in some way. It is better to view the image in a web browser that does not apply any color correction (the posted image here on the forum should be that).

- Look at the "differences" between each bars. Do not try to judge the absolute gray values but instead judge the differences in contrast between each bars.

 

On my monitor, I see very little differences between the the darkest bars than between the brightest bars. I actually barely see any difference between black and the next darkest but I see a very clear contrast difference between white and the next brightest.

 

Then I loaded the image in Photoshop (my PS color management is set to OFF and PS workspace is set to Web which means no color correction is applied before display). And I play with the gamma slider (the middle slider) in PS "level" tool untill I feel confortable that all the bars differences are visually equal, the values and the contrasts seem well balanced. On my system, this happens at around gamma 2.0. If you are on a Mac with a gamma of 1.8, you will probably get a different gamma result.

 

So something must be wrong in my process somewhere. My monitors, A:M, Photoshop, the Adobe gamma control and/or my video card control. That's too many variables.

 

Monitor: Usually, in a system, that is the most probably cause of non-linearity. Unfortunately, the right way to calibrate a monitor is with a calibration tool such as the Huey or the Spyder. I think there are some other on the market now. The gamma calibration charts that are available on the web can get you at a usable state but it is not precise at all.

 

A:M: Unlikely. All renderers are inherently linear. That is their nature and getting a renderer to not be linear is nearly impossible. i.e. That would require too many hacks that would become extremely unstable under different uses. If you did not select a gamma for your output file, then the result is linear.

 

Photoshop: You should set PS workspace color profile to match the one of your display. You should have a matching profile in the drop box. Use it. If you have a Mac set with a gamma 1.8, then sRGB does not match the display. Apart from that, if you set PS color management to OFF, then you don't need to worry about Photoshop assuming things about the color space of the image you load: what you see is what's in the file.

 

Adobe Gamma and the video card gamma: You want to use only one of those but not both. Using both will create conflicts. Prefer the video card gamma setting to Adobe Gamma because Adobe gamma uses a software color lookup table for mapping the gamma correction while the video card controls the card A/D converters and does not create bandings. Use one and disable the other.

[ypoissant]

So when I create a decal in Photoshop ( with my "Color Management Off") I'm working in linear workflow, right?

No. If Color Management is set to OFF in PS, then you are working in the color space of your monitor. This includes whatever color space tweaks applied by the OS, the graphics card gamma correction of other gamma management applications. In applications that don't do any color management at all, then you are also working in the color space of your monitor.

 

And when I use that in A:M, A:M is working in linear color space, right?

Yes. As I mentioned earlier, renderer are inherently linear in nature.

 

And when I render in A:M... I should leave Gamma>Value set to 1?

If you do not use a "linear workflow", then yes. You are better off leaving gamma to 1.

 

If you use a "linear workflow", then it depends. The exact answer depends on the output file format. For OpenEXR output gamma must be left to 1. For other low dynamic range formats, the output gamma should be set to 2.2.

 

To me that sounds like linear color space and this is what I've been doing all along and the results have looked right.

Yup! The non linear workflow have been used by 3D artists for tens of years and it always "looked" right. Indeed it looks right on the surface. You select a color for a surface and it renders that color exactly. You apply a texture on a surface and it renders that texture exactly, etc. so it does look right.

 

It looks right because the renderer is a linear color space calculator. Because it is linear, it does not apply any transformation or distortion to the input colors. So if you input a color ramp in A:M and render that color ramp, you will get the same color ramp.

 

It looks wrong only when you start considering the distortions you get from lighting. Light that falloff too quickly. Shadow terminators that appears too early. Light that don't add-up correctly. Etc. However, renderers have implemented all kind of tricks to compensate for those issues like linear or no light attenuation to compensate for light that falloff too quickly, special shaders such as Oren-Nayar to compensate for early terminators and negative lights to compensate for light that do not add correctly.

 

So it is not too bad and not of such a concern as long as those tricks can be used. Compensating with all those tricks requires more work but most 3D artists have developped routines with those tricks. It starts to be a real problem when those tricks cannot be used anymore. That is the case when doing photorealistic and physically based rendering. And that is why the "Linear Workflow" issue is such a recent issue.

[dblhelix]

Monitor: (...)

A:M: (...)

Photoshop:(...)

Adobe Gamma and the video card gamma: (...)

i recall spending a day or two googling this general subject when struggling with publishing; testing something (lowering to 1.0 feels very familiar) at complete random in desperation and in vain. none of it stuck to memory cause everything was isolated bits of info with nowhere to anchor.

 

here's logic, context and reality. school was never this good before. thank you!

[robcat2075]

hmmm...

 

When I render that test scene in A:M ( with the A:M gamma at the default 1) and sample those grays in Photoshop and they come out with the "right" numbers... is that not what is really stored in the image file?

 

If you use a "linear workflow", then it depends. The exact answer depends on the output file format. For OpenEXR output gamma must be left to 1. For other low dynamic range formats, the output gamma should be set to 2.2.

 

I turned off the Adobe Gamma Utility and then used my video card control panel to calibrate my CRT monitor. This brings me to a setting of ~ 2.2

 

If I then render the test scene in A:M with gamma set to 2.2 the result is WAY too bright with all the light grays crowded together. And the values for the grays in the image are not "right" anymore.

 

 

 

What is the relationship between "desired gamma" and "current gamma" under "Preview renders" in the Options window?

[ypoissant]

When I render that test scene in A:M ( with the A:M gamma at the default 1) and sample those grays in Photoshop and they come out with the "right" numbers... is that not what is really stored in the image file?

Yes. That is what is stored in the file. A:M being a linear color space calculator, the values are going to be the expected ones.

 

Looking at the stored values is not relevant though. It is not looking at the right place. What is relevant is how you perceive those values on the screen.

 

I turned off the Adobe Gamma Utility and then used my video card control panel to calibrate my CRT monitor. This brings me to a setting of ~ 2.2

 

If I then render the test scene in A:M with gamma set to 2.2 the result is WAY too bright with all the light grays crowded together. And the values for the grays in the image are not "right" anymore.

Then your monitor is probably not set with a gamma 2.2. Even if you set the video card gamma control to 2.2, the end result might be different because the video card don't know how your monitor is setup. All the video card gamma control can tell you is that the electronics power curve is set to gamma 2.2. But if there is something else playing with the gamma in between the system and the video card or inbetween the video card and the monitor, then the end result may be off. I don't know for sure. I'm just hypothesizing. Normally, with a monitor gamma of 2.2 and a gamma correction of 2.2 on a regular gray scale, this should result in perceived uniform gray scale on the monitor.

 

What is the relationship between "desired gamma" and "current gamma" under "Preview renders" in the Options window?

This controls the preview renders only. It does not affect the final renders.

 

"Current Gamma" represents your monitor current gamma. You would set it so the little chart looks almost uniformly gray. When the chart is uniformly gray, the corresponding gamma number corresponds more or less to the monitor gamma.

 

"Desired Gamma" represents the gamma you would like the preview renders to look like. So say you indend to apply a gamma 2.2 to your final renders, then you would set "desired gamma" to 2.2 so you can view the preview renders the way it would look in the final render with the gamma applied. This lets you preview the end result while working on your project.

 

Those two controls are not intuitive. I know and I'm sorry for that. They represent the best way I could figure to start implementing linear workflow capabilities in A:M at a time where linear workflow was only a concept discussed among specialists. If I had to redo that today, with the experience, I would do it differently. But even though they are not intuitive, they do the job.

[robcat2075]

Tell me at which step I've gone wrong...

 

- I decide to make a scene that appears to have 17 linearly stepped shades in it from black to white.

 

- I make a scene with 16 lights, each set to 1/16 of full intensity, (the above scene, the one you suggested but with 16 lights instead of 4)

 

- I render the scene to a file with A:M's Gamma set to 1

 

- The image looks right in A:M's render window. All the shades are visible and they appear linearly stepped; not crowded or stretched at either end.

 

- I load the image into Photoshop (Color Management is off) and it looks the same as it did in A:M and sampling the image shows the numerical values are indeed linearly stepped from black to white.

 

At this point I get out my jump suit and say "Mission Accomplished!". I created a scene with linear tools and expectations and it came out with both linear numbers in the file and linear appearance on the screen.

 

??

 

But based on what you said above I shouldn't get this result unless I set A:M's render gamma to 2.2. Or something other than 1. (If I use the "current Gamma" tool in A:M, that says my monitor has a gamma of 1.6. If I put 1.6 into the "desired gamma" box and do a preview render the result is obviously not right and over bright in the gray tones.)

[robcat2075]

After some more fiddling, I'm finding that the brightness and contrast settings of the monitor have a lot to do with what gamma setting works

 

At low brightness and contrast settings it was possible to have a gamma setting of 1.0 and see all 17 shades and have them appear even, but the gray bar and stripes gamma test chart isn't right at that configuration. If I adjusted the monitor gamma to be "correct" then the shades looked wrong. To much jump from black to near black.

 

With brightness and contrast turned way up I can get to a place where all the bars are visible if I crank the monitor gamma up to 1.8. The gamma test chart also looks "right" at that point. The jump from black to near black still seem a bit big but not as bad as before.

 

But if this is correct, I'd say there isn't much on the web that was made to be seen with a gamma corrected monitor. The forum is very pale shades of blue. Photos on websites have obvious noise in the dark areas that doesn't seem intended. There don't seem to be muck black at all in photos

 

Even the A:M interface doesn't seem made for this. The difference between the white "play range" area and the gray at the top of the PWS is very slight now.

 

I feel like I need sunglasses to look at my screen now. I'm sure it would be blinding if I ever got it to the point where 2.2 gamma was working.

[ypoissant]

It is difficult to pose a diagnostic without having your system in front of me so I can inspect. But if the "current gamma" says 1.6, it's probably because your monitor is set not very far from 1.6. But it is most certainly not set to 2.2. If your monitor is actually set to 1.6 instead of 2.2, then that explains why you see almost uniform gray scale. Indeed, the Mac gamma of 1.8 is more uniform than 2.2. It is more comfortable but it does not correspond to the sRGB standard. This means that images created to look right on a 1.8 gamma monitor will appear darker on a standard sRGB monitor.

 

You should not put 1.6 in the "desired gamma" though. "desired gamma should normally be set to 2.2.

 

See what gamma you get from the gamma chart on the following page:

http://www.normankoren.com/makingfineprints1B.html

[ypoissant]

After some more fiddling, I'm finding that the brightness and contrast settings of the monitor have a lot to do with what gamma setting works

That is why, the best way to get a monitor calibrated is with the help of a calibraton device. This device is stick on your screen during calibration and reads the actual luminance at many levels for red, green and blue channels separately and adjust the graphics card to get optimal contrast, brightness and gamma.

[robcat2075]

It is difficult to pose a diagnostic without having your system in front of me so I can inspect. But if the "current gamma" says 1.6, it's probably because your monitor is set not very far from 1.6. But it is most certainly not set to 2.2. If your monitor is actually set to 1.6 instead of 2.2, then that explains why you see almost uniform gray scale.

 

Don't I want to see a uniform gray scale?

 

You should not put 1.6 in the "desired gamma" though. "desired gamma should normally be set to 2.2.

 

Here's a render I get if I set the gamma to 2.2

 

 

The step up from black is zero to 80. How could this possibly be used as part of a linear workflow when it's not recording linear values? Shouldn't an image used in a linear workflow have a 16 there?

 

On my monitor with the video card control set to 1.0 the step from black looks way too big. If I set the card control to 2.2 it's even worse. It's impossibly bright.

 

But that image looks normal on everyone else's monitor?

 

 

See what gamma you get from the gamma chart on the following page:

http://www.normankoren.com/makingfineprints1B.html

 

With my video card set to 1.0 I get 2.2 for the left bar, about 1.9 for the middle and I can't tell on the right.

 

With my Video card set to 2.2 I get about 1.0 on the left and middle bar and can't tell on the right.

[ypoissant]

Don't I want to see a uniform gray scale?

Not really although it is a good start. What I mean, is that this is not the ultimate goal to achieve. There are many issues that get in the way such as working with the limited dynamic range of 8-bits/channel colors.

 

sRGB would give you something a little more uniform. I think in A:M output gamma, if you select NTSC, you actually get the sRGB tone mapping curve. Not the straight gamma 2.2. Or is there a sRGB gamma setting?

 

Here's a render I get if I set the gamma to 2.2

On my monitor, this looks more evenly spaced than the previous one although, the dark stripes are slightly more spaced apart than the bright stripes.

 

The step up from black is zero to 80.

80 seems to be about normal. When I compute the resulting value for a 16 step with gamma 2.2, I get 74. This is not too far away. That is the effect of applying a gamma of 2.2.

 

How could this possibly be used as part of a linear workflow when it's not recording linear values? Shouldn't an image used in a linear workflow have a 16 there?

Really no. It is called "linear workflow" because there are steps where the images are corrected for the display devices which are not linear. What you see there is the result of one of those steps, the output step. I'll elaborate on that at the end of this post.

 

On my monitor with the video card control set to 1.0 the step from black looks way too big. If I set the card control to 2.2 it's even worse. It's impossibly bright.

 

But that image looks normal on everyone else's monitor?

 

With my video card set to 1.0 I get 2.2 for the left bar, about 1.9 for the middle and I can't tell on the right.

 

With my Video card set to 2.2 I get about 1.0 on the left and middle bar and can't tell on the right.

AH-ha! Now I see what is going on. If you get a reading of 2.2 when you set the video card to 1.0, then that is a good news. It means that your monitor default calibration is already calibrated to sRGB standards and don't really need further compensations. At least not wild compensations. Normally, with modern monitors, this should be the case. So just let your video card gamma setting at 1.0. The fact that your middle bar reads 1.9, though, is a little troubling. This is probably related to brightness and contrast not being set to their neutral position or something.

 

About "Linear" workflow.

 

Display devices are not linear. Their values (those numbers you read in Photoshop) to luminance transfer curve follows a power function with an exponent that goes around 2.2 up to 2.5. The industry have decided that the standard would be 2.2. Since then, all manufactured good quality monitors are calibrated to this standard.

 

Becasue display devices are not linear, if we adopt a linear workflow, we must add steps to compensate for the non-linear devices in the workflow. One such step is to apply a gamma correction to the rendered images. This gamma correction alters the colors in the image so they look right on the non-linear display. That is why the step of 16 that you read before gamma correction now reads 80. The final image is not in linear color space anymore but in sRGB or gamma 2.2 color space.

 

In a linear workflow setup, colors inputed to the renderer are also in the monitor color space. Either because the color palette, picker, checker, mixers, etc., live in the display color space or because the colors come from a photograph which also lives in a color space that is assumed to be sRGB. So steps must also be taken to linearize those color values before the renderer uses them. In the industry, this step is called "degamma" because it consist on removing the gamma correction to retrieve the linear color.

 

You take sRGB color space colors as input, linearize them to feed the linear color space renderer and then take the linear render from the renderer and delinearize the render to match the monitor sRGB color space. This is the ssence of the linear workflow.

[robcat2075]

Thank you for your detailed reply!

 

When we render a TGA or JPEG in A:M, do they get a color profile embedded in them?

 

sRGB would give you something a little more uniform. I think in A:M output gamma, if you select NTSC, you actually get the sRGB tone mapping curve. Not the straight gamma 2.2. Or is there a sRGB gamma setting?

One of the menu choices is NTSC/sRGB which sets the value to 2.2. I guess for A:M purposes those are regarded as synonymous.

 

 

 

How could this possibly be used as part of a linear workflow when it's not recording linear values? Shouldn't an image used in a linear workflow have a 16 there?

Really no. It is called "linear workflow" because there are steps where the images are corrected for the display devices which are not linear. What you see there is the result of one of those steps, the output step.

If my next production stop is to use this image in some composite in AfterEffects, I'd want to use the version that had a value of 16, I'd think, right? If I used the "80" version then I'm using a version that has compressed the bright grays near the white end of the scale. Maybe the software in AfterEffects is expecting the "80" version and un-smushes everything? That sounds messy.

 

 

 

 

With my video card set to 1.0 I get 2.2 for the left bar, about 1.9 for the middle and I can't tell on the right.

 

With my Video card set to 2.2 I get about 1.0 on the left and middle bar and can't tell on the right.

AH-ha! Now I see what is going on. If you get a reading of 2.2 when you set the video card to 1.0, then that is a good news. It means that your monitor default calibration is already calibrated to sRGB standards and don't really need further compensations.

 

I've kind of suspected that too, but I wonder where this is controlled? I've taken out the Adobe Gamma utility, the video card is set to 1.0, there are no other control panels for my display...? And I wonder how we know that chart is being displayed correctly, because...

 

 

... the gamma chart on on my video card control panel still suggests I'm way out of whack at "1.0". It's similar to the one you put in the A:M Options panel. The solid gray bars are WAY darker than the striped bars if my video card setting is at 1.0. If I move it up to ~1.9 the bars finally match. And this is true of all other such gamma charts I encounter.

 

 

 

If my viewing device is displaying correctly I would think those bars would be very similar.

 

My understanding of those charts is that the stripes simulate a 50% gray and you want the solid 50% gray to match that.

 

So far, I haven't encountered any set-up process that leaves me with a normal looking result on-screen.

[ypoissant]

When we render a TGA or JPEG in A:M, do they get a color profile embedded in them?

I'm pretty sure that there are no color profiles written in those files. Since LDR files are assumed to be in sRGB color space anyway, especially jpeg, there is not much point in duplicating this information in a color profile. In other words, not puting an explicit color profile in those files is like saying that the color profile is sRGB.

 

One of the menu choices is NTSC/sRGB which sets the value to 2.2. I guess for A:M purposes those are regarded as synonymous.

I coded the sRGB gamma function and I remember coding the exact sRGB curve which is not quite gamma 2.2 but nearly so. The sRGB have a linear segment in the dark colors designed to prevent some artifact. But I don't recall which artifact this is.

 

If my next production stop is to use this image in some composite in AfterEffects, I'd want to use the version that had a value of 16, I'd think, right?

Yes. Absolutely.

 

If I used the "80" version then I'm using a version that has compressed the bright grays near the white end of the scale. Maybe the software in AfterEffects is expecting the "80" version and un-smushes everything? That sounds messy.

Yes. It is messy but you are right. compositing applications like AE already have what it takes to degamma those images when they come in a LDR format. However, like you observe, you loose data by going this route. For this reason, it is better to either encode LDR image in 16-bits file format or even better in floating point format (the here so called "32-bits images"). The best strategy is to keep the image in linear space in HDR format. Post prod with linear images and then gamma correct when post prod is done before outputing to final format.

 

I've kind of suspected that too, but I wonder where this is controlled? I've taken out the Adobe Gamma utility, the video card is set to 1.0, there are no other control panels for my display...? And I wonder how we know that chart is being displayed correctly, because...

The only way to know for sure is to use a monitor calibration device. This will do the best job. By this I mean that whatever the capabilities of your monitor, it will set it in the most optimal way. So the charts may still look off but you know this is still the best you can get with this monitor.

 

... the gamma chart on on my video card control panel still suggests I'm way out of whack at "1.0". It's similar to the one you put in the A:M Options panel. The solid gray bars are WAY darker than the striped bars if my video card setting is at 1.0. If I move it up to ~1.9 the bars finally match. And this is true of all other such gamma charts I encounter.

The fact that the three gamma bars on Norman Koren web page indicate different gamma is strange and would tell me that something is setup wrong somewhere. WHat this is, though, I don't know.

 

My understanding of those charts is that the stripes simulate a 50% gray and you want the solid 50% gray to match that.

Yes. That is the principle.

 

So far, I haven't encountered any set-up process that leaves me with a normal looking result on-screen.

I'm sorry this is turning out so difficult. I'd like to help but there is little I can do remotely.

[robcat2075]

My understanding of those charts is that the stripes simulate a 50% gray and you want the solid 50% gray to match that.

Yes. That is the principle.

 

 

If a person's monitor is set that way, so that the two grays match, is that monitor set to 2.2 gamma or is it linear or is it something else?

 

The intention of that adjustment is ___________?

[dblhelix]

in newbiespeak

 

for a newish LCD,

 

- set your graphics card gamma to 1

- set your monitor gamma to 2,2

(- make sure your monitor' brightness and contrast are set to factory defaults)

- download the 17-bar robcat greyscale-chart, scale it up and make the window only show the bars and no large black or white areas and leave on the screen (if you have a desktop bgr in color make sure it doesn't show)

 

late at night in a pitch black workroom

 

- turn off screen, wait a couple of minutes for your eyes to forget the light, then

turn on your screen and adjust brightness and contrast (with actual buttons on your monitor) so the bars look evenly graded.

if you "loose judgement" turn off screen, wait a couple of minutes in darkness then continue

 

and when finished, you should be at the starting point, to be able to judge your work in a relative, representative environment.

 

this is for black and white, not RGB.

 

i'm working on a laptop; it seems wisest to do the color etc corrections in the slower but trusty stationary with an LG LCD. also, as it happens, i'm testing scanned drawings where the pencil is manipulated with selective color > neutrals > successively increasing black, then morphing into cleaned PS drawings. was in grayscale but switching to 32 now

[ypoissant]

If a person's monitor is set that way, so that the two grays match, is that monitor set to 2.2 gamma or is it linear or is it something else?

It is set to gamma 2.2.

 

Making a monitor linear (gamma 1.0) would push the electronics quite far. A monitor natural gamma is already about 2.5. Gamma 2.2 is a good compromise for all monitor without pushing their electronics too hard. So because the monitor electronics is setup got a gamma 2.2, normally, a factory set monitor would not need any further gamma adjustment from the video card or such. The electronic gamma adjustment is not to be confused with the gamma control pannels, though, which don't modify the electronics of the monitor but adjust the signals sent to the monitor.

 

The intention of that adjustment is ___________?

... to make reasonably sure your monitor is set to gamma 2.2.

 

But this chart is just approximate. It should works for all monitor set to 2.2 gamma with correct brightness and contrast settings. It is a quick check. But if the monitor controls are OFF by a good bit, this chart will not be very helpfull.

[robcat2075]

If black is 0 and white is 1, then the black and white stripes are simulating 0.5

 

if RGB of 128, 128, 128 is made to display the same as that 0.5, I'm wondering how that is not "linear" . that sounds like x=y.

 

 

A monitor natural gamma is already about 2.5. Gamma 2.2 is a good compromise for all monitor without pushing their electronics too hard. So because the monitor electronics is setup got a gamma 2.2, normally, a factory set monitor would not need any further gamma adjustment from the video card or such. ...

 

But this chart is just approximate. It should works for all monitor set to 2.2 gamma with correct brightness and contrast settings. It is a quick check. But if the monitor controls are OFF by a good bit, this chart will not be very helpfull.

 

This is where my in-person observation is absolutely at odds with everything everyone else is saying

 

a monitor's default behavior is 2.5... with tweaking it's 2.2... and in those circumstances everyone else is getting a display where the two grays match pretty close. On a default monitor.

 

No monitor I have appears that way at its defaults.

 

But if I adjust my monitor to make those two grays similar it's obvious that everything else is pale and washed out and over-bright. I do like the fact that with this setting the lower end of the gray scale is not all crunched to black and that I can see the difference between 0 and 8 and 16. But that setting doesn't render most of the rest of the world's graphics well. They seem to be made with the expectation that 128, 128, 128 displays quite a bit darker than 50% gray. For them, the middle grays are found somewhere between 128 and 256

 

If I create graphics with my monitor at its matching-grays setting everyone else complains that the result is too dark. It looked fine on my monitor but way too dark on theirs. All the shadow detail is black.

 

It's a mystery to me.

[ypoissant]

If black is 0 and white is 1, then the black and white stripes are simulating 0.5

 

if RGB of 128, 128, 128 is made to display the same as that 0.5, I'm wondering how that is not "linear" . that sounds like x=y.

You need to let the math and electronic away. If you concentrate only on the values and how those values add on, then you are not focusing on the right issues. When a monitor display a value of 128, it does not come out as half bright. So those numbers are fine for computations but not fine for display.

 

This is where my in-person observation is absolutely at odds with everything everyone else is saying

 

a monitor's default behavior is 2.5... with tweaking it's 2.2... and in those circumstances everyone else is getting a display where the two grays match pretty close. On a default monitor.

 

No monitor I have appears that way at its defaults.

 

But if I adjust my monitor to make those two grays similar it's obvious that everything else is pale and washed out and over-bright.

That could be an habit thing. You are used to see your colors in some way and the other settings look off. I had this same feeling when I started to play with the gamma 2.2 issue years ago. But now I'm comfortable with thos settings and they look natural.

 

Prior to that, I was working in a multimedia business and had my monitor set to gamma 1.8 to match my collegues that were all using macs. And we were receiving complains from several customers that our products looked too dark. Gamma 1.8 have several advantages relative to actual linearity of displayed values but it does not match the vast majority of computer monitors out there. Those were days prior to sRGB standard BTW. So we had to figure this stuff by ourselves. Unfortunately, there was no way to fix the mac monitor gamma that were factory set that way and had not controls. So the artists learned to compensate by making all their graphics more washed out that natural.

 

I do like the fact that with this setting the lower end of the gray scale is not all crunched to black and that I can see the difference between 0 and 8 and 16.

That is the main reason why the gamma 2.2 that comes with the linear workflow is preferable. This should be the focus of observations instead of the fact that 128 corresponds to 0.5.

 

But that setting doesn't render most of the rest of the world's graphics well. They seem to be made with the expectation that 128, 128, 128 displays quite a bit darker than 50% gray. For them, the middle grays are found somewhere between 128 and 256

I'm lost there. It is probably because, to me, the relationship between 128 and 50% gray is not true when displayed on a monitor. Indeed, on a normal monitor, 128 is quite darker than 50% gray. And that is the whole point of all this gamma compensation issue and the linear workflow.

 

If I create graphics with my monitor at its matching-grays setting everyone else complains that the result is too dark. It looked fine on my monitor but way too dark on theirs. All the shadow detail is black.

Exact.

[ypoissant]

FX-Guide interview with Zap, linear workflow evangelist.

 

Worth listening. There are more information on this subject than any discussion we can have here.

[zandoriastudios]

I'm glad they invented the Huey (keeps me from thinking about it...)