marzipano wrote:klausesser wrote:marzipano wrote: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.
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)
marzipano wrote:Enable Fusion=yes
Edit colour anchor=HDR
Optimise by layers=no
colour level on update=no
optimize on anchor change=no
gkaefer wrote:in #30 matmerk wrote hes using "nuke"
mattmerk wrote: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.
mattmerk wrote: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.
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 !)
mattmerk wrote:And, as predicted, I was the dumb one here and am more than happy to be wrong.
mattmerk wrote:As for the discussion of IBL, I hope anyone interested gets lost in the amazing work of Paul Debevec who pioneered all this work.
mattmerk wrote: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.
mattmerk wrote: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?
mattmerk wrote: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.
Users browsing this forum: ArneAlbers and 2 guests