Stitching multiple exposures, HDRI result

[aaronpriest]

by aaronpriest » Mon Mar 25, 2013 12:35 pm

NO color-manipulation AT ALL in APG - JUST stitching.

That's actually a great idea!

[mattmerk]

by mattmerk » Mon Mar 25, 2013 8:22 pm

You can output stitched bracketed layers from both PTGui and AutoPano. The trouble is, most HDR programs will not handle very large panoramas to bring the separate 8 or 16-bit exposures into a 32-bit HDR file. For the time being I gave up on 32-bit panoramas, and I've often been tonemapping or fusing into 16-bit LDR files BEFORE stitching because neither APG nor PTGui have good enough control over the fusion process to do it all in one pass. There are obvious issues however with tonemapping or fusing before stitching, the biggest being inconsistency between images with such a large scene.

Hey Aaron, Matt!

Try HDR-processing the bracketed images FIRST. Saving the results as HDR/EXR. Stitch the HDR-images using the xml-import. Render them as HDR/EXR.
Output them as HDR/EXR. Import them to Maya, Maxwell, V-Ray, Cinema ot whatever for IBL.

NO color-manipulation AT ALL in APG - JUST stitching.

best, Klaus

Had you read my extensive notes above, you would have seen I already tried that. APG can write out a .hdr file or a .exr file. It just doesn't have values above 1. How come I can't seem to get anyone to understand that? Floating point, 32 bit file formats can have values well above 1. APG just doesn't write any values above 1.0. And yes, you can load any image you want into Maya or any other 3D app to do IBL. You could even load crappy 8 bit JPEGs. Just because you can load them for IBL doesn't make the image HDR. A .exr or a .hdr with values that only go from 0 to 1 is NOT HDR. How many times must I repeat this before someone slaps their palm to their forehead and says, "OHHHHHHHHH! I get it now!"

Let me say it again. If a .exr or .hdr has values that only go from zero to one and the whites are clipped at a value of one, and if you then color correct the image down in brightness in a piece of software that has a 32 bit float color pipeline, and you see no detail emerge in the highlights, your image is a 32 bit floating point LOW DYNAMIC RANGE IMAGE!!! Simply writing out a .exr doesn't magically make it HDRI.

So, I have a counter proposal. Somebody point me to an image anywhere on the internet written in a 32 bit file format, straight out of APG that is supposedly HDR. Let me load it in a piece of time tested VFX compositing software like Nuke and let me judge for myself that it is actually really HDR. I've said it many, many times already. I Want to be wrong about this. I really, really, really want to be wrong about this. All evidence however points to me not being wrong.

I am suggesting that APG is writing out LDR images in high bit depth image file formats and the brightest values are clipped at 1.0.

[mattmerk]

by mattmerk » Mon Mar 25, 2013 8:46 pm

By the way, I would prefer bringing in pre HDR-processed bracketed images first. I'm shooting my 360º spheres on a Gigapan robotic head and by pre-baking the bracketed stacks, I can also assign alpha channels to eliminate the parts of the rig that get captured with my 8mm fisheye. This can all be fully automated very easily. APG does really well with this workflow.

I can show up on set and shoot a pano pretty quickly and assemble it in APG very rapidly. Again (and again, and again, and again) APG is just not writing values above 1.0 in the .hdr files or .exr files. <--- NOT HDRI!

[gkaefer]

by gkaefer » Mon Mar 25, 2013 9:38 pm

mattmerk,

sorry for my dumb questions... you write about autopano cant write hdr files with RGB values above 1.
where do you see in autopano the RGB value is 1 or less than one?
what should be the possible range? (max.possible value)

are there different max. RGB values between the .hdr and .exr fileformat?

Georg

[mattmerk]

by mattmerk » Mon Mar 25, 2013 10:31 pm

Not a dumb question at all. You can't see the RGB values in APG. You have to load them in software that can first, read 32 bit float images. Then, second, has a color picker that will show you the floating point RGB values. Another way to confirm it would be to load the image in Photoshop and just bring the brightness down on the .exr or .hdr file and see if you reveal any image details hiding in the overexposed areas.

