Finally all render/compositing jobs are done and I have now the full 1080p footage ready.
I still do have the intermediate multilayer renderpasses for each shot, in case there is the need to revisit some compositing tasks. The storage demand is quite huge for these (a single frame typically has ~140MB) , but it already saved me a lot of time and trouble. I guess I will only delete them once the movie is eventually released 🙂
The compositing pass creates the final frames which are delivered as OpenEXR files. Here we typically have 23 MB per frame.
I did some intense testing and exploring on how to best tackle the color grading workflow. As I now did a very close look to the whole color behaviour, I noticed that initially I had wrongly calibrated my monitor and had done the primary color grading in the compositing on a display with a gamma setting of 2.4. That means, that on a correctly calibrated display, the movie displays too bright and flat.
My initial idea was to apply the appropriate gamma correction in blender, but as already mentioned in my previous post, I decided to try out DaVinci Resolve Lite. The new problem that this did create, was that I had to switch to Windows to work with this software. That in itself wouldn’t be a big problem, but I soon found out that the display driver under Windows acts quite differently to the one under Linux. In fact I didn’t manage, to get the same color dynamic under both OSes. I got the gamma setting ok, but for the white and black point I had absolutely no chance to get it to work correctly under Windows. The solution would be of course do buy a real hardware calibration tool, but that is not an option right now and I have to find an other way.
This different behaviour made me a bit uneasy and I did numerous tests on both platforms to learn how these differences show in the final color grading. That was when I learned that my monitor has a gamma drift over time. When freshly turned on, I need a correction of 1.20 and after 4-5 hrs I am down to 1.05.
What I do now, is to constantly check the actual gamma value ( using the cool test images at http://www.lagom.nl/lcd-test/) and apply a correction if necessary. Its a bit tedious, but with this I get relatively reproducible results.
What got me a bit frustrated were the tests I did on my 40″ FulHD TV. It provides a load of settings, none of which seems to have anything to do with a gamma 2.2 setting … Most settings have blown out highlights or oversharpening. The 100Hz feature destroys completely the movie feeling. I really wonder how this movie will look like on the various displays when eventually released. This is something that is completely out of my control.
Anyway, for all those interested, I have a 2 shot sequence in 1080p for you to download and look at. I would really be interested how this sequence looks like on your individual display. With a correct gamma 2.2 display, you should see a relatively dark movie with stark contrast, but there is no completely black area. You should still be able to see features even in the darkest spots. But these dark spots should really be dark and not misty white washed. Please have a look and tell me how your viewing experience is and what display settings you have.
Hi Martin,
I’ve checked the clip on my macbook pro, and it looked a little washed out with the default monitor profile. I set up a custom profile with new calibration and set the gamma to 2.2 and it looked much better, crisper colour and deeper shadows. I think the default gamma on macs is 1.8. Hope that helps!
Thanks a lot Todd.
Yes the Macs have a default of 1.8. Do the Macs play every content on a 1.8 gamma ? Or put another way, do you have to make adjustments for any other movie ( e.g. sintel, BBB etc ) ?
Wow looks real nice man 🙂
Not quite sure what to make of this, but on my MacBook Pro (Snow Leopard) during the first several seconds, during the ECU shot of the cage, I see some kind of, perhaps, a compression-artifact going on in the vertical bars of the cage … the top half of the bar, so to speak, jumps slightly ahead of or behind the bottom half. It’s just a little “ragged” obviously-digital effect but it’s unfortunately distracting. I’m certain it’s not in the render files, but it does appear in this MP4 print.
Thanks Mike for taking the time to report on this.
I have seen the effect you describe on some occasions now, but on my system it was always the problem with the playback engine/computer system. If I look at the generated h264 file on a frame by frame basis, I do not see any such artefacts.
For me this artefacts looks like a problem in getting the image fast enough into the video frame buffer. This effect was onyl visible as soon as I switched to 1080p. At lower resolutions there were no problems whatsoever.
I guess you are using the quicktime player. Could you try out another player or if it is possible for you to look at the file on a frame by frame basis ? Reports from others indicate that the quicktime player has some serious problems displaying this type of movie files correctly.
Though the test sequence appears adequate with the default gamma value of a laptop running Windows XP, I am inclined to regard a slight reduction of gamma (approximately 0.2) as more appealing. Furthermore, I have noticed a slight flickering upon the background rock face within the second shot; however I am unsure whether this is a universal issue of the sequence, due to consistent issues relating to the display of blacks and shadows by my laptop’s integrated graphics card.
Thanks Nathaniel for reporting back.
The flickering you notice is a problem in the render. The particular use of high frequency textures, especially for the bump/normal maps do unfortunately create these artefacts. To fix this I would have to retexture the cliffs, and this is something I will not do at this stage :).
This will remain one of the countless little problems left in the movie for the attentive viewer 😉