ypoissant

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? 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. 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. 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. 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.

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.

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

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. 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. 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.

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. Yes. As I mentioned earlier, renderer are inherently linear in nature. 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. 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.

- 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. 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.

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--------------------------------------

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. Yes. This is what you are supposed to see.

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.

All correct. 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.

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.

Just found this thread. Very nice work. I love everything about it.

Very good modeling job as usual from you. There is only one critique, though, but it is not about the model, texturing and lighting. It is rather the way the truck is composited in the photo. The truck looks way too large. The road looks like a two lane road but the truck covers it completely. And also, in a photo, the horizon line is at eye level so the truck looks like a monster in there. Finally, the truck perspective does not match the photo perspective.

I guess your groung plane texture is coming from a photograph. In that case, you need to reverse gamma correct the groung plane texture before using it for render. That is apply a gamma 0.45 to the ground plane texture in Photoshop.

Don't forget the gamma correction.

I only used Photosjop Levels command for that. I adjusted the 3 sliders. The black level (upper-left slider), the white level (upper-right slider) and the Gamma (upper-mid slider). Normally, I wouldn't have touched the black level but different objects in the scene had different ambience values on them (it seems) so when I cranked the gamma (to 2.2), some objects (the chairs among others) were pitch black while the rest of the room had a strong base ambience. So I had to adjust the black level to match the chairs. The same result could be obtained by reducing (even removing) the ambience on the surfaces. On the other hand, the white level adjustment could be avoided by increasing the lights intensities. The general light range is rather small if you take a look at the histogram so by adjusting the black and white level, it amounts to expanding the light range. As for the gamma adjustment, I simply pushed the gamma slider to 2.2. Doing that with post plugins in A:M, I don`t recall and I don`t have A:M with me here. There is a gamma plugin. There is an exposure plugin that can increase or decrease the range but it cannot clip the black level. There is also a contrast and brightness plugin that can be used for range cliping and expansion but it may be a little more difficult to control.

Here is #1 with some adjustments: Lighting range expanded and gamma corrected.

I like it. It's far from perfect but you already have a good sense of drama and cinema. The story, so far, is catching and shows a great sense of suspense. The framings, angles and compositions are very good and you have well thought out shots overall. This looks like your strongest skill. Lighting is good too. The characters are well differentiated and recognizable. The animations are rough though but they are improving. And on the "need improvement" side: timing is often off and slow. There is a lack of pacing and the voice are emotionless. You're on a very good start. Just keep up improving the animation side of that project.

Entering 0.45 anywhere in the render option panel gamma values would be wrong if that is what you are refering to. You would enter 2.2 in the desired gamma and set the current gamma so both side of the little gamma chart looks the same gray. If you are refering to the gamma setting in the render to file settings, then this one too should be set to 2.2 (or select the NTSC setting). I'm not quite sure which gamma seeting we are talking about here so we have yet another potential for more confusion. To be safe, I'd say just keep the settings to their defaults and go on with life.

I'm at home and I don`t have a gamma correct monitor here so I can't comment on the render quality since I can't rely on what I see although the render seems to be reverse gamma corrected. You mention you rendered out to 0.45. What does that mean? How did you do that? Normally you would render out to gamma 2.2 and that would apply a gamma correction of 0.45 but if you explicitly specified a gamma 0.45, then it (both A:M and Photoshop) would actually apply a gamma 2.2 which would be the reverse of what you would want.

Yes. That is correct. The "Current Gamma" is the actual monitor's gamma. That is why you set it using the gamma chart as a guide. On a properly set monitor, this should read 2.2 when both half of the chart look the same gray. The "Desired Gamma" is the target display device gamma. This one should be set to 2.2 for linear workflow. And that is the one that would appear in the targa header file. But it is not directly related to any post processing gamma. This gamma is only used for preview. It is not used for altering rendered to file images. Yes. You would want to avoid that. If you render with the intention of importing that in A:M, then you should not apply any gamma correction to the final render. Also, you would not want to apply any gamma correction to images that are desigend to be composited. You are better (and it is more correct) to do the compositing in linear space and then gamma corected after all compositing have been done. Also, of course, if you import any gamma corrected image into A:M, you have to linearize it first. That holds for A:M renders that have been gamma corrected too. I have to say that, "under my own scenario", I would not apply any gamma correction to the rendered images. I would prefer to keep all images as linear as possible and apply a gamma correction only when they are ready to commit to movie sequence. Also, I would save my images in OpenEXR or at least in a 16bits format so that when I apply a gamma correction (or a tone mapping operator for that mater), I would loose as less as possible.