I have attached some images. I am using output from PTGUI loaded in Nuke (http://www.thefoundry.co.uk/products/nuke/) because PTGUI actually outputs float values above 1.0, unlike APG. Note the RGB values outside the window above 5, even though my (and your) monitor can only display up to 1!

THAT is High Dynamic Range Imagery.

From the HDR shop website, http://www.hdrshop.com :

"WHAT IS A HIGH-DYNAMIC RANGE (HDR) IMAGE?

"The "dynamic range" of a scene is the contast ratio between its brightest and darkest parts. A plate of evenly-lit mashed potatoes outside on a cloudy day is low-dynamic range. The interior of an ornate cathedral with light streaming in through its stained-glass windows is high dynamic range. In fact, any scene in which the light sources can be seen directly is high dynamic range.

"A High-Dynamic Range image is an image that has a greater dynamic range than can be shown on a standard display device, or that can be captured with a standard camera with just a single exposure.

"HDR images also have the important property that their pixel values are proportional to the amount of light in the world corresponding to that pixel, unlike most regular images whose pixel values are nonlinearly encoded.

"HDR Images are typically generated by combining multiple normal images of the same scene taken with different intensity levels, or as the result of creating a global illumination rendering. In practice, high dynamic range pixels use floating-point numbers, capable of representing light quantities of one to a million and beyond. Low-dynamic range images usually represent pixels using eight bits per channel, with pixel values ranging as integers between 0 and 255."


As I have been saying, you can actually have a LDR image saved in a HDR wrapper where the RGB values only go from 0 to clamped at 1. And that is NOT HDR. Does that make sense?

Last edited by mattmerk on Mon Mar 25, 2013 10:40 pm, edited 1 time in total.

[klausesser]

by klausesser » Mon Mar 25, 2013 10:40 pm

Had you read my extensive notes above,

impossible to miss it . . .

you would have seen I already tried that. APG can write out a .hdr file or a .exr file. It just doesn't have values above 1.

I just use the files in Maxwell and Maya and others. And when they accept the files as 32bit fp i believe them.
When i also can see that the file´s IBL capabilities features brilliantly - also in HDRLight-Studio providing extremely great features btw. -
the i tend to believe it too.

I don´t have washed-out lights as you show in your pictures - sorry So i can see no need to argue.

If PTGui does it better than APG: use it!

best, Klaus

[mattmerk]

by mattmerk » Mon Mar 25, 2013 10:53 pm

Here are some actual HDR images suitable for CGI image based lighting. All have RGB values above 1. All contain the high dynamic range of the environments in which they were shot.

http://cgcookie.com/blender/2013/03/04/contribution-free-hdr-panoramas-resource/

[mattmerk]

by mattmerk » Mon Mar 25, 2013 10:59 pm

There is no argument here. Autopano Giga simply does not do what the ads claim and what I paid for. This isn't an ego competition. I have already said many, many, many times that I could be the stupid one here and would happily be wrong and shout out to the world how I couldn't figure out a simple piece of software. But I have exhausted every possibility that I can see.

If this is a bug/misrepresentation, wouldn't EVERYONE benefit if it got fixed?

Autopanogiga is the better stitcher, hands down. PTGUI doesn't get close. PTGUI passes floating point values through its color path. APG does not. Why would anyone fight making the software actually work the way it claims to work?

BTW Klaus, your IBL will improve drastically when you start using actual HDRI and not just LDR images saved out as LDR .exr files.

[mattmerk]

by mattmerk » Mon Mar 25, 2013 11:04 pm

Oh, and one more thing. I too assume the software isn't lying to me, just like you. "And when they accept the files as 32bit fp i believe them." The problem is that the files are actually 32 bit float. They just have their brightest values clamped at 1. I have assumed all along that APG was doing what it claimed on the website: HDR output. I always assume that I am the one who is wrong and then spend a lot of time figuring out how. Rarely, I find I was actually right. Now is one of those times.

Unless someone wants to please show me that they can reproduce an HDR image out of APG. That is my challenge. I don't think it can be done.

[klausesser]

by klausesser » Mon Mar 25, 2013 11:25 pm

BTW Klaus, your IBL will improve drastically when you start using actual HDRI and not just LDR images saved out as LDR .exr files.

Where would i be without your wisdom . . .

best, Klaus

[gkaefer]

by gkaefer » Mon Mar 25, 2013 11:33 pm

ok, you did post a link to Blenders free HDI 32bit Floating Point panos.
download one - open it in your HDI Software showing the Pipette pointing to a Point with value above 1.
use the downloaded one and load this .exr file into autopano TWICE, disable all Options like Color correction etc before detection - do not use the HDR preset.
detect the "pano" and Export/save it as exr pano again.
load the autopano result into your HDR Software again and Point to the same poitn with your Pipette showing the VGA value (above? or lower than 1)

make from both a screenshot

under autopano bugs, create a new bug...with reference to this thread and posting a summury of above...


Georg

[HansKeesom]

by HansKeesom » Mon Mar 25, 2013 11:56 pm

if the data is in floats, it might be of interest what float in computer terms means. See http://en.wikipedia.org/wiki/Floating_point
If we are talking about the same floats here, it is not so much relevant whether any pixel gets a value above 1 or not, it is about the number of steps between 0 and 1 and the dynamic range. Between 0 and 1 you can still have an enormous number of different values and specify an enormous dynamic range using floats......

So if all values are between 0 and 1 and you want them between 0 and 100, just change the exponent 2 values, effectively multiplying by a 100.

[klausesser]

by klausesser » Tue Mar 26, 2013 12:35 am

Oh, and one more thing. I too assume the software isn't lying to me, just like you. "And when they accept the files as 32bit fp i believe them." The problem is that the files are actually 32 bit float. They just have their brightest values clamped at 1. I have assumed all along that APG was doing what it claimed on the website: HDR output. I always assume that I am the one who is wrong and then spend a lot of time figuring out how. Rarely, I find I was actually right. Now is one of those times.

Unless someone wants to please show me that they can reproduce an HDR image out of APG. That is my challenge. I don't think it can be done.

I took 3 images x7 steps bracketing.
combined the 7 steps in Photomatix to HDR (without tonemapping of course).
Took the HDR images and stitched them in APG (no CC at all).
Rendered them as Radiance (.HDR).
put the rendered image into Photomatix.

In the screenshot below you can see the - non-correct-displayable - HDR image and in the small viewer on the left side you can see the image´s
HDR-feature at the cursor.
When i move the cursor over the image the small viewer-image continuously changes it´s density. That´s how a 32bit/FP image is supposd to behave.

The image is about 12000x6000px and 330MB.

best, Klaus

1) APG-Stitch
2) Photoshop
3) Photomatix - small window on the let shows HDR-capability - it´s on the right beneath the red lamp close to the car´s bumper outside the window.

