Here are links to the v14.0 Beta 3 Installer.

Windows:

• v14.0 Installer (2007 - Oz CD ) (11m)
• v14.0 Network Installer (Hasp - Requires 2007 subscription) (15mb)

OSX (Universal Binary):

• AMv14Installer.zip (23.6m)

Fixes since the last release:

• 0004514: [Sounds] Sound cropping fixed, sound can be dropped on a rotoscope in a choreography to tie rotoscope offsets to sound offset (Noel)
• 0004493: [Rendering] displacement, Crash or Exception #010 on render (steveb)
• 0004470: [Animation] TWO: skeletal mode bone draw with path, Crash on shot _2_03_092 (KenH)
• 0004460: [Images/Animations/Rotoscopes] use image sequence name for rotoscope name (Steve)
• 0004363: [Relationships/Poses] model poses posing distorts in poses for facial animation. (3dartz)
• 0004457: [Constraints] Constraint target dropdown limited to objects and bones visible in skeletal mode unless shift key is held down. (Noel)
• 0004438: [Modeling] Rotoscope Images not showing up in Model window (Paul Forwood)
• 0004416: [Composite/Post Effects] Post Effect shortcut saves absolute paths to cache, should be relative. (Noel)
• 0004432: [Realtime] Rotoscope showing of in Rendering but not in Realtime (Fuchur)

Make sure when you report bugs to A:M Reports, that you pick the v14 project in the upper right.

QUOTE

I've been collecting these new image enhancements you know.
Revolutionary stuff in the making.

Thanks!

Has the new feature of easy hiding models in a chor been introduced in this version? I can't get it to work.

I need to report an issue with Beta3, but when I went to the reports folder there was no V14 available in the drop down menu. I tried reporting it anyway but I get an error page cannot display.

Anyway, has anyone have this happen to them? It's in the timeline, on any given axis, I get two cp's on the same instant (same frame).

I have seen that before too dhar.

I hope that the A:M Reports isn't down, I have to make some reports here too...

Have lights changed in A:M14 Beta3?
My renders are coming out very bright and washed out. This occurs in the modeling window as well as the choreography.
I'll report it anyway.

I've noticed that too. I've only been doing the Q render though.

The difference in render is most probably due to the preview gamma adjustment. If you want to get no gamma corrections to your quick and progressive renders, then go in the options pannel, the render tab and set the desired gamma to 1.0 and the monitor gamma to 1.1. Thanks for the A:M report about that. I need to make sure the defaults are set appropriately. I will eventually write a short tutorial on how to adjust it.

Yes, that was it. Thanks, Yves.

Lesson learned? Do we all need to check our gamma now? What was the default again? Why has it changed?

I'd say yes.

The default should be Monitor gamma : 2.2 and desired gamma 1.0. This setting will actually apply no gamma correction to the preview renders. Those default settings will be changed in the next beta release.

This is a new option. I need to prepare a tutorial on its use. It is designed so people working on a team project, like TWO, can preview their renders with similar gammas so that there is no large differences in the way textures and lighting are made.

A default CRT monitor have a gamma of 2.2. When using a monitor calibration device such as the Huey, the default gamma is also set and kept to 2.2. That is why the monitor gamma property will be set to 2.2 by default. But normally, this should be adjusted, using the gray scale slider, to each monitor. The idea is to select a gamma where the left part and the right part of the gamma gray scale looks the same shade of gray on the monitor. By matching this "Monitor Gamma" property, the preview renders will look like how the most common monitor on computer users around the world will see your render.

The "Desired gamma" property represents the gamma correction that would be applied to the rendered image. A desired gamma of 1.0 means that there will be no gamma correction applied to the preview renders. A:M users are not used to apply a gamma correction to their rendered images (although they should do so but more on that later) so the default will be set to 1.0. Normally, if you set the "desired Gamma" property to, let's say, 2.2, you should also select a gamma of 2.2 in the final render options pannel.

This type of application-embedded color management is not new, nor unusual. This is also used in applications like Photoshop, Corel Draw, even The Gimp and thumbnail browsers. It is very powerfull and allows a much greater control on the graphics output appearances when used properly. But using it properly requires a little bit of knowledge. That is why I plan to write a tutorial.