Actually a gamma 0.45 is applied on each pixel. When we say that an image was corrected for gamma 2.2, we actually mean that a gamma 0.45 was applied to its data. I do not understand this. The monitor does not add gamma correction. The monitor just have a gamma curve of 2.2 and any image or color that is displayed on the monitor must be gamma compensated because of that. First, Photoshop do have its own color management system so this must be taken care of when dealing with Photoshop. Take a photo that had a gamma 0.45 applied to it so it displays linearly on a standard gamma 2.2 monitor. Now take that photo again and linearize it by applying a gamma 2.2 on it so it can be used as a linear reflectance (or albedo) texture on a patch. You took a photo that had a gamma 0.45 on its texels and apply a gamma of 2.2 so the textels now have linear data. Render that patch. The result is still linear since the renderer just do linear calculations. And now apply a gamma 0.45 on that render so it displays right on a standard gamma 2.2 monitor. THe resulting image will look just like the original. The above step may seem like splitting hairs in 4 because we only focus the texture colors. But the point of the linear workflow is to get realistic lighting. That is realistic light distance attenuation, realistic light cosine falloff and terminators and realistic light additions and thus realistic shadows.

That is correct. Images imported into A:M are gamma corrected so they look right on a gamma 2.2 display. Their image data is not linear anymore and they must be linearized. No. I'm talking about any RGB color that are entered in the color properties. Those colors were selected in a gamma 2.2 display device so they must be considered as having been intrinsically gamma corrected and must be uncorrected. One very obvious case is picking a color from a photo. But picking a color from a color dialog is also the case. Think that the color dialog lives in a display color space that is made so gamma corrected photos look good. Thus any color that looks good on this device must be considered as gamma corrected when the user sees them and selects them. I must add that in my tutorial, I give steps for setting a gamma corrected space when painting textures in Photoshop and The Gimp. If the application does the ungamma correction on the fly, then this special painting color space setup is not required anymore.

In principles, you should be able to put a gamma correction factor as a Gamma value in the image file and store the image data uncorrected and the display device would correct it on the fly. It practice, this is not the case. For targa files, even though there is a gamma tag, there is no standard way to interpret it. If you put a value of 2.2 in this tag, does it mean that the data is already corrected or that it needs to be corrected? Same for PNG files. So in practice, the gamma tags are not interpreted in those file format. The only clearly semantically defined standard is the sRGB standard. In this standard, the color profile embedded in the file must match the actual correction on the image data. If there is no explicit color profile in the image file, then it is assumed the sRGB gamma curve is already applied to the image data. The display does not apply a gamma 2.2. The display just have a gamma 2.2. That is a given in the equation. Now, because the display does have a gamma 2.2, the images that are to be displayed on this display must be gamma compensated. You can do that with the gamma post effect. We must assume, unless otherwise specified, that the display gamma is 2.2. I know of absolutely nobody who sets its monitor for gama 1.0. Try that with a graduating gamma chart such as the ones found on Norman Koren site and you will see that this is totally unusable gamma setting for a monitor. That is, indeed, what is happening. Except that we don't actually know the display actual gamma and the user don't know either. So I added this little gamma chart to help determine the actual monitor gamma. I'm not sure we are discussing the same thing here however. I added two gamma related settings in the "Render" options pannel. Those settings do not affect gamma on rendered files but only in preview renders so lights and textures can be properly tweaked so they look right once gamma corrected. This is the first step for a linear workflow and A:M have a step in advance on other 3D applications on the market because of that. The next step that needs to be done for total linear workflow in A:M is to systematically ungamma correct every RGB material colors and color maps before using them in the renderer. This option could be another checkbox in the render options panel.

I don't have much time to draw a diagram and I'm not installed for that. But I will try to come up with a post that resembles a diagram later. I don't know how the images were stored in those days. But I know that several digital cameras do have a RAW mode where the image data is stored in linear form and is not gamma corrected. Jpeg files coming out of those cameras are always gamma corrected though. Correct. Nowadays, color space handling is way much more sophisticated than simply maintaining a certain gamma curve. Every OS have its own color management system which uses device specific color profiles to match colors as precisely as possible from device to device. In this context, image files are also considered as devices and each image file should ideally contain its own color profile section. Without specific color profile section in the image file, any image file is considered to comply with the sRGB standard profile which specifies a gamma corrected for 2.2.