Last edited by klausesser on Tue Mar 26, 2013 12:41 am, edited 1 time in total.

[mattmerk]

by mattmerk » Tue Mar 26, 2013 12:36 am

Where you would be without my wisdom is living with the assumption that the claims made on the APG website are actually correct.

"...it is not so much relevant whether any pixel gets a value above 1 or not, it is about the number of steps between 0 and 1..."

No. You need values above 1.0 in float to do HDRI IBL. From the HDR shop website: "...high dynamic range pixels use floating-point numbers, capable of representing light quantities of one to a million and beyond." This comes from Paul Debevec, the guy who invented HDRI.

http://www.pauldebevec.com

And since we are trucking out wikipedia articles: http://en.wikipedia.org/wiki/Paul_Debevec

[klausesser]

by klausesser » Tue Mar 26, 2013 12:49 am

Where you would be without my wisdom is living with the assumption that the claims made on the APG website are actually correct.

"...it is not so much relevant whether any pixel gets a value above 1 or not, it is about the number of steps between 0 and 1..."

No. You need values above 1.0 in float to do HDRI IBL. From the HDR shop website: "...high dynamic range pixels use floating-point numbers, capable of representing light quantities of one to a million and beyond." This comes from Paul Debevec, the guy who invented HDRI.

http://www.pauldebevec.com

And since we are trucking out wikipedia articles: http://en.wikipedia.org/wiki/Paul_Debevec

You simply don´t get it. I´m tired now. Good nite!

best, Klaus

[mattmerk]

by mattmerk » Tue Mar 26, 2013 1:12 am

ok, you did post a link to Blenders free HDI 32bit Floating Point panos.
download one - open it in your HDI Software showing the Pipette pointing to a Point with value above 1.
use the downloaded one and load this .exr file into autopano TWICE, disable all Options like Color correction etc before detection - do not use the HDR preset.
detect the "pano" and Export/save it as exr pano again.
load the autopano result into your HDR Software again and Point to the same poitn with your Pipette showing the VGA value (above? or lower than 1)

make from both a screenshot

under autopano bugs, create a new bug...with reference to this thread and posting a summury of above...


Georg

