Well spotted but both the bright and dark grassy areas are part of the same pano. Here's evidence:

Last edited by Aeriscera (2010-05-28 09:23:56)

Aeriscera wrote:

Or, is what I am missing is that support for raw/hdr is essentially broken for now which is why people say develop your raw images before stitching?

As i told before - several times . . . .

The first question is: what do you need hdr files for?

Native .hdr/.exr files you need ONLY for IBL/GL (ImageBasedLighting/GlobalLighting) in 3D apps like Maya or Cinama4D.
For working with "usual" photography the way is: using a dedicated program to generate real HDR first and tonemap it in the same application afterwards.

The "second best" way would be to stitch all the bracketed images in APP/G, select "layered as brackets" in the editor and render three "bracketed" panos (by typing "%L" behind the pano´s name).
Theses 3 brackets you can tonemap then in Photomatix.

I myself definitely prefer the way to use HDRing and tonemapping before stitching.

best, Klaus

Aeriscera wrote:

PS

klausesser wrote:

The first question is: what do you need hdr files for?

It saves time when I want to try different tone-mapping algorithms in PS or PM.

1) you have "different tonemapping algorithms" in Photomatix already: tone-mapping and tone-compressing.
Use them in the right way and you definitely don´t need more.
2) Generating HDR in APG or in PTGui doesn´t save time at all.
(btw.: saving time is not the right way of thinking when aiming at top quality . . . )

I tested HDR in PTGui - it´s not what i expect from a HDR-application.

Again:
"HDR" is a very special theme. It should be done by dedicated applications and not by add-on features inside stitchers or EBV apps.

You should take in respect that most of the cases it´s DRI and not HDR what´s called "HDR".



best, Klaus

Hi All,

I just read this thread and I'm having the same problem as explained in the original post. I've attached a pano that shows the lower portion much brighter then it should be... all images are the same settings. I'm attempting to stitch bracketed NEF raw files into separate 16 bit tiff panos for merging into HDRI environments for IBL (in Rhino). I have been doing this for a couple of years using jpg files and wanted to see if I could gain some dynamic range by stitching raw instead. The resulting pano is a bit better if I use color correction but this always removes the contrast ratio between the brackets making the HDRI merge not work well for IBL. I always turn off color correction to maintain the EV separation of the brackets... I think many of you know the same.

I've found that converting the NEF raw files to tiff first and then stitching them does not cause this brightness on the bottom of the pano. However, I'm finding that converted tiff files merged to HDRI in Photomatix actually have about half the dynamic range of NEF raw images merged to HDRI. (The same individual bracketed sequences were used for this test and I am using the HDR histogram in Photomatix to judge dynamic range)

I would like to stitch the raw files directly and render them out as 16 bit tiff panos without color correction to see if the EV range is greater once merged as it is with the single shot tests.

Thanks for any help. I've emailed support a couple times but haven't heard back.

Brian James

APP 2.0.9 x64
Windows 7 x64

Aeriscera wrote:

Hi Brian,

My understanding is that the HDR support in Autopano is still broken. Certainly I have seen or read nothing to suggest otherwise in this thread or otherwise. I vaguely recall that the much-awaited version 2.5 (currently at alpha) will address this shortcoming.

Aeris

What´s your exact understanding of "HDR support"?

best, Klaus

Aeriscera wrote:

I'm can't give you a precise definition, but it would include "Not having the problems that Brian and I posted".

;)Well - everywhere in the world sometimes problems arise caused by unclear expectations . . .

First:
RAW is a format which needs pre-processing. It´s like a negative which has to be developed first before being enlarged
in the darkroom - you can´t use a negative straight from the camera.

"HDR" originally means to generate a 32bit/ch floating-point file.

This can be done in several ways. One of them means to shoot bracketed series of pictures and combine them to a "HDR" file in a dedicated "HDR" application.
Shooting bracketed series can mean to shoot JPGs or RAWs for example.
Theoretically shooting RAWs for generating HDR is preferable - but what does that mean in detail?
It means using for example 3 shots of 12/14bit RAW to generate one 32bit HDR file.
Of course a 12/14bit RAW contains a wider tone-range than an 8bit JPG - but experiences show that using 3 JPG versus 3 RAW doesn´t mean lesser performance generally.
(I strongly suggest to "develop" RAW-files before using them in a stitcher with a very good RAW-converter like PhaseOne or the ARC in Photoshop and Lightroom, for Nikons also appropriate is NX2 and for Canon it would mean DPP as a RAW-converter").

To get HDR for IBL we usually shoot JPG and generate three or more JPG 8bit-files to a 3x8bit=32bit HDR file. Instead of tonemapping the HDR it can be used as an .exr or .hdr in Maya, Max or Cinema for IBL-spheres.

AutopanoPro/Giga first hand is a stitcher-application - it´s very good in what it does. It´s NOT a dedicated HDR application in any way.

Nevertheless you can generate HDR-spheres using APP/G indeed.

To do so you can import your bracketed shots into APP/G and stitch them as layers. DON´T use color correction - it might alter the layers differently and that can cause results you surely wouldn´t want.

Having stitched the pano you can render and save it as bracketed layers. This bracketed layers - tiff or jpg - you can process in a HDR application to .exr or .hdr files which you can
use for IBL in Maya and so on.
I described that here sometimes before.

So you definitely HAVE "HDR-support" in APP/G and you might definitely be able to "not having the problems that Brian and i posted" . .

best, Klaus

BrianJames wrote:

It sounds like it's not possible to use raw without tonal artifacts at the moment. I'll try again in 2.5 and until then go back to my previous work flow.

Applications like APP/G or PTGui and so on are no dedicated RAW applications. That means the RAW-converting abilities are basic - which in no way can be a surprise. RAW converting is a bit of a delicate thing . . . :cool:

So it´s always preferable to convert the RAWs in a dedicated converter before stitching.

best, Klaus

hankkarl wrote:

But APP doesn't recognize the different exposures as being in one bracketed stack (yet).

Maybe it depends on the kind of files.
I sometimes do it using 3 RAWs - APP/G does recognize them well. But HOW well it does - that´s definitely below
a dedicated RAW app.
I mean: if you want to get the most out of your exposures - and who doesnt´t want that - it´s better do use a fine RAW converter first, save 16bit/TIFFs and use them in APP/G instead of letting APP play the role of a RAW-app.

So "spreading" 3 RAW exposures to 5 JPG or TIF files shouldn´t be left to APP - Photomatix does a much better job here!
Even taking a single 14bit-RAW to "pseudo HDR" and tonemap it in Photomatix takes you a good step forward in most cases.

best, Klaus

BrianJames wrote:

I suppose a simplified version of my question would be, why does APP support NEF raw stitching if the results are as I've shown?

I'd like to know the answer to that question too. Is the reading and stitching of raw files a feature that was added some time ago but no longer works properly? Or are Brian and I missing something?

A

BrianJames wrote:

Thanks for any help. I've emailed support a couple times but haven't heard back.

I guess it´s color correction/anchors what produce the effect.

best, Klaus

hankkarl wrote:

Ok, you can't always compare fixed point to floating point, and a 32bit floating point number does not have 32 bits of precision.  (a few of the bits are used for the exponent...)

I meant that just converting one JPG to a floating point, HDR type file does not really make it an HDR image--you have to add other images that expand the DR of the overall scent to be above a certain point.  It may done be by bracketing, or by taking several adjoining shots at different EVs (e.g. take a pano on auto, moving from very dark to very bright).

If you linearize each pixel (eg convert to some large fixed point version) I'd say that its not HDR unless there are more than 14 bits required to hold the data from the brighest to darkest pixel.  This means that a camera would need a photosite and ADC that gives a 14 bit result, and noise is not a big issue.

But I guess there are two ways of looking at this--one is that the image is in HDR file format, the other is that the image has more than some amount of DR.

Hey Hank!

Converting ONE JPG to fp data  wouldn´t make sense at all . Of course i meant a series of shots with different EV.
I usually take -2/0/+2 and soemtimes up to 12 shots differing 1 EV.
12 shots are needed when shooting straight into the sun or other very bright and hard light while keeping the foreground completely visible.
"HDR" is nit the same as DRI - because of it´s fp nature which allows ImageBasedLighting in 3D applications.
Without this HDR nature feature it would be DRI.

The 5D2 as well as the D300 and D3x series have 14bit RAW. A 5D2 RAW file used in Photomatix can be a substitute to a series of 3 JPG - but not always. Most of the time 3 JPGs processed to HDR and tonemapped carefully are better than one 14bit-RAW processed
to pseudo-HDR or just converted from RAW to 16bit TIFF.

If HDR is needed for IBL there´s no way around generating "real" .hdr resp. .exr files - which can be done in APG only by rendering seperate EV-layers (preferably 16bit TIFF) and processing them in Photomatix or another HDR application to .hdr or .exr . . . . . of course without tonemapping

best to you, Klaus