 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | Rules | You are not logged in.
Pages: 1
Trying to capture both the sunny and snowy mounts and an entire room in my home resulted in a 5 EV difference between the brightest view (1/160 F7.1) and the darkest one (1/5 F7.1)
Last edited by GURL (2009-01-22 15:35:55)
Offline
Using LDR color mode and placing the yellow anchor on an intermediate (1/20 F7.1) image resulted in a decent image but some parts of the room distant from the window are too dark while the mounts are not visible enough.
Last edited by GURL (2009-01-22 14:49:04)
Offline
Selecting other placements for the yellow anchor is enough to produce two more versions of the whole pano (a "too bright" one and a "too dark" one)
Offline
Then, using Enfuse to fuse those 3 versions of the pano result in a much more pleasant pano.
Offline
Source images are unprocessed JPEG from a Fuji S5, panoramas are shown using DevalVR, the final one is the JPEG unmodified result as it was poduced by EnfuseGUI using Enfuse default options. It was not post-processed using PS, something I would do if this was not "just for demonstration purpose".
The most important point is that I was able to use Smartblend (no ghosts, etc) and a single series of source images (10 images for a 360 x 180 pano, not 10 x 5 = 50 images like when using "real HDR" - 10 images in a single layer are much more easy to stitch than 50 images in 5 different layers!)
This is possible because the "internal bit depth" Autopano is using is not limited (floating number processing it uses is much more "powerful" than 8 bit or even 16 bit processing are.)
This point is not well known : there are many situations where the subject dynamic range is much larger than the one the camera can record (Fuji S5 included) in a single shot and where a proper use of Autopano anchors is enough to get fine results (using or not using Tufuse but using Smartblend to avoid ghosts). Enjoy!
Last edited by GURL (2009-01-22 15:43:04)
Offline
Nice result. But it only works as long as you don't have the 5EV on the same picture. If you didn't capture all the dynamic on one part of the pano, this won't work so well (this part will still be burned, of very noisy).
Offline
fma38 wrote:
But it only works as long as you don't have the 5EV on the same picture.
There are 3 EV between the folowing source images I used in the above pano. I decided of their exposure so that one of them is OK for the mounts while the other is OK for the room.
fma38 wrote:
this part will still be burned, or very noisy.
Compact and bridge cameras are noisy. Recent DSLR are not noisy when used at their base ISO, so that, pehaps, being afraid of inexistent noise is as harmful as actual noise is ?
I should add my tripod to the list of the tools I used, no doubt about that! (and I could add that the nicely shaped transfert curve of the Fuji - a film-like curve not a "digital one", certainly helped to get correct highlights, too.)
Offline
About noise the truth is that I usually use preprocessed RAW source images where I select a noise reduction setting according to the brightness of the shot (the darker the shoot the stronger the noise reduction) and then don't care any more (that is, I never inspect the result trying to find some noise.) Having owned digital cameras of the previous century certainly is a reason for that: noisy shots were displaying very bright blue and red sparkles and a grainless blue sky was something unknown!
For the used JPEG the noise reduction setting was "Standard" and this is certainly not a huge processing.
Offline
DrSlony wrote:
How well would this work for a shot in which there is a moving vehicle
For the moving vehicle the answer is easy: just as usual.
If smartblend is smart enough to care of the moving vehicle there will be no problem (using Enfuse before APP would not work, using Enfuse after APP to blend two different layers where the vehicle is not at the same place would not work either.)
DrSlony wrote:
How well would this work for a sunny sky and a shadow under a tree (all in 1 photo)?
This would work like it works for the sunny mounts, bright clouds, and my bike in the shadow (because of the wall and the ceiling it is in a really dark place.)
I'm making an other series of examples from the sames shots, try to show why it works. They are not ready yet but they show that the way APP can brighten or darken the very same source images is what matters.
Provided every region of the subject was in the DR range of the sensor in one or the other of the source images (preferabily in the straight part of the camera transfert curve), one (or more) of the stitched panos will include a proper exposure for this region.
Enfuse will then do its task as usual. Enfuse could be replaced by a manual fusing of the stitched panos but this would need progressive (gradient) masks in most occasions and this would be very time consuming task.
The lower the number of source images the less ghosts you will get, but removing the ghosts is Smartblend task only and sometimes Smartblend can't avoid them completely (nothing new there.)
Offline
Hi George,
In your nice explanation at
http://slash72.club.fr/gurl/smartfuse/index.htm
you showed that smartblend can lead to some ghost effects because smartblend doesn't apply the same decision to blend pict #N and pict #N+1 when brightness/contrast are different when working with +X EV or -X EV.
In this example, you didn't mention this potentially bad artifact. Do you think it's no more possible or we still have to check this ?
Offline
Using LDR and anchors is necessary.
Using any other method to brighten and darken the panos to be fused would not work because when NONE is used the exposure differences between source images are visible (when using Multiband and when using Smartblend.)
In the folowing partial stitchs there are very visible variations in the ceiling lightness wich was quite evenly lighted and other faults are visible though they are less obvious:
Offline
I think what marco-pano asks about is the problem with APP-1.x that stitching several layers where images are of different exposures produces layers with different locations of the smartblend blending boundary (seen in red on the mockups below). As you know APP doesn't perfectly align images, no stitcher does, which is why blending algorithms are important. Smartblend fives sharper edges. The problem is that APP-1.x is unable to render several layers of differently exposed but otherwise identical images... even if I edit the .pano file and replace img###_bracket+2.raw with img###_bracket-2.raw or img###_bracket_0.raw, the resulting panos will be almost identical, except for some of the smartblend blending borders... this is why I eagerly await APG with its notion of stacks, which, I believe, will use the same identical place in all layers to use as blending boundaries.
I hope the mockups below explain this well. The red line marks the smartblend boundary. Imagine the images aren't reprojected so that they fit identically, e.g. APP made one a bit more concave than the other, or one has a FOV of 0.5° more than the other - a typical stitching case. So now we have images which almost perfectly align, but not quite. If we rendered several layers, smartblend might not choose the same boundary in both layers, varying it by several pixels. The same problem with moving things - APP might not draw the boundary in the same spot on all layers. Now after enfusing the resulting panos, we end up with a ghost in the unmatched window frame.
So now the question, did I miss something, or does the GURL Method overcome this problem when rendering only 1 layer but moving the yellow anchor? Will the resulting panos have identically placed smartblend borders?
I'm dying to try this, hope I get a chance this weekend!
Last edited by DrSlony (2009-01-22 20:56:02)
Offline
On the contrary when LDR mode is used, both Multiband and Smartblend are able to stitch a correct pano because the brightness differences between source images were removed by APP before that.
This works for the brightest versions, for the darkest versions and for the (undisplayed) intermediate versions. The brightest versions correspond to 1/200 F:7.1 and the darkest ones to 1/13 F:7.1, a 4 EV exposure difference.
That the amount of exposure change is selected using an anchor is not really meaningful: this could (or perhaps should ?) be done using the mouse wheel or any other way. The extent APP can shift an image toward the dark or the bright values while keeping their colors identical to the results one would get if changing the camera settings would be something interesting to know (and the workaround to test that is quite obvious...) This sort of adjustments is something many peoples do when processing RAW format images, doing that using data found in JPEG corresponds to using Curves tool or Histogram tool to adjust them during post-processing.
Last edited by GURL (2009-01-22 21:01:07)
Offline
marco-pano and DrSlony
marco-pano and DrSlony wrote:
stitching several layers where images are of different exposures produces layers with different locations of the Smart blend blending boundary
A solution could be Smartblend producing some sort of "adjustment layers" rather than direct changes.
Besides those changes being manually editable (a rather nice feature, BTW !) they could (or could not ?) be reused for the different layers. Whether the "intermediate exposure" series of adjustment layers could be reused for a brighter layer and a darker layer seems a difficult question... (is there enough information in the "too dark" or "too bright" regions for that?)
Offline
GURL wrote:
A solution could be Smartblend producing some sort of "adjustment layers" rather than direct changes. Besides those changes being manually editable (a rather nice feature, BTW !) they could (or could not ?) be reused for the different layers. Whether the "intermediate exposure" series of adjustment layers could be reused for a brighter layer and a darker layer seems a difficult question... (is there enough information in the "too dark" or "too bright" regions for that?)
Agree with you, Georges, following some video codec way of working, will it be possible to perform a first smartblend process, recording how to blend on middle range layer, then apply same recorded rules for higher range or darker range layers. Maybe not so easy to implement but interesting to think about.
Offline
very interesting discussion!
a nice "how to", indeed, but only working on still motives...
i did some tests like that some time ago and found that there is some ghosting.
so the idea to give smartblend an information that is used for all renders may be a way to get non-ghosting results.
its a fact: the complicated way of using bracketed shots and rendering by layer doesnt give good results at the moment. its a good idea, but not ready...
so an easier way without bracketed shots but hdr-like results would be great...
Offline
I wanted to write a post here describing the error better, but I decided it will be best if I write it as a separate bug report thread because it might still occur in future 2.* versions, so take a look at this thread for a real-life example of the problem where APP/smartblend uses different blending borders for different layers:
http://www.autopano.net/forum/t5273-1.s … -identical
Offline
Pages: 1