This was a great idea Georg. I have done exactly what you recommended and here are my results in the images below. I was right! APG is clamping the values at 1.0. Thank you for finally giving me a method for testing this beyond any reasonable doubt. APG is NOT outputting 32 bit HDRI. It is writing LDR 32 bit EXRs and .hdr files.

And Klaus, again, I have no interest in "being right" here. For some reason you seem to think that I am maybe attacking you personally? If so, I apologize. I'm only interested in finding the truth here (and getting what I paid for): HDR output from autopano giga, which I have finally discovered to be broken.

[klausesser]

by klausesser » Tue Mar 26, 2013 11:31 am

For some reason you seem to think that I am maybe attacking you personally?

Hey Matt!

No! I definitely don´t think so!

best, Klaus

[klausesser]

by klausesser » Tue Mar 26, 2013 12:49 pm

APG is NOT outputting 32 bit HDRI. It is writing LDR 32 bit EXRs and .hdr files.

Maybe i found the issue: APG seems to include a sRGB profile. Can someone from Kolor finally say a word regarding Matt´s problem?
That would really be very much appreciated . . .

best, Klaus

PS:
Photoshop gives me this:

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

[marzipano]

by marzipano » Tue Mar 26, 2013 1:33 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 ?

[klausesser]

by klausesser » Tue Mar 26, 2013 2:34 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 . .

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

[AlexandreJ]

by AlexandreJ » Tue Mar 26, 2013 2:56 pm

Since yesterday, we were trying to reproduce this 1.0 clamp but with photomatix, we have the high dynamic range that we expected and not this 1.0 clamp. So we are not sure yet what the real answer is.
---
More news
---
What we tried :
- Stitching of the sample case provided in Autopano Pro / Giga 3.0.5 ( be sure to have the latest )
- No color correction / no multiband / simple render / nearest as interpolator ( to be in the most basic case )
- Output format : EXR
- Resulting panorama opened in Photomatix => nice histogram and nice dynamic range close to original picture
- Resulting panorama opened in Nuke => values over 1.0 as expected

Seems for us a workflow issue somewhere. Can you give detailed step by step workflow to get your results ?

[lumelix]

by lumelix » Tue Mar 26, 2013 3:00 pm

Hi
As we can read in wiki
http://de.wikipedia.org/wiki/High_Dynamic_Range_Image#Speicherung
or in several special books about HDRI, there are different HDR formats and coding methods.
So it's really interessting how APG handles HDR.

I created a HDR from 3 exposures (-1, 0 +1EV) and rendered it in APG to HDR-Radiance.
In Photomatix I get the values as expected:

Last edited by lumelix on Tue Mar 26, 2013 3:10 pm, edited 1 time in total.

[klausesser]

by klausesser » Tue Mar 26, 2013 3:07 pm

Since yesterday, we were trying to reproduce this 1.0 clamp but with photomatix, we have the high dynamic range that we expected and not this 1.0 clamp.
So we are not sure yet what the real answer is.

This meets my own experiences. I guess Hans was right regarding the 1.0 thing. The files would behave differently would they not be 32bit/fp hdr.

best, Klaus

[marzipano]

by marzipano » Tue Mar 26, 2013 5:08 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 terms of settings different to defaults I used:

Camera White balance
Create Stacks of 10 images

Auto colour correction=off

colour correction by layer=off
default correction=exposure
defaut regroup=by Stack

Blending preset = HDR output
output=.exr file or .hdr file

Then when actually running the images

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

[gkaefer]

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

Since yesterday, we were trying to reproduce this 1.0 clamp but with photomatix, we have the high dynamic range that we expected and not this 1.0 clamp.
So we are not sure yet what the real answer is.

This meets my own experiences. I guess Hans was right regarding the 1.0 thing. The files would behave differently would they not be 32bit/fp hdr.

best, Klaus

well, but it should be a reproducable case:

1. download demo hdr files from http://cgcookie.com/blender/2013/03/04/contribution-free-hdr-panoramas-resource/ posted by matkerm in #32
2. open the Image in nuke (download link in #32) and select any Point in the Image with RGB values above 1

3. the downloaded demo hdr file load into apg (two times the same Image to simulate an incomplete pano), disable any processing like corrections, Color adaptions, not using the HDR preset
3. detect the pano and render to same hdr or exr Output Format.

4. open the rendered apg pano again in "nuke" and compare the RGB values....

... if they stick at 1 or below ... than something apg is doing different...

Georg

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