By Tom Dow (Thelocknar) (24.165.252.166) on Saturday, January 18, 2003 - 04:19 pm:

Since Film Gimp handles 32 bit images, I reasoned that it could be used to create HDRI images for use with lightwave. I decided to play around with it a bit, and achieved some limited success. If anyone has been able to get it to be fully functional, please let us know.

Here's the low down: Film Gimp can edit HDRI images. I opened a lightprobe image in Film Gimp ("cami.hdr"), and was able to mess with the exposure and gamma. Standard paint tools don't seem to work, they probably are limited to 8-bit color, but the dodge and burn tools work fine.

The next step was to create a new HDRI. I created a series of bracketed exposures, saved them as 8-bit png's. Opened each one in Film Gimp and converted it to "float" color. I then stacked all the images on top of each other, in separate layers, by copying and pasting with the darkest image at the bottom. Set the mode of all but the bottom layer to "multiply". It helps to have layer visibility turned off for this step, since Film Gimp is particularly prone to crashing right here. Finally I did a "layers -> merge visible layers" (or was it "flatten image"? I can't remember), and save the result as an uncompressed TIFF. The image responds to exposure changes like a HDR image, and has colors that range from 0 to 1 with 6 decimal places. I can only assume that it is an HDR image. The only problem is that I can't open it in Lightwave!

Anyone else want to continue the experiment?

By Beam Tracer (Beamtracer) (203.109.241.109) on Saturday, January 18, 2003 - 04:47 pm:

Are you sure it was a 32bpc image you saved? It sounds like a 16bpc image. Maybe I'm wrong.

Also, does Lightwave support the importation of 16bpc TIFFs? I know it can't render to 16bpc TIFFs. I wish it could!

By Tom Dow (Thelocknar) (24.165.252.166) on Saturday, January 18, 2003 - 06:47 pm:

Film Gimp reports the image as 32 bit RGB. According to the Dan Alban book, Lightwave supports "TIFF LogLuv", whatever that is. Not RGB color, I guess.

By arthur argote (Archiea) (68.164.65.7) on Sunday, January 19, 2003 - 01:46 pm:

Tom...

Nice experimentation. Where I have my doubts is both what Film Gimp describes as "float" and the fact that the values of your final images were from 0 to 1....

What Film GIMP describes as float is the ability to break down values from 0 to 1 into several decimal points for precision. I believe that it truncates the data above 1 and below 0. For your compiled image to have HDR values, the high number should have been in the hundreds or thousands instead of just 1.

Typically TIFFS, at least from shake, can retain Float values beyond 0 and 1. The Tiff LogLuv is like a cineon... it truncates at 0 and 1 but puts the untruncated data into a log curve. Thsi is one way to "compress" a float image.

I'll look into this, though...

By kenneth woodruff (Kenneth) (12.236.254.153) on Friday, January 31, 2003 - 12:30 pm:

I finally got Film Gimp installed last night. I had some X11 trouble. At any rate, I apparently still do, since Film Gimp crashes constantly.

I had it open long enough to see that it does indeed support the .HDR format, so why not save in that instead of TIFF LogLuv? TIFF is much more of a grab bag of options and features, and who knows what flavor(s) are being added to their files, and what flavor(s) LW can handle...

The irony is that you can do what you're doing inside of LightWave. I had hoped to make a little tutorial on this some day, but it has been a year, so I'll just say it:

You can do the same thing using surface layers in LightWave, by stacking exposures in the surface of, say, a camera-facing plane. The intensity is added together in the same manner. The problem with both of these methods is that proper HDR creation involves much more subtle processing than just stacking things together, but this kind of brute force method might get the job done if all you want is range in an image.

By Arnie Cachelin (Arnie) (65.164.224.3) on Saturday, February 01, 2003 - 11:48 am:

To crudely mimic the mkhdr process of combining exposures, one would need to add the different exposure images together, not multiply them. Most importantly, each exposure would need to be multiplied by some weight that scaled with the shutter speed, so that the darkest image, which showed only the brightest areas, would be multiplied by the largest factor, and the brightest (overexposed) image would be multiplied by the smallest factor.
Mkhdr combines the images based on a film response curve it deduces from the involved relationship between pixel intensity, exposure time, and aperature. The scaling is non-linear, and its computation is the bulk of the time nd code complexity of mkhdr.
As Kenneth notes, this can be done with surface layers in LW.

By Beam Tracer (Beamtracer) (203.109.241.109) on Sunday, February 02, 2003 - 07:47 pm:

Go on, Arnie, Kenneth. This would make a great tutorial to add to Newtek's collection!