aaronpriest wrote: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.

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!

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?

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!

"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.

mattmerk wrote: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.

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.

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.

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...

if the data is in floats, it might be of interest what float in computer terms means. See http://en.wikipedia.org/wiki/Floating_pointIf 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.

Regards, Hans KeesomI stitch and render for other photographers. Price: 25 euro or less, no cure no pay. If you want to concentrate on your business let me do the stitching for you. Free TB of Dropbox space when you have more then 250 euro business a year.

mattmerk wrote: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Â´sHDR-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-Stitch2) Photoshop3) 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.

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.

mattmerk wrote: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.

gkaefer wrote: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.

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 ?

AlexandreJ wrote: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.

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.

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)

AlexandreJ wrote: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.

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 preset3. 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.