Stitching multiple exposures, HDRI result

[gkaefer]

by gkaefer » Tue Mar 26, 2013 5:20 pm

I just took 10 bracketed shots and processed HDR through both APG and PTGUI and got identical results from both with no obvious cut-off from APG (3.0.5) as below

The only thing is I'm not sure how you actually measure this cut-off at 1.0 described

I put them in Photomatix and checked the figures in there - but is that the same thing ?

Guess Matt just mistakes something when he views ths files.

best, Klaus

PS:

nevertheless a statement from Kolor might enlighten everybody . .

Thanks Klaus - I assume there should have been a attached to that

With Sherlock Holmes logic I can only see 2 possibilities. Either there is a difference in the way I am following the workflow (workflow E) in terms of all the settings used Or the use of Photomatix to measure this 1.0 cut-off in my examples is not showing this issue up properly (don't know what software Mattmerk is using for this)

(...)

in #30 matmerk wrote hes using "nuke"
Georg

Last edited by gkaefer on Tue Mar 26, 2013 5:21 pm, edited 1 time in total.

[klausesser]

by klausesser » Tue Mar 26, 2013 5:21 pm

Enable Fusion=yes
HDR Ghosts=yes
Edit colour anchor=HDR
Optimise by layers=no
colour level on update=no
optimize on anchor change=no

NO Fusion.
NO color-anchors AT ALL.

The point is:
generating HDR images from bracketed sets using a dedicated HDR application like Photomatix. NO tonemapping or ANY other manipulation. In the batch set "save as HDR".
Importing the HDR-images into APG.
NO color-processing, NO fusioning at all in APG!

ONLY stitching the HDR images in APG - otherwise you´ll be lost.

Save as .hdr (Radiance - that´s what i do) or .exr

best, Klaus

[klausesser]

by klausesser » Tue Mar 26, 2013 5:23 pm

in #30 matmerk wrote hes using "nuke"

Nuke is a very fine - and very expensive - professional application for composing, special-FX and so on.

http://www.thefoundry.co.uk/products/nuke/

best, Klaus

Last edited by klausesser on Tue Mar 26, 2013 5:24 pm, edited 1 time in total.

[mattmerk]

by mattmerk » Tue Mar 26, 2013 6:26 pm

Well, first off, just loading the photomatix website, they are calling the picture of the eiffel tower HDRI. It isn't. Heres a quote from the site: "Photomatix Pro is an excellent tool for creating high dynamic range photographs." Stuart Gripman, Mac Life, issue # 17, 2008 That quote shows the misunderstanding of what HDRI even is and how the term has been polluted.

I looked at photomatix ages ago to see if it might help in my company's workflow. Then I realized it didn't actually output real (old school definition) HDRI. Then I walked away from it.

The problem is that people call these images like the one of the eiffel tower on the photomatix website HDRI. They are not. The guy who invented HDRI, Paul Debevec, did research in this area to accomplish photoreal CGI photogrammetry. Somewhere along the line, someone hijacked the term HDR and began applying it to tone mapped images. This happens all the time in the world of computer graphics. I started out doing 3D animation. Now when I say 3D people think I mean stereoscopic. Loose use of these technical terms is fine at the hobbyist level but engineers need definitions that are inflexible.

I'll talk to the VFX world and see if we can move everything we say over to Latin. Until then, it is just a burden we technical VFX folks have to bear.

I don't think it is a matter of me not understanding what is being discussed here. I am just using a very specific and the original definition of HDRI--images that contain photon energy representations of the real world. Most places in the real world have high dynamic range lighting. It isn't that the photos taken in the world are HDR, it is that the world is HDR. HDR photography is there to capture a photon energy map of the world to apply to a world one would build in a computer. THis is why you need values that go as high as into the hundreds of thousands or millions in the brightest parts of the HDR image for computer rendering of CG elements.

Last edited by mattmerk on Tue Mar 26, 2013 6:28 pm, edited 1 time in total.

[klausesser]

by klausesser » Tue Mar 26, 2013 6:28 pm

Well, first off, just loading the photomatix website, they are calling the picture of the eiffel tower HDRI. It isn't. Heres a quote from the site: "Photomatix Pro is an excellent tool for creating high dynamic range photographs." Stuart Gripman, Mac Life, issue # 17, 2008 That quote shows the misunderstanding of what HDRI even is and how the term has been polluted.

I looked at photomatix ages ago to see if it might help in my company's workflow. Then I realized it didn't actually output real (old school definition) HDRI. Then I walked away from it.

The problem is that people call these images like the one of the eiffel tower on the photomatix website HDRI. They are not. The guy who invented HDRI, Paul Debevec, did research in this area to accomplish photoreal CGI photogrammetry. Somewhere along the line, someone hijacked the term HDR and began applying it to tone mapped images. This happens all the time in the world of computer graphics. I started out doing 3D animation. Now when I say 3D people think I mean stereoscopic. Loose use of these technical terms is fine at the hobbyist level but engineers need definitions that are inflexible.

I'll talk to the VFX world and see if we can move everything we say over to Latin. Until then, it is just a burden we technical VFX folks have to bear.

I don't think it is a matter of me not understanding what is being discussed here. I am just using a very specific and the original definition of HDRI--images that contain photon energy representations of the real world. Most places in the real world have high dunamic range lighting. It isn't that the photos taken in the world are HDR, it is that the world is HDR. HDR photography is there to capture a photon energy map of the world to apply to a world one would build in a computer. THis is why you need values that go as high as into the hundreds of thousands or millions in the brightest parts of the HDR image for computer rendering of CG elements.

Matt -maybe you should look into this one:
http://forums.cgsociety.org/archive/index.php/t-1020985.html

i added some screenshots i made in Nuke.

Now i´ll set the input correctly. Wait a bit, please:cool:

best, Klaus

Last edited by klausesser on Tue Mar 26, 2013 7:08 pm, edited 1 time in total.

[mattmerk]

by mattmerk » Tue Mar 26, 2013 6:33 pm

And for the record, making this one small fix to APG, based on what everyone is saying here, no one would even notice the change. Only Klaus, suddenly seeing very different (and better) results in his 3D renders, and all the people in the VFX world to whom I would be promoting the software. I'm basically asking for a change that most of you wouldn't even notice but would open up APG to a new market to sell more units.

[klausesser]

by klausesser » Tue Mar 26, 2013 6:52 pm

And for the record, making this one small fix to APG, based on what everyone is saying here, no one would even notice the change. Only Klaus, suddenly seeing very different (and better) results in his 3D renders, and all the people in the VFX world to whom I would be promoting the software. I'm basically asking for a change that most of you wouldn't even notice but would open up APG to a new market to sell more units.

Matt - what´s the reason you want to go over 1.0?

best, Klaus

PS: as you can see in the screenshots: it´s all there! Look at it!

Last edited by klausesser on Tue Mar 26, 2013 6:54 pm, edited 1 time in total.

[mattmerk]

by mattmerk » Tue Mar 26, 2013 7:33 pm

Why you want to go over 1.0 is covered extensively in Debevec's papers published on the subject.

You could start here: http://www.pauldebevec.com/Research/HDR/

[klausesser]

by klausesser » Tue Mar 26, 2013 8:17 pm

Why you want to go over 1.0 is covered extensively in Debevec's papers published on the subject.

You could start here: http://www.pauldebevec.com/Research/HDR/

Matt - i´ve read all this years ago.
You know how old it is, do you?

bst, Klaus

PS - and ofcourse i downloaded the light-probes already . .
as well as the original images.

Last edited by klausesser on Tue Mar 26, 2013 8:19 pm, edited 1 time in total.

[klausesser]

by klausesser » Tue Mar 26, 2013 8:35 pm

In Photomatix the Debevec-file "memorial.hdr" behaves EXACTLY like my test-file rendered from APG.
Same with "uffizi_probe.hdr

best, Klaus

Last edited by klausesser on Tue Mar 26, 2013 8:53 pm, edited 1 time in total.

[marzipano]

by marzipano » Tue Mar 26, 2013 8:35 pm

Why you want to go over 1.0 is covered extensively in Debevec's papers published on the subject.

You could start here: http://www.pauldebevec.com/Research/HDR/

HDRView allows viewing of .hdr files but not .exr so it would seem

Anyway loading the same images I showed earlier which came from APG 3.0.5 in HDRview instead of Photomatix gives a clearer result

It would still seem to me that APG is producing OK results and there are some numbers on the top which are >1.0 (but I don't know whether they are showing the same thing !)

best
Martin

[klausesser]

by klausesser » Tue Mar 26, 2013 8:51 pm

Why you want to go over 1.0 is covered extensively in Debevec's papers published on the subject.

You could start here: http://www.pauldebevec.com/Research/HDR/

HDRView allows viewing of .hdr files but not .exr so it would seem

Anyway loading the same images I showed earlier which came from APG 3.0.5 in HDRview instead of Photomatix gives a clearer result

It would still seem to me that APG is producing OK results and there are some numbers on the top which are >1.0 (but I don't know whether they are showing the same thing !)

best
Martin

We can see very well that the whole HDR-tonerange is in the file.

And i know that the IBL capabilities also are completely there - because i use them. Even Maxwell and VRay - the best renderers around - see the files as 32bit-HDR and produce very fine results.
The Debevec site and conclusions result from around 1997 . . in the meantime there was some developement.

The fact that the Devebec-HDR files behave exactly the sae way as my HDR-file behave shows me that it´s ok.

And believe me: i have an eye to judge it . . .

So for me this dicussion ends here.

best, Klaus

[mattmerk]

by mattmerk » Tue Mar 26, 2013 8:57 pm

I used to be a beta tester for VRAY and was on the advisory board for 3DS Max at Autodesk who have invited me to speak at SIGGRAPH for many years. I know all this software back and forth. If you are using float images with no values above 1 and they were shot in outdoor environments under direct sunlight, you are simply doing it wrong.

If you think your results are fine, great! Then the conversation should end here for you.

Last edited by mattmerk on Tue Mar 26, 2013 8:58 pm, edited 1 time in total.

[mattmerk]

by mattmerk » Tue Mar 26, 2013 9:27 pm

So, I have been talking to Alexandre who walked me through the proper procedure to get APG to do what I want. Here are my results:

Here I go:

1. Loaded two copies of the same 32 bit .hdr file from the CGCookie website with values well above 1 in the highlights.

2. Made sure I am using the latest version: (I am.)

3. Once the images are loaded, I opened the group settings.
a. Under Detection I uncheck "auto-color correction".
b. under Optimization I set the reset to "quick". I leave lens distortion correction to "enabled" with all those parameters set to "automatic".
c. In Panorama I set the projection to Planar (since I am just rerendering the spherical panorama that has already been assembled for this test). I've never messed with the default crop, so I will leave it at "Clamp to panorama content." Color correction by layer is "off" and I leave the Default color correction to "gamma" since there is no "none." Default regroup is left at my default, "By stack."
d. Render. Blending presets is set to HDR output. I have this time disabled blending and have deactivated fusion and HDR ghosts and cutting. Format is set to 32 bit EXR. Exported data is "Panorama."

4. Click "Detect."

5. Pano re-render looks good in the preview.

6. Load the rendered output to Nuke and...Success! Whites above 1.0.

It would seem that I have made poor assumptions about how the software was working and I think some of the default settings could be changed to make this work more easily, but yes, APG does appear to render Proper HDR under these conditions. And, as predicted, I was the dumb one here and am more than happy to be wrong.

Thanks everyone here for their feedback, especially Georg who really simplified the workflow to debug my improper approach.

As for the discussion of IBL, I hope anyone interested gets lost in the amazing work of Paul Debevec who pioneered all this work.

[klausesser]

by klausesser » Tue Mar 26, 2013 9:44 pm

And, as predicted, I was the dumb one here and am more than happy to be wrong.

Don´t worry - you´re not the first one and definitely wouldn´t be the last one . . . :cool:

Good it´s cleared now!

As for the discussion of IBL, I hope anyone interested gets lost in the amazing work of Paul Debevec who pioneered all this work.

I started reading him - and others - about 12 years ago . .

There´s indeed much confusion about what is "real" HDR and what´s just namend so.

best, Klaus

Last edited by klausesser on Tue Mar 26, 2013 9:44 pm, edited 1 time in total.

[gkaefer]

by gkaefer » Tue Mar 26, 2013 9:45 pm

So, I have been talking to Alexandre who walked me through the proper procedure to get APG to do what I want. Here are my results:

Here I go:

1. Loaded two copies of the same 32 bit .hdr file from the CGCookie website with values well above 1 in the highlights.

2. Made sure I am using the latest version: (I am.)

3. Once the images are loaded, I opened the group settings.
a. Under Detection I uncheck "auto-color correction".
b. under Optimization I set the reset to "quick". I leave lens distortion correction to "enabled" with all those parameters set to "automatic".
c. In Panorama I set the projection to Planar (since I am just rerendering the spherical panorama that has already been assembled for this test). I've never messed with the default crop, so I will leave it at "Clamp to panorama content." Color correction by layer is "off" and I leave the Default color correction to "gamma" since there is no "none." Default regroup is left at my default, "By stack."
d. Render. Blending presets is set to HDR output. I have this time disabled blending and have deactivated fusion and HDR ghosts and cutting. Format is set to 32 bit EXR. Exported data is "Panorama."

4. Click "Detect."

5. Pano re-render looks good in the preview.

6. Load the rendered output to Nuke and...Success! Whites above 1.0.

It would seem that I have made poor assumptions about how the software was working and I think some of the default settings could be changed to make this work more easily, but yes, APG does appear to render Proper HDR under these conditions. And, as predicted, I was the dumb one here and am more than happy to be wrong.

Thanks everyone here for their feedback, especially Georg who really simplified the workflow to debug my improper approach.

As for the discussion of IBL, I hope anyone interested gets lost in the amazing work of Paul Debevec who pioneered all this work.

whoever - sorry Alenxandre to contradict your procedure - said that you should use "Blender presets is set to HDR Output": this is wrong according current documentation!
see this page: http://www.autopano.net/wiki-en/action/view/LDR_/_HDR_:_How_it_works
here you see in last line the case with HDR Input files and HDR outputfiles (.hdr and/or .exr files talking about and not the tonemapping ldr files...) - this is "Case F"
and there its clear visible in screenshot to not use the HDR Output preset (because this only does tonemapping using ldr files). If you use "HDR Output" than this may cause your clamping to 1.
Check it to use preset "Antighost" instead and Review the RGB values...

Georg

[mattmerk]

by mattmerk » Tue Mar 26, 2013 9:53 pm

Yeah, the Debevec work is old Klaus. I know that because I was reading it as he was publishing it while I was working on Star Trek. That is my whole point. Debevec developed something in the 90s and then people started mis-using the terminology he came up with. And If you read his papers and understood them, why are we having a conversation about why HDRI in IBL should have values above 1? (THis is all way, way off topic at this point--I wanted to know what buttons I should have been pushing in APG to get me true HDRI. Now I know. I'm not about to go on teaching a free master class in image based lighting. For that I'll just send you to Chris Nichols (whom I also know.) He's not free though.

http://www.amazon.com/Global-Illumination-Exteriors-Lighting-Techniques/dp/B000NQRRCK/ref=pd_bxgy_mov_img_y

[klausesser]

by klausesser » Tue Mar 26, 2013 10:06 pm

And If you read his papers and understood them, why are we having a conversation about why HDRI in IBL should have values above 1?

I meant: did you need it to exceed the top values for some special purpose? Like a "hard glance" on a floor more than in the shooting or a glare somewhere - that´s what i do sometimes by stretching the top values a bit.

I did so in the lamp-shop: due to 7 steps bracketing the image was e bit "too well equalized" - i wanted a bit more glare in the lights to make them look somewhat overexposed, which is a more natural reception.

best, Klaus

[mattmerk]

by mattmerk » Tue Mar 26, 2013 11:22 pm

Here are some more interesting HDRI images one could use for computer based lighting (also made by a friend).

http://www.ruffstuffcg.com

All have values above 1. Here's why. When shooting your HDR brackets, you want your middle most bracket to be in the ballpark of what would be seen by the human eye. Values at one are pure white. If you look at the sun, the details you would see, like the caronas and sun spots are also pure white, but well outside what the eye is able to register. However, those values can be used to determine how many photons get shot at your subject.

This is why you want HDRIs that contain the brightest values above 1. You'd find these outside the windows of dimly lit rooms. On the reflections of shiny cars on sunny days. Even light reflected off clouds would typically be at these high energy values above 1.

If you quit looking at the HDRI as simply an image but instead a spherical light source wrapped around your scene, representing all different brightness values shooting photons at your subject, you'll get why you want values above 1.

And you can of course color correct the HDRI in the app by increasing or decreasing the brightness overall or gamma correcting it to lift or lower the mids, or increase contrast in the map. It is just about where you are starting. In your HDRI you want the mid tones to match the mid tones of the scene into which you are dropping your CGI object.

Last edited by mattmerk on Wed Mar 27, 2013 1:37 am, edited 1 time in total.

[mattmerk]

by mattmerk » Tue Mar 26, 2013 11:44 pm

I just wish someone would have said to me, "You're doing it wrong dummy. Don't use HDR output (even though it is totally counter intuitive) and use anti ghost." It works really well now.

Problem was what we all like to call PEBKAC = problem exists between keyboard and chair.

[klausesser]

by klausesser » Tue Mar 26, 2013 11:57 pm

If you quit looking at the HDRI as simply an image but instead a spherical light source wrapped around your scene, representing all different brightness values shooting photons at your subject, you'll get why you want values above 1.
And you can of course color correct the HDRI in the app by increasing or decreasing the brightness overall or gamma correcting it to lift or lower the miss, or increase contrast in the map. It is just about where you are starting. In your HDRI you want the mid tones to match the mid tones of the scene into which you are dropping your CGI object.

Yes, i know - that´s why i use a somewhat tricky strategy when i shoot bracketed - it´s different from the common use that you described. So i use 7 to 12 steps bracketing in many situations.
In some - but rather rare - situations even 21 steps.

It´s a problem in CGI that it sometimes looks too smooth, too clean as it´s often in digital imaging and photography. Of course there are plugins for generating some noise or other "irritating" features. I like to make it manually. In post i use a tablet for "painting irritations" into a scene.

But it all starts with the light! That´s the most important part.

best, Klaus

[dpolcino]

Re: Stitching multiple exposures, HDRI result

by dpolcino » Sat Mar 08, 2014 10:27 am

I've been testing both Kolor's and PTGUI, much prefer Kolor, it stitches like a dream. But I stumbled on this (old) thread because when I load Kolor HDRs into my 3D software, it's definitely not as good as a PTgui environment map. So glad someone else noticed. Has this been fixed???????