3D application renderers like A:M renderer are engines that compute the appearance of light that falls on 3D models. The resulting lighting calculation are linear in shades. This linearity in shades is one visual characteristics that says "CG". Lights are bright and shadows are very dark and contrast is high with a sharp falloff and color are saturated.

Actually, the CG look does not comes from the linearity in shade of the renderer. It comes from the non-linearity of the monitors on which those rendered images are displayed. Renderers have much in common with CCD image sensors that are used in digital cameras which are also linear shade devices. Displaying a digital photo that comes directly from the CCD sensor on a monitor shows the same bright lights with dark shadows, with high contrast and saturated colors. Recognizing that fact, the digital photographic equipment industry have adopted the sRGB standard which specify that a digital photo should be color corrected right inside the camera so that the jpeg files that comes out of the digital camera can display correctly on a normal monitor. The default sRGB color correction is at least a gamma correction of 2.2. However, each digital camera manufacturer design their own transfer curves.

Here is a photo. The bottom one comes directly from the CCD image sensor in the camera and the top one have a gamma correction of 2.2.
Click to view attachment

To try to manage lighting in 3D scenes so the illumination looks more natural, requires that additional fill lights are added to the scene to soften shadows and contrast falloff. But a gamma correction of 2.2 would give a more acceptable result much more easily and much more accurately. More fill lights can be added for artistic reasons but working with a gamma correction of 2.2 fills a good way in.

Here is a simple scene rendered in A:M. The bottom one comes directly from the renderer and the top one have a gamma correction of 2.2.
Click to view attachment

And here is a more complex A:M rendered scene. The bottom one comes directly from the renderer and the top one have a gamma correction of 2.2.
Click to view attachment

Since there currently are no consensus on which gamma correction we want to use on final TWO renderers, the preview gamma correction properties should be set to "desired gamma" : 1.0 for now. As for the "Monitor gamma", your choice, you can leave it at 2.2 and you will get previews like in v13 and previous versions or you can adjust it to match your monitor and you will finally see the preview renders like most A:M users see your renders when posted on the forum.

That`s it for now.

What is recommended for an LCD monitor?

Thanks Yves, I am looking forward to reading your tutorial about this important yet still elusive topic.

By the way, on the simple image of the primitive shapes above, did you also use AO mixed with the lights?

It greatly depends on the quality of the LCD monitor and wether it is a laptop monitor or a desktop monitor.

Laptop monitors are pretty much hopeless in term of calibration and gamma setting. Just leave them to their manufacture setting and assume a gamma of 2.2. The reason they are hopeless is because of the technology used to light them in such a thin space. If you look at your laptop monitor and move yourself up and down so you see the monitor from different vertical angle, you should see the image colors varying as you move. This is called vertical anisotropy. On some cheaper laptop monitors there even comes a point where the color contrast gets reversed. For this reason, laptop monitors are uncalibratable. Even if you were to keep your eyes at the same level all the time, there would still be a difference in gamma between the bottom and the top part of the laptop screen. Even higher quality laptop monitor such as on a MacBook Pro does that.

Desktop LCD monitors have a much better lighting technology because there is much more space behind the screen. But even on desktop LCD monitors, there are some cheaper ones that have the same issues as a laptop monitor. So you have to determine if your desktop monitor have this issue or not by doing the vertical head move test. It is better to do the vertical head move test while a gamma chart is displayed on the screen. This way, the vertical anisotropy of the monitor becomes very obvious. So if the desktop LCD monitor have the same vertical anisotropy issue, you must consider it uncalibratable, leave it at its manufacture setting and forget about this whole gamma setting thing.

Fortunately, there are several good desktop LCD monitor that are very stable colorwise and do not show any vertical anisotropy. Those monitors comes with different manufacture set gammas. Most of them set the manufacture gamma to 2.2 to comply with the industry standard. Some desktop LCD monitor have a manufacture gamma different than 2.2. In any case, a good calibratable desktop LCD monitor gamma should be set to 2.2.

The most important fact to understand is that the industry is standardizing on gamma 2.2. It started with the digital photo industry a few years ago, immediately followed by scanners manufacturers and now pretty much every image producing equipment is geared for a monitor with a gamma of 2.2. Content producers are also gamma correcting their images and clips so it will display correctly on a 2.2 gamma monitor. So, because of that, if your monitor is not already set to a gamma of 2.2, it should preferably be set to 2.2.

The A:M "Monitor gamma" property in the render option pannel does not change your monitor gamma. It only tells A:M what is the current gamma on your monitor. If you want to change your monitor gamma, you have to use the graphics card color management widget, the Adobe gamma that comes with Photoshop or a standalone gamma adjustment utility.

No AO at all in the primitive scene render. Just normal A:M lights.

See what a simple gamma adjustment can do to a render?

That's interesting. I'm pretty sure that it used to be 1.8.

Yves, I can definitely see why this is such an important issue. The scene with the lighter gamma is looks much better than the one without, and does a lot to eliminate the telltale "cg" look that you speak of. As you point out, it gives the impression of more ambient light in the scene and thus made me think that AO was used. This is certainly something that we need to pay attention to – something most useful indeed.

A few questions arise.

1. Assuming there is no way to verify what a monitor’s gamma truly is, and therefore we assume that it is 2.2, are you saying that the gamma settings in A:M should all be set to 2.2 to achieve this more natural look.

2. If one changes the gamma curve from 1.0 to say 2.2, does the A:M render engine render the new gamma into the pixels, or are the linear values rendered linearly as before, and the gamma setting only applies to the “viewing” of the image.

3. Related to above, if one opens an image rendered with gamma 1.0 into photoshop and changes the gamma to 2.2, does this do the same thing as setting the gamma in A:M?

4. What is the gamma in the Photoshop working space profile sRGB IEC61966-2.1?

5. What is the gamma in the profile Adobe RGB (1998)?

6. Where is the Adobe gamma utility that comes with Photoshop located?

Hope I haven’t bombarded you with too many questions, but there is no doubt that color management is a crucial theme in all of computer graphics and we must educate ourselves further along these lines (in my opinion).

Thanks,

Joe.

If you really can't determine your monitor gamma, then you must assume it is 2.2. In this case set the "monitor gamma" property to 2.2 in A:M. That would be the case for laptop LCD screens.

Usually, for good quality monitors, LCD or CRT, you can determine the monitor gamma with the gray swatch that is used for the "Monitor gamma" property in the "Render" tab of the "Option" dialog. When both side of this swatch looks the same gray, then the value indicated your monitor gamma. As I mentioned earlier, however, this property will not change your monitor gamma. If you want to change your monitor gamma, then you should use one of several gamma charts that are available on the Internet. Personally, I would recommend using Norman Koren Gamma chart. Just follow the instructions on his page.

If you change the "Desired Gamma" from 1.0 to 2.2, then this will only affect the preview renders. Not the final render. The final render will still have linear luminosity values. If you want to add gamma correction to your final render, then you must explicitly do that in the final render to file option pannel. Select "NTSC/sRGB" gamma and you will get a gamma of 2.2.

The reason for that independance is that you may plan to publish your final render with a gamma 2.2 but you may not want to do the correction directly at render time because you may want to composite that render or do further post processing on it before adding the gamma correction. When compositing or when doing post processing, it is preferable to do that on linear light data and apply a gamma correction only after all composition and postprocessing steps are completed. However, because you plan to publish a gamma corrected render, you will want to adjust the textures and the lighting so it looks good on the final gamma corrected render. That is why you can select to see your preview renders with a gamma correction on them.

First, you must take into account that Photoshop does use color management internally already. So this must be taken into account when painting textures or when post-processing rendered images. I plan to cover those aspects later. For now, if you open a 1.0 gamma rendered image in photoshop and change the gamma to 2.2 in "Image"->"Adjustment"->"Levels", using the middle slider, and save that modified image, then you have visually the same effect as adding the gamma in A:M.

There is one very important difference though. If you apply the gamma correction in Photoshop (or any other image processing application) on an 8-bits per channel image, you will lose image information. If you plan to apply a gamma correction in any outside application, you should save your render in a 16-bits format or better yet in OpenEXR format. This way, when you apply a gamma correction, you will not loose any color/image information. If you don't plan on post-processing the image or composit it, then it is better to add the gamma correction right from A:M.

Color profiles are designed to correct the particular color characteristics of a particular physical device. Each physical device have a particular color space or gammut and a particular white point and a particular set of transfer curves. Color profiles are designed to correct whatever comes in from a device or goes out to a particular device so it matches a standardized virtual color profile. I will not get into the details of that. But because there is a standard virtual profile, it is possible to transform to and from this standard profile to match any physical device and ensure that colors match from devices to devices. Example, from a scanner to a paint application to a color printer.

Color profiles are considerably more complex than gamma correction. Gamma correction is a cheap way of doing color management. But gamma correction works well in 3D CG because there are no physical graphics devices involved in producing the image so there is no need for a complex profile.

Concerning the two profiles you mention, I don't know the details of their characteristics. And anyway, color management in Photoshop is quite another beast to fight and I don't plan to cover this aspect here. I plan to describe a workflow using Photoshop and The Gimp that is suitable for producing texture for A:M given that the final render might be gamma corrected and I will give a Photoshop profile and a The Gimp procedure specifically designed to do that. While doing that, I will describe some aspects of Photoshop color management but I don't plan to explain further that what we need for texturing.

It should be in the Windows control pannel.

For a long time, there were no industry wide accepted gamma standard. Apple made their own gamma standard to be 1.8 and for a long time, every Macintosh had a gamma of 1.8 from manufacturing. There were no other standards so I guess gamma 1.8 came to be known as the standard.

The main reason why 2.2 became the true standard is only because of the number of users. The CRT itself that is used in CRT monitors have a gamma of approximately 2.5. Traditional electronic circuitry non-linearlty characteristics that drove those monitor made it approximately equivalent to 2.2. So a CRT monitor that came out of the manufacturer have a gamma of approximately 2.2. There are way much more computer users that use normal CRT than Mac users. Actually, even Macintosh CRT monitors had a gamma of 2.2. The gamma of 1.8 was corrected through the color lookup table in the Mac OS software which actually resulted in loss of color information between the application and the screen.

So when the digital imaging industry representatives sat down to design the sRGB standard, they considered the economic side of the situation. It is much more economic to settle for the most commonly used monitor setup around the world than to design a standard that would require that almost every monitors in the world be modified or replaced. Simple as that. This sort of economic desision was also taken when television was first designed. It was considered that it would be more economic if the gamma correction was implemented in the cameras instead of inside each TV set because there are much less cameras in use than TV sets.

BTW, even the Macintosh OS X does not force the 1.8 gamma correction anymore. The Mac OS, like every othr OSes now use color management.

Thank you for clearing these things up. I still need to study your words carefully over the next few days and look forward to your tutorial, whenever you have the chance to do it.

Joe.

Yeah...that's a LOT of reading.

Off the topic... COOL! I'm doing an overnight render in V13.0S and I figured I'd also do the same in 14.0Beta3. The V13 renders are taking an average of 4:12 (4 min 12 sec) and the 14 renders(all the same settings; shadows refs ON, 5 level multipass) are taking 3:09!!!

That's quite a nice improvement!

Wow, Yves! Are you half Vulcan?
That was very illuminating. Thanks!

Oh No! That was not supposed to be disclosed!

Okay. Here I go again. I should know better than to use a Beta release for my projects but I was tempted by what seems to be better hair and SSS in A:M14.

A:M just ate my model! Completely consumed and digested it, leaving absolutely nothing behind! The model file is now 0 bytes!
That is alot of hours down the drain again.

Click to view attachment

The frustrating thing is that the exception occurs and then A:M reports that it is about to save the file, and that it may be corrupted, but there is no way to stop it saving.
Couldn't we have a cancel button or have A:M add an extension to the filename instead of overwriting a good file with a corrupt file?
How about if A:M always saves a temp file first and if no exception occurs the "temp" extension is removed and the file is allowed to over-write the previous version? Or an incremental save button.
-----------------------------------
Edit:
Phew! It feels alot safer back here in A:M13s.
A:M14 has some great things going for it but, MAN, it's a mine field in there at the moment!

Paul, are you pleasing yourself with the 'vulcan'-bits?

Yves, I didn't read your 'so many words', but...
The 'realworld' spectrum IS a standard and as it comes also with dark and light...
Colorprofiles are made for every seperate device to determine what colours they actually CAN display(/or print)
Since most if not all devices can only display a part or even a small part of the full 'realworld'-colourspectrum.
To keep the WYSIWYG* from e.g. computermonitor to xxxxx-printer, the profiles are calculated against eachother.

Hope this helps.


ps.
*WhatYouSeeIsWhatYouGet

Yves, if you wonder, what 'dark' and 'light' is...
There has been a standard-unit set in Calvin(degrees) at a particular time of day.

It is not quite so simple as that. Of course, it all starts with a spectrum of wavelengths with intensities known as SPD for Spectral Power Distribution. But to make a standard, you need a way to represent realworld colors. A representation that everyone agrees on. This standard is the CIE (Commission Internationale de l'Éclairage) XYZ color space. Color is color only because of the way, we perceive it. For instance, we do not perceive color from X-rays even though they also have SPDs. So CIE have mapped the human perception of color into a mathematical representation called the XYZ color space. And this is the standard color space (or profile) I was mentioning. This is the standard that every color profiles must relate to.

Yes. But that is not all. It is true that a device can only represent a limited set of colors. This is called the gamut. But also a device usully will not map colors in a linear manner. That is send a value of 0.5 to a device, it will not necessarily display or print an effective tone 50% it should represent. This also needs to be compensated. A color profile not only contains the gammut limits but also a set of transfer curves that can compensate for the non linearity of the device. And if the device also have an intrinsic color temperature offset then this must also be compensated.

All this said, I think that level of technicalities is totally irrelevant to the current Gamma correction discussion. So I won't go nay further than that into those technical discussions.

It was simply meant as a compliment.

Psssst, Yves..., not everyone uses CIE, but to what they all relate to?



It seems that you 'limited' my words of 'calculating against eachother' to gamut, not me!




Why did you?

This is a relevant point. Any light does have a particular color temperature. Digital cameras have several photography modes such as incandescent, fluorescent, cloudy, sunny, etc., that are designed to compensate for that. I plan to discuss that a little bit further. When taking digital photos for texturing, using the proper mode is important. But this is OT here since this is not related to the beta release and the gamma properties.

Yves, if you want to flatter yourself:
Build a pyramid, make sure it doesn't tumble by construction or by GOD


ps.
Did you notice, I've taken all your words seriously from the start?

To clearify: You do know 'dark' and 'light' are related to gamma...

Yes. But through the alpha and the omega.

U have 1

Yves,

I checked the gamma on one of my monitors, and it was definitely 1.8. I applied a 1.8 gamma correction on a frame in Photoshop, and the result was much better as you point out. I will probably do all gamma corrections to the movies in After Effects and leave the original renders linear as you suggest.

Would you kindly explain the following quote by you just a little bit further as to why 16 bit or open EXR formats loses less information vs. 8 bit?

Thanks,

Joe.

An 8-bits image holds only 256 level of values in each of the red, green, blue channels. The gamma correction will warp those values to another set of 256 values. The most dramatic warping occurs in the dark areas of the image.

Here is a gray gradient. First when it is linear gradient and after a gamma 2.2 have been applied.
Click to view attachment
The bright portion of the gradient vary more slowly and the dark portion of the gradient vary much quickly.

Here is a set of transfer curves I did in Photoshop "Curve" operator editor.
Click to view attachment
The first one is a traditional Gamma 2.2 curve. Following that, is the curve from the Nikon Coolpix 5700, the curve from Photoshop RAW that is used when loading a camera RAW file in Photoshop, then the curve from Breeze Browser, an application I use to manage camera RAW files. I included the other curves to show that every application or digital camera does a color correction similar to a Gamma 2.2.

But let's concentrate on the Gamma 2.2 curve. It is obvious, from that curve, that the most warping occurs in the dark colors. The line of the curve is almost vertical in the lower-left portion of the curve. This is consistent with the change in the variations on the gradient above.

Here is a set of histograms I grabbed from Photoshop "Level" operator.
Click to view attachment
The first one represents the linear gradient. Every gray values are equally represented.

The second one represents the result of applying a gamma correction to an 11-bits image (I cannot do that with a 16-bits image because it would require an image 65000 pixels wide to represent all the possible values). It shows that there are more values in the bright part of the image which is consistent with previously observed.

The third one represents the result of applying a gamma correction to an 8-bits image. Note the large gap of unused values in the dark values.

The fourth one represents the result of doing a gamma 2.2 correction using the Photoshop "Level" operator middle slider. Photoshop does not apply a true gamma operation because it tries to minimize the loss of data in the dark values. But even if it tries to minimize the loss of data, there are still several gaps of unused values.

In fact, after a gamma 2.2 is applied to an 8-bits image, there are exactly 20 (I mistakenly wrote 26 in the illustration) values that are not used between the value zero and the next darkest value which is 21 (out of 255 possible values) and thenthe next values are 29, 35, 39, 43, etc. The gaps get closer and closer untill around the value 100. This is quite a loss. This means that any shading details that may have been visible in the shadows are lost.

When you use a 16-bits file, you have 65535 levels of values. In other words, there are 255 levels of values between each step values in an 8-bits image. So after the gamma is applied, there are a possibility of 255 more values that can fill the first gap of 20 missing values. OpenEXR is even more precise than that.

This is a technical issue nd it is difficult to explain but I hope this answered your question.

Yves, it's wise to tell someone who seriously wants to deal with colours that, most if not all LCD/TFT have a smaller spectrum than CRT, and the gamma will change every time you change perspective.

You also did know that the light surrounding one, should be kept equal or perception of colours will change as well; Not handy when you want to 'edit'.

You should read the previously posts. You would have note that this was already covered.

Would you be so kind to tell me, which letter, alinea and sentence?

Anyone really serious about monitor calibration. should buy a calibration device such as the Pantone Huey that can adjust the monitor dynamically as the ambiant light changes. And the Huey also profiles the monitor and creates a profile that application such as Photoshop can later use. Personally, I use a Huey and I recommend it. But even if I recommend it, I don't think it is absolutely necessary for the work we do on TWO for instance. The minimum step to take however, is to follow the adjustment procedure described by Norman Koren from the link provided in a post above to set the monitor to gamma 2.2.

See my review of the Pantone Huey

"We're" not really talking about me..., but yes, I have experience with monitor and paper calibration-devices, it 'generates' a monitor-colour-profile and from an paper output, a printer-colour-profile. After the calculation, according to this device, it kept telling purple is the same as blue...

No, thank you.

I want to make sure there are no confusions.

If your monitor have a gamma of 1.8 and you apply a gamma of 1.8 then you will see the image as it would look like if it was gamma corrected at 2.2 and watched on a monitor with a gamma 2.2. But it is important to understand that if you publish your image or your movie gamma corrected at 1.8, then only you or anyone with a monitor G1.8 will see it correctly. The vast majority of computer users with G2.2 monitors will see it too dark. You still need to apply a gamma correction of 2.2 to your image or movie if you want to publish it.

But here is the catch for you. If you keep your own monitor at G1.8 and look at G2.2 corrected images or movies, they will appear too bright. You need to be aware of that if you want to keep your monitor at G1.8. This is something that have been confusing the whole gamma correction issue for years now.

IMO, you would be better if you adjusted your monitor to G2.2. I have a BenQ LCD monitor that was G1.8 from manufacture and I atached a Huey on it and let it at G2.2 now. Less trouble figuring how the other users will see my images. And I also have a MacBook Pro with a large HD display attached to it and I just checked the HD monitor gamma and is is set to 2.2. Even Apple does not set its monitor to 1.8 anymore.

I was using "you" in a generic way. But I edited my post to remove any confusion.


Yes. This can happen if the two devices have very different gammuts. Then some colors on one device just cannot be reproduced on another device. This can be particularly severe between RGB devices that reproduce color additively such as a monitor and CMYK devices that reproduce colors subtractively such as a printer. Photoshop have a "check gammut" mode to verify that.

This said, I can't say that the Huey is absolutely perfect but it is still way more reliable to match colors with it than when I adjusted my devices manually and visually. And adjusting the devices manually and visually was still more reliable than not taking care of any calibration at all. Also, the modern OSes like Windows XP, Vista and OS X, all include APIs to do and use color management and more applications uses those APIs now especially the application that must deal with images and movies. Color management is becoming mainstream and should greatly ease that aspect of the working environment that used to requires expensive equipment and expertise just a few years ago.

When I CAN show a particular color on a monitor-device and as well as on a printer-device, they still could have different gammuts.
When a calibration-device can't colormatch, it's the two-colourprofiles made AND/OR the calculation that can't.
This of course considering monitor-light versus paper-color and paper-tint.

Yves, once again not only have you cleared many things up, but exceeded expectations while so doing, such that several new areas of consideration have opened up, some of which spawn new comments or issues of clarification.

First, Although I understand that the color range of 8 bits per channel is much narrower than 16 bits, I have often wondered whether you could see the difference on your monitor since the video card is only delivering 24 bit color. In other words, could you see the difference between a 16 bit image and an 8 bit image on a standard RGB monitor unless perhaps you had a 16 bit video card? Or would the subtleties of 16 bit color be thrown away by the lower depth of your monitor? Am I flawed in this thinking?

However, from your comparison of histograms above, I can see that working at a higher bit depth provides more intermediate values between the value of lets say 0% and 25% of the levels between dark and light, obviously a benefit. But, if one were to convert the image back from the higher bit depth to 8 bits after applying a gamma curve, would the histogram would be improved with less gaps than if one applied the gamma curve while in the 8 bt color space? (thus resulting in a better 8 bit image).

Furthermore, this brings to mind another related question. A final product may be viewed in one of several formats. It may be viewed on a computer screen, it may be viewed on an HD television, or it might be viewed on screen in a theater by either a film projector or a digital projector. If it is viewed on a computer screen, we can all assume that it would be viewed in 8 bit (2.2 gamma), unless they have started making 16 bit video the mainstream.

But if it is viewed on an HD television (for which I am no expert, but assume the signal is digital) then what is the bit depth of that device? And furthermore, what should the gamma be? If it is viewed in a theater (either by a projecting a roll of film or by a digital projector), then what depth/gamma is used there? Obviously, in the case of a piece of film there is no bit depth, however what bit depth/gamma does a film recorder use during the transfer from digital? If all of these depths are higher than 8, then would it not benefit us to work at the correct bit depth and the proper gamma for each desired format we plan to publish in?

Would it also make sense to think of this as a proper workflow: Renders from A:M can be previewed at Gamma 2.2, but final renders would be done with G1.0 (no adjustment) at 8 bits per channel (as far as I know, A:M does not render at 16 bpc, does it?). Raw frames from A:M would then be imported into the compositor/Finisher (such as AE, or Flame, etc.) and the bit depth for the project would be set at 16 bits. Final compositing, 2D effects, and of course gamma curves could be applied here within this bit depth based on the final outlet of the project. Final renders could then be generated with specific gamma curves/bit depths as needed. What do you think of this approach?



I see your point clearly. If the world is going to be using G2.2, then you should publish your renders at 2.2 and make sure your monitor is 2.2. Just a quick question here, I opened the Adobe Gamma control panel on my laptop and noticed that the description was set to sRGB and the Gamma was Window default 2.2. Does this mean that my monitor is set to 2.2? By changing the value there, does that change the gamma of my monitor?

Once again, thanks for the great wealth of knowledgeable information.

Joe.

You are right. One would not see the difference between an 8-bits image and a 16-bits image when displayed on computer screen because of the vieocard.

Yes. That is exactly the point of my demonstration. The idea is that we don't really care what is the format of the final image. It will very probably be an 8-bits per channel RGB format but it could just as well be an 8-bits dittered gif format. We don't care. What we care is that while we work on that image, we keep as much information as possible. And then, only after all the post-processing operations are all completed, we convert to the final format.

You really don't need to care about supplyin the image in an 8-bits or 16-bits format. Once your image is all color corrected, then you can supply it in 8-bits format. That is what everybody expect. If you submit your image for a particular media or application that requires a different format, then someone at the other end should inform you on the technical details.

As far as gamma correction is concerned for film media, every film stock have its own transfer curve and this can be obtained from the manufacturer. This said, unless you have your own digital to film transfer equipment, you shouldn't worry about that. There again, someone at the other end should assist you. Normally, they have a whole set of processes to convert from digital to film and that includes the proper transfer curve.

If you plan to transfer to film however, you should save your images in OpenEXR. The film industry don't use targa or an other 8-bits per channels file format except to prepare graphics. They use a much more sophisticated formats, such as Cineon and now OpenEXR. OpenEXR was developped by Industrial Light & Magic to replace Cineon. Although you can save gamma corrected images in OpenEXR, this format is specifically designed so there are no color correction added to the images it stores. The image data should be strict linear and any color correction should be applied when the images are transfered to a particular media.

No. Not as 8-bits but as 16-bits or as OpenEXR.

Yes it does in PNG format.

No. That would gain very little. That would minimize the errors, up to a very limited point, while you apply post-processing but it would not allow to fill in the missing color information that a native 16-bits format would supply while doing the post processing. If you start with an 8-bits file format, the color aliasing is already present and converting that to 16-bits will only get an image with the same color aliasing even though it is now 16-bits. There is no way you can retrieve the missing color information from an 8-bits image file..

No. Adobe Gamma does not really know how your monitor is set. It assumes it is set to the standard which is sRGB with a gamma of 2.2 and that is this assumption that is displayed. It is your responsibility to adjust your monitor so it actually matches this assumption. You do that by moving the sliders. Not by changing the 2.2 value that is displayed in the "Desired" edit box. Actually, it is easier to use the Adobe Gamma wizard and follow the instructions.

Changing the sliders does change the monitor gamma. Changing the 2.2 value just changes Adobe Gamma assumptions.

Thank you. Based on your excellent comments, a few followup issues:



I have heard of OpenEXR. I believe I remember that it was useful for the ability to render seperate alpha channels for each light so in a compositing environment, one could alter those light values. Have I remembered correctly?

- Are there any other benefits to using OpenEXR, besides that, extracting from previous comments, it renders at 16 bpc?

- Are there any other special considerations when rendering to OpenEXR from Animation Master?

- Is there lossless compression applied to OpenEXR?

- Is there any similarity between OpenEXR and say, RAW? Or am I totally off-base here? If so, please ignore this question.

Therefore as far as I understand it, and based upon your posts, the proper way would be to render our animations with linear pixel values as OpenEXR files - one file per frame (which will provide 16bpc, and which I gather from your statements would be better than 16bpc PNG files). No gamma adjustment would be built in from Animation Master (except for previews) but would be applied in post as needed, depending upon the final requirements. Final renders can be delivered at 8 bits. Have I finally gotten it right?

Just one last thing. Why do monitor manufacturers put gamma on their monitors anyway? If you were to render an image linearly or take a picture straight from the sensor of a digital camera without applying a gamma curve and display it on a linear monitor, I am assuming everything would look peachy. If you wanted to boost the gamma in addition, you could always do it. So why the monitor gamma?

Thanks again.

Joe.

When we introduced the use of OpenEXR in A:M, we did that mostly to allow compositing and that is the way we discussed OpenEXR. We selected OpenEXR because it is a file format with several intersting characteristics for compositing. Among those, it can store as many layers as needed and as many channels as needed. It also allow to structure the layers as we need.

OpenEXR can store channels (or layers, there is no distinction between layers and channels in OpenEXR) in 8-bits, 16-bits, small-floats and floats per channel. We store the channels in small-floats which is a floating point representation in a 16-bits format because Small-float is much much more precise and wide than simple 16-bits.

First, while there can only be 256 intermediary 16-bits values between the zero and the next first value (1/255) of an 8-bits format, there is a quasi infinite values that can be represented in a small-float between those same two 8-bits values.

Second, 8-bits and 16-bits are restricted in the range of values it can represent. They are Low Dynamic Range (LDR) format while OpenEXR is an High Dynamic Range (HDR) format. We can store illumination values, in an OpenEXR format, that may be way much more brighter than white. For some post effects, like a bluring, storing brighter than white values can make a huge difference in the final result. Not only that, but if you expect to modify the contrast or the exposure on your shot, then having HDR data can save your day.

I don't see any. You don't need to output all the light and properties buffers if you don't plan to post-process them in A:M composite. You can just output the image in an OpenEXR file just like you would do for an TGA or PNG file. I do that all the time.

Yes. It is the default.

Not really. RAW is a generic format name. It just designate files that are produced by pro or semi-pro level digital cameras that contains data as captured by the camera image sensor and unprocessed in any ways. Each digital camera manufacturer have its own set of RAW formats.

Yes. That is correct.

They don't add any gamma to their monitors. It is just the nature of the beast. The functioning of the CRT electon gun itself is the biggest part of that, plus the electron gun driving circuits. LCD monitors don't have the same intrinsic gamma curve. They have a different transfer curve. The driving circuitry are more sophisticated but the final gamma curve was designed to match the CRT gamma curve for complying to the standard.