Here is one of Aiko3. Used cycles shader for the skin. The hair ( Dixie Hair ) used the old Firefly shader. The dress I converted to use cycles shaders, but didn't do anything special with it. I used two lights, an area light above and a spot pointing at the character.

I seemed to lose some saturation when I exported the image, so I adjusted in PS.

Here's one of my attempts using the Cycles shaders and SuperFly. I got some initial ideas for a skin shader for Blender and Cycles from the Web. I applied my tweaked version to Mk2, using image maps from one of the texture sets in my library ( LiuYan character, to be exact ). I don't have any decent bump map images for Mk2, so the skin looks a bit unnaturally smooth.

There's a single area light above the model, and a spot light forward and to the right of the character. I didn't do anything special with the hair, so that's still using the Firefly materials.

On the Mac, you can use the 'Disk Utility' app ( inside the 'Utilities' folder to create a blank disk image as a file. You set how big you want the file ( how big you want the disk ) and if you want it encrypted. You'll be asked for a password when you double-click on the file to mount it. You can put an external runtime and any other private assets on that image. Once you 'eject' the image, no one can load it again without the password.

-Stan

"no, CRTs do not natively support the sRGB spec.  they are however altered to support it.  LCDs do natively support it.  as do cameras and scanners."

What I was referring to was the hardware aspect. In a CRT, increasing the voltage to the electron gun does not result in a linear increase in luminance. So a channel value of 128 ( for 8bit channels ) does not display as half-brightness, but rather as something slightly dimmer. Because of the natural physics of the electronics, the CRT is acting as a 'gamma decoder', as pointed out in the Wiki page. In order for the image to display the proper luminance values, the linear image needs to be 'gamma encoded'. An LCD does not naturally exhibit this behavior, so the electronics emulate it. On many LCDs, the gamma decoding value can be set.

As for colorspaces, here's a page that has a nice explanation of the relationship with sRGB and gamma.

You know, things were so much simpler before computers. I get a photo printed, hand the print to you, and I could expect that the image on the print didn't change during the exchange.

A simple way for me to understand GC and the need for it is with basic math. A pixel in an image is represented by three colors: red, green, and blue. Each color has a value between 0 ( black ) and 255 ( full brightness ) when represented using 8 bits/pixel. The problem is that CRT monitors didn't display the values linearly. If you had a red pixel with a value of 100 and another with a value of 200, you would expect the latter to be twice as bright as the former. This is not the case and while the extremes display close to linear, the midtones display dimmer. GC adjusts the colors, not by brightening the entire image, but by adjusting the different tones by the amount necessary to make them display linearly. As I understand it, LCD monitors do not suffer the same problem but are built to emulate it since everything out already accounts for it.

In a linear workflow, the texture maps need to be uncorrected because if you do a final correction during the render, those images will have been corrected twice giving it a washed out appearance.

As for my own renders, I use GC and also try to restrict myself to three lights in a scene.