Hugin -> Faux Exposure Brackets -> enfuse

[Michael Witten]

I've achieved some pleasing results by using `Hugin' to stitch a
panorama several times with various Exposure Values, and then passing
this faux-bracketed stack through `enfuse' to yield the final,
exposure-fused result; this usually pulls out more details, especially
in places like a sky that might otherwise be blown out and clipped.

Unfortunately for this technique, the choice of seams made by
`enblend' occasionally depends on the Exposure Value setting;
consequently, various features in the images of the faux-bracketed
stack don't align, and thus the final exposure-fused panorama exhibits
ghosting and the like.

Is there a way to keep `enblend' from choosing alternate seams? Are
there better ways to achieve this faux-bracketing?

Thanks,
Michael Witten

[Caleb Anderson]

You can save and load blend masks. I forget the exact switch, but the documentation on the enblend site will have it. I'm not sure if you can from the frontend, though.

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[Monkey]

On Tuesday, 27 November 2012 06:13:21 UTC, Michael Witten wrote:

Is there a way to keep `enblend' from choosing alternate seams? Are
there better ways to achieve this faux-bracketing?

The --no-optimize option will stop enblend from refining the seams, so then they'll be the same on every exposure because they're only based on the image shapes. But could I recommend you give multiblend a try, if you don't need/want seam optimisation? :)

David

[cspiel]

Michael -

Am Dienstag, 27. November 2012 07:13:21 UTC+1 schrieb Michael Witten:

> Is there a way to keep `enblend' from choosing alternate seams? Are
> there better ways to achieve this faux-bracketing?

         I have not yet explored its
possibilities, but even Enblend-4.0 offers an
`optimizer-weights' option that balances the
contribution of the distance (from the initial
seam line) contribution and the image-data
mismatch (along the current seam line) to the
optimal seam line.  You'd say
        --optimizer-weights=1:0
in your case.

        In Enblend-4.1 you'll find a
`primary-seam-generator', where the default is
`graph-cut' and AFAIK the image contents is
taken into account.  OTOH,
`nearest-feature-transform' only uses the
images' shapes not their contents.  So for you,
        --primary-seam-generator=nearest-feature-transform
will be preferable.

Furthermore, version 4.1 will allow fine-tuning
how the image difference in the overlapping
areas is computed: option `image-difference'.
(IMHO, the default overweights the chrominance,
but that's a matter of taste.)

In any case please consult the manual of
Enblend.

BTW, Enblend/Enfuse 4.1 have not been released
yet, but soon will be!

HTH,
        Chris

[JohnPW]

Why not faux-bracket the source images first, then stack and enfuse them before stitching?

This is similar to making bracketed images from RAW files (eliminates alignment/movement difficulties common to conventional bracketing.)

I have to admit, most of my panos are from jpegs shot with cheap point and shoots that don't do RAW (and using TIFF is too onerous.)

John

[Gnome Nomad]

That's how I've done it. Works quite successfully.

If you're shooting JPGs, I wouldn't worry about converting them to
16-bit TIFF - JPG doesn't have the color depth for that.

Hmm, I think using TIFF isn't onerous at all!

--
Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

[paul womack]

JohnPW wrote:
> Why not faux-bracket the source images first, then stack and enfuse them before stitching?
> This is similar to making bracketed images from RAW files (eliminates alignment/movement difficulties common to conventional bracketing.)
> I have to admit, most of my panos are from jpegs shot with cheap point and shoots that don't do RAW (and using TIFF is too onerous.)

I just threw (almost literally) a perl
script together to do this, and the results are impressive.

BugBear (script appended)

Here it is:

#!/usr/bin/perl

use strict;
use warnings;

sub mk {
my ($in) = @_;
my $list;
for(my $i = 0; $i <= 100; $i += 20) {
my $o = sprintf("c%03d.tif", $i);
my $cmd = "convert $in -sigmoidal-contrast 5x$i\% $o";
`$cmd`;
$list .= " $o";
}
return $list;
}

sub enf {
my ($out, $list) = @_;
my $cmd = "enfuse --output=$out $list";
`$cmd`;
}

unless(scalar(@ARGV) == 2) { die "in, out" };

my $in = $ARGV[0];
my $out = $ARGV[1];
my $list = mk($in);
enf($out, $list);

[JohnPW]

Actually, for static situations, I have found that taking 3 or 4 jpeg exposures (maximum quality) and stacking them gives a surprisingly decent result and (with my camera) is quicker and better than a single TIFF. My P&S camera takes forever to process a TIFF and they gobble up card space like crazy. Converting the JPEGS to 16b and stacking allows produces an image with higher resolution more dynamic range (obviously nowhere near as good as RAW, but if the camera could shoot RAW, I'd do that instead.)

John

[JohnPW]

Just to clarify:

The image capture is the onerous part. My old camera (Nikon CP4500) takes forever to capture a TIFF (10-15 seconds between shots) I can capture JPEGs, bracketed or not, in a burst and the resulting files are much smaller than a single TIFF. In post porcessing on the compute,r the TIFFS are not onerous.

John 

On Monday, December 10, 2012 10:10:00 PM UTC-6, GnomeNomad wrote:

[JohnPW]

What are you folks doing to "faux-bracket" your images?

With RAW files, obviously you can do all sorts of non-destructive things, but I assume you aren't using RAW files though, or it wouldn't really be all that "faux."

If you are using conventional files, I assume you are adjusting the curves?

Sorry BugBear, I'm not smart enough to be able to read your perl script (other than that you are using something to adjust something and then enfusing the resulting images!)

I really need to lear scripting!

[Carlos Eduardo G. Carvalho (Cartola)]

I think I will test the script when I have an opportunity.

Nowadays I do one of these:

1- Shoot JPG with autobracketing and enfuse expositions (usually 3 but sometimes up to 5)
2- Shoot RAW and do those false exposure bracketing, mainly in movement scenes. In this case I usually shoot in both JPG and RAW and also do the autobracketing, so I can decide what to do after all.

I do this in a Canon T2i or a 60D, both with Magic Lantern firmware, that gives me better bracketing control.

Cheers,

Carlos E G Carvalho (Cartola)
http://cartola.org/360
http://www.panoforum.com.br/

2012/12/11 JohnPW <johnpw...@gmail.com>

--

[Gnome Nomad]

You have a camera that shoots TIFF? Old camera. My Maxum 7D (several
years old) shoots RAW or JPG. It shoots 3 frames per second, regardless
of format. RAW is the raw data dump from the CCD and reflects the actual
layout of the individual color sensors on the CCD. I think most DSLRs
have a RAW format. The RAW format typically isn't processed by anything
in camera (many cameras do some processing such as sharpening or noise
reduction to the image when making a JPG out of a RAW file).

[Gnome Nomad]

If you can set your camera to automatically bracket using JPGs, I'd
think you'd get good dynamic range results. Or you can do it manually
(adjusting the shutter speed). Then you're getting into the area of
shooting high-dynamic range images.

[paul womack]

OK - ignoring the script, here are the external commands issued by the script for a run:

proc.pl o1.tif o2.tif

convert o1.tif -sigmoidal-contrast 5x0% c000.tif
convert o1.tif -sigmoidal-contrast 5x20% c020.tif
convert o1.tif -sigmoidal-contrast 5x40% c040.tif
convert o1.tif -sigmoidal-contrast 5x60% c060.tif
convert o1.tif -sigmoidal-contrast 5x80% c080.tif
convert o1.tif -sigmoidal-contrast 5x100% c100.tif
enfuse --output=o2.tif c000.tif c020.tif c040.tif c060.tif c080.tif c100.tif

I'm assuming people on this list know what enfuse does.

I'm using ImageMagick ("convert") to make derived files from the original
image, with (severaly) skewed image curves, all the way from skewed
to the dark (so most of the dynamic range in the output file is expanded
from the shadows of the source) to skewed to the dark (ditto, sort of).

http://www.imagemagick.org/script/command-line-options.php#sigmoidal-contrast
http://en.wikipedia.org/wiki/Sigmoid_function

The upshot is a range of image with enhanced contrast in the
various intensity ranges of the original image.

Enfuse then "just" picks and merges the best pixels in
the usual way.

BugBear

[JohnPW]

Yup, I do that too. But again, the bracketing will not work in a burst. I have to press the shutter 3 (or 5) times when auto-bracketing. I mostly bracket only in very static situations.

[JohnPW]

Yep, old.

It's a Nikon Coolpix 4500. It must be over 12 years old by now. I got it when I did for quick digital images for my work, but I didn't want to spend on a DSLR at the time because they were so expensive and not very mature. I've been slow to get a DSLR,waiting for larger sensors, which are not getting more common. The Cannon 5D Mark II is getting me interested.

I set the camera to do no sharpening, saturation, or contrast adjustments and to use minimal compression when processing the jpeg.

I have looked at a hack to make the camera put out RAW, but it looked iffy, and Nikon seems to actively block such efforts (hence my interest in Cannon and Magic Lantern software.)

John

[JohnPW]

Thanks. I was thinking it might be Image Magic, but I haven't been able to get it to work for me and so am not familiar with it's commands.

John

[JohnPW]

I should say I have not been able to get it to install. But the latest MacPort for it seems to have installed it without a hitch! Now that I have it installed, I can see you call IM with "convert."

Will be experimenting w/ IM, and your and some other scripts.

John

[JohnPW]

Bugbear,

That's cool. Very fast and exiting.

Unfortunately I get a warning with each execution. But it does produce the output files:

watkins-mbp-admins-macbook-pro:Testy jpwmacbookpro$ convert o1.tif -sigmoidal-contrast 5x100% c100.tif 

convert: o1.tif: wrong data type 3 for "GainControl"; tag ignored. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/824.

Then when it gets to the enfuse command, it can't find enfuse:

watkins-mbp-admins-macbook-pro:Testy jpwmacbookpro$ enfuse --output=o2.tif  c000.tif c020.tif c040.tif c060.tif c080.tif c100.tif

-bash: enfuse: command not found

I assume this is because there is a problem with my .profile. It looks like a mess to me (fricking MacPorts, I guess.)

And yes, I have no real idea of what I'm doing or how to doit and  have been unable to get usable help on what I'm doing  wrong. I suspect the path to Hugin/Hugintools/ is incorrect.

Help from any kind soul would be greatly appreciated.  :-)

John

.profile (which is in ~) contains this text (my additions are in bold):

# MacPorts Installer addition on 2012-08-12_at_18:57:16: adding an appropriate PATH variable for use with MacPorts.

export PATH=/opt/local/bin:/opt/local/sbin:$PATH

# Finished adapting your PATH environment variable for use with MacPorts.

##

# Your previous /Users/jpwmacbookpro/.profile file was backed up as /Users/jpwmacbookpro/.profile.macports-saved_2012-10-11_at_23:28:46

##

# MacPorts Installer addition on 2012-10-11_at_23:28:46: adding an appropriate PATH variable for use with MacPorts.

export PATH=/opt/local/bin:/opt/local/sbin:$PATH

# Finished adapting your PATH environment variable for use with MacPorts.

##

# Your previous /Users/jpwmacbookpro/.profile file was backed up as /Users/jpwmacbookpro/.profile.macports-saved_2012-10-15_at_13:53:25

##

# MacPorts Installer addition on 2012-10-15_at_13:53:25: adding an appropriate PATH variable for use with MacPorts.

export PATH=/opt/local/bin:/opt/local/sbin:$PATH:/Applications/Hugin/Hugintools

# Finished adapting your PATH environment variable for use with MacPorts.

##

# Your previous /Users/jpwmacbookpro/.profile file was backed up as /Users/jpwmacbookpro/.profile.macports-saved_2012-10-15_at_14:33:27

##

# MacPorts Installer addition on 2012-10-15_at_14:33:27: adding an appropriate PATH variable for use with MacPorts.

export PATH=/opt/local/bin:/opt/local/sbin:/Applications/Hugin/HuginTools/:$PATH

# Finished adapting your PATH environment variable for use with MacPorts.

On Wednesday, December 12, 2012 3:55:33 AM UTC-6, bugbear wrote:

[JohnPW]

I added a slash and now it works. For any other poor noob, here is text that worked for me:

export PATH=/opt/local/bin:/opt/local/sbin:$PATH:/Applications/Hugin/HuginTools/

[JohnPW]

Actually it appears that it was this text that did it:

export PATH=/opt/local/bin:/opt/local/sbin:/Applications/Hugin/HuginTools/:$PATH

[Gnome Nomad]

I'm waiting for the budget for something like an Sony Alpha A-9xx series
(36MP full 35mm-sized sensor). And the bigger budget for very good
lenses to go along with it, of course!

12 years ago, I guess they decided TIFF was the best format available
for a lossless image format back then (even 100% JPG quality throws out
some color info). I guess they also decided they didn't want to provide
a proprietary lossless RAW format back then.

[Gnome Nomad]

Bummer. On my camera, holding down the shutter fires a burst of
autobrackets (3 or 5). I think there's a mode setting, though, that
turns it off for autofocus on moving objects.

When I'm seriously bracketing, I'm general not shooting for a panorama,
I'm shooting for a HDR image. Then I'm manually adjusting shutter speed
between shots ...

[JohnPW]

This is very cool (and, amazingly, I've gotten it to work form me.) I'm still trying to figure out how to run the perl script, but  I'm happy I at least have the commands working on the command line!

Any way, I'm curious, does this script produce essentially the same results as if you output differently exposed tiffs converted from a RAW file, or would that technique offer a slightly better result? I ask out of curiosity (I don't normally have access to a camera that shoots RAW.)

Thanks,

John

On Wednesday, December 12, 2012 3:55:33 AM UTC-6, bugbear wrote:

[paul womack]

JohnPW wrote:
> This is very cool (and, amazingly, I've gotten it to work form me.) I'm still trying to figure out how to run the perl script, but I'm happy I at least have the commands working on the command line!

> Any way, I'm curious, does this script produce essentially the same results as if you output differently exposed tiffs converted from a RAW file, or would that technique offer a slightly better result? I ask out of curiosity (I don't normally have access to a camera that shoots RAW.)

RAW should (potentially) have a little more data available than a JPEG, so the results
from that should be (slightly) better.

BugBear

[Gnome Nomad]

48-bit RAW has 16-bits per color channel. JPG only has 8.

[JohnPW]

Actually, I was curious how using this script on a high bit depth tiff extracted from a good RAW file would compare with:

enfusing 6 tiffs extracted from the same RAW file at 6 different exposure levels.

In other words, given RAW and tiff files with similar depth of information how does the sigmoidal contrast setting compare to RAW conversion?

Clearly RAW conversion isn't even an option on jpegs. But I'm curious about how similar these two approaches are both theoretically and in actual practice.

My understanding of basic concepts of image manipulation is not great, and my initial thought is that the approaches are totally different. (the intermediate files don't look like different exposures in the way actual bracketed shots do.) But after reading what little I found on sigmoidal contrast and considering what little I (think) I know about RAW files, I start to think that the manipulation may not be so different as I initially thought. Perhaps the destinations these two winding roads lead to, are nearer each other than I thought!

The main thing I notice with this process is that the highest of the highlights seems to get slightly blown. But is this a result of the strategy itself or just the finer points of it? Perhaps some adjustments might make a difference, say the sigmoidal contrast settings — perhaps the contrast factor needs to be edged down bait? Or maybe the weighting of the enfuse settings should be different from the defaults? Or is it inescapable with this process because of a simple principle of image manipulation theory? Or maybe it's inescapable even with full access to a RAW file?

I don't know, I'm just curious. To me it's an ingenious process in any case.  :-)

If anyone can tell me, or point me to a good resource, I'd love to hear about it.

John

[JohnPW]

Yes, that's what I was alluding to.

But what about what I'm asking below?

Theoretically tiff 16 bit tiff brackets converted from a 12 (or 16 bit) RAW file contain more information than a single one. But in practice is there really much difference between enfusing them and making faux bracketed images from that single 16 bit tiff using this technique.

How much difference, theoretical and practical, is there between the two groups of intermediate images?

John

[paul womack]

JohnPW wrote:

>
> The main thing I notice with this process is that the highest of the highlights seems to get slightly blown. But is this a result of the strategy itself or just the finer points of it? Perhaps some adjustments might make a difference, say the sigmoidal contrast settings � perhaps the contrast factor needs to be edged down bait? Or maybe the weighting of the enfuse settings should be different from the defaults? Or is it inescapable with this process because of a simple principle of image

> manipulation theory? Or maybe it's inescapable even with full access to a RAW file?

Are they un-blown in ANY of the intermediate images?

BugBear

[Carlos Eduardo G. Carvalho (Cartola)]

Another try would be using some command line tool to convert directly from the raw files. I know that ufraw[1] can do this. One easy way to do this is to use its graphic interface to generate the different profiles in files, then make the script using them.

Surely it is available on unix systems, I just don't know if it can be used on command line on windows.

[1] - http://ufraw.sourceforge.net/

Carlos E G Carvalho (Cartola)
http://cartola.org/360
http://www.panoforum.com.br/

2012/12/18 paul womack <pwo...@papermule.co.uk>

JohnPW wrote:

The main thing I notice with this process is that the highest of the highlights seems to get slightly blown. But is this a result of the strategy itself or just the finer points of it? Perhaps some adjustments might make a difference, say the sigmoidal contrast settings — perhaps the contrast factor needs to be edged down bait? Or maybe the weighting of the enfuse settings should be different from the defaults? Or is it inescapable with this process because of a simple principle of image

manipulation theory? Or maybe it's inescapable even with full access to a RAW file?

Are they un-blown in ANY of the intermediate images?

 BugBear

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com

To unsubscribe from this group, send email to hugin-ptx+unsubscribe@googlegroups.com

[JohnPW]

Yup. If you have the RAW, that would be the way to do it.

But, as the prison warden in "Coolhand Luke" said, "I think what we have here, is a failure to communicate!"   ;-) 

Not really a failure to communicate, but possibly a misunderstanding of interests.

• I think Bugbear is advocating this as a nice and quick way to get the most from a single jpeg image. And I think he's right — it looks like a neat trick to faux enfuse a jpeg and get a better image.

• Other folks maybe think one should use a RAW file instead, which is also right, but he's talking about getting the most from a jpeg when you don't have a RAW file. And presently, I can't take RAW images.

• And in addition to these points, I'm curious about the theoretical and practical aspects of this image processing method. Unfortunately, I don't know enough about image processing to figure it out for myself. It seems to me there is some loss of detail in the highest highlights. But is this just a figment of my imagination? Is it endemic to improving the image and impossible to avoid (even with a RAW file?) Is there a way to avoid it by changing how the method is used? As an example, if one uses this process on a single, well exposed, high bit depth image extracted from a RAW file, how does it compare to enfusing several exposures extracted from that RAW file? etc.

John

2012/12/18 paul womack <pwo...@papermule.co.uk>

To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com

[JohnPW]

Hi Bugbear,

Admittedly initial image is not the greatest. It is a pano stitched from jpeg originals. But it's pretty good. Here is a small detail from the image:

c100     the darkest of the faux brackets, which would presumably have the best exposure of the highest highlights.

o1         the input file

o2         the output file

The place I see some loss of detail is in the white T shirt. The difference is most obvious when comparing o1 and o2. It seems to me the detail is there in c100, but not in o2. The shirt is brighter, but the texture is blown. This surprises me, because I would have thought that enfuse would have selected these detail pixels from c100 as "best exposed."

What do you think?

John

[Frederic Da Vitoria]

Hello JohnPW

IMO, you shouldn't compare the highlights between any image and c100: since c100 is the darkest, it will always show more details in the highlights than any other picture. You should always compare with the original. Does o2 do better than à1 in the T shirt? I believe so.

2012/12/18 JohnPW <johnpw...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

[JohnPW]

Are you sure you didn't mix the two up?

o1 is the original and o2 is the output.

In my opinion the shirt detail in o2 is very clearly blown out compared to o1.

BTW, I agree that it's best to compare o1 and o2. I included c100 to show that at least one of the intermediate image isn't blown out at Bugbear wondered.

[Frederic Da Vitoria]

Yes, you are right, I didn't look closely enough. The details in the T shirt are more immediately visible, but the textures in the lightest zones now seem uniformly white. In my experience, P&S cameras have a tendency to over-expose pictures. Maybe choosing picture with a better exposition (that is under-exposed by the camera's standards) would give better results.

2012/12/18 JohnPW <johnpw...@gmail.com>

[JohnPW]

Sure, in fact I have the camera default set to underexpose by .75 stop (which is probably the only thing you can do if you can't shoot RAW.)

But the fact that the detail exist in o1 shows that the detail is lost in the transformation, not because of the camera.

[Gnome Nomad]

All CCDs have limits to how bright or dark a value they can record. RAW
formats can allow software to recover blown highlights to an extent, but
it's really more of an educated guess based on surrounding pixels.

When the sensor in my Maxxum 7D blows a highlight, it's really blown,
and unrecoverable. Other sensors, such as the ones Canon uses in their
lower-end DSLRs, don't blow highlights as quickly as my camera does. But
they will all blow highlights sometime.

That's why true HDR shoots sets of images with a range of exposure
settings. One's exposure is set so the blackest blacks fall within the
camera's dynamic range. The lightest exposure is set so the brightest
whites fall within that dynamic range. (I've shot HDR sets with about 9
stops exposure). Bracketing is just an automatic, less flexible way of
doing that. Faux bracketing doesn't have the same dynamic range
available to start with, although it can work out effectively where you
have a contrasty scene but want to pull detail from both the bright and
dark portions of the image.

Or something like that. I'm tired! #-/

> than �1 in the T shirt? I believe so.


--

[Frederic Da Vitoria]

Yes, this is another an illustration of the advantages of RAW files.
Also, the lower bit depth of JPEGs may have an influence here: maybe a
little more details could have been recovered from the highlights if
the original image had been a RAW or a TIFF.

But now that I think of it more closely, I understand that JohnPW's
question is still unanswered and that my answers completely missed the
point. I expect the faux-bracketing to keep the lightest parts of the
darkest exposure and the darkest parts of the lightest exposure. If
this were true, there should not be any loss in the highlights.
Obviously enfuse decided otherwise, but why did he do so and is there
any way to make him behave as I expect?

2012/12/19, Gnome Nomad <gnome...@gmail.com>:

>> than à1 in the T shirt? I believe so.

>
>
> --
> Gnome Nomad
> gnome...@gmail.com
> wandering the landscape of god
> http://www.clanjones.org/david/
> http://dancing-treefrog.deviantart.com/
> http://www.cafepress.com/otherend/
>

> --
> You received this message because you are subscribed to the Google Groups
> "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
>

[paul womack]

JohnPW wrote:

> � I think Bugbear is advocating this as a nice and quick way to get the most from a single jpeg image.

That's exactly it.

In my personal case, I went round the Rockies in Canada with a (new) Canon A590,
determined NOT to be a photography geek, but just to snap away.

But the (JPEG) images in scenes with tree lined valleys in shadows, and snow
in full sunlight made for disappointing prints, so I tried manually (in Gimp)
making dark/light versions and enfusing them, which helped a good deal.

This script is simply an automated version of what I did manually.

BugBear

[Doug]

On 18/12/12 19:36, JohnPW wrote:
> Yup. If you have the RAW, that would be the way to do it.
> But, as the prison warden in "Coolhand Luke" said, "I think
> what we have here, is a failure to communicate!" ;-)

<snip>

Just a P.S.
That was "Coolhand Luke". The prison warden shot him ;-)

[JohnPW]

Exactly!

On Wednesday, December 19, 2012 5:13:57 AM UTC-6, Frederic Da Vitoria wrote:

 I expect the faux-bracketing to keep the lightest parts of the
darkest exposure and the darkest parts of the lightest exposure. If
this were true, there should not be any loss in the highlights.
Obviously enfuse decided otherwise, but why did he do so and is there
any way to make him behave as I expect?

I'm expecting this script to increase the amount of information in the image (but really, that seems counter to basic laws of thermodynamics.) It does seem to do that generally, but clearly information is lost in the highlights. Although I don't perceive it, I imagine that information is also lost at the dark extremes as well. My suspicion is that it has to do with the fact that the tips of the sigmoidal curve are locked down on the white and black points and somehow the curve is not acting the way we expect at these extremes.

With a real bracketed shot (and with a brackets made from a RAW image) the "least exposed" image will give you the most usable detail in the highlights. In both cases the curve still has a long tail with a gradual slope that spreads the highlights out. With this script, the end points remain at exactly the same point on every intermediate image (there's nowhere else for them to go.) This forces the extreme tip of the curve to compress severely and the points on the curve nearest the endpoint must necessarily change radically. I'm not sure what the shape of the curve at these extremes would be, but I'm thinking it must have the effect of clipping the highlights instead of spreading them out. If so the same thing happens at the low end. So my guess is, contrary to what I expected, that the extremes get slightly clipped, rather than enhanced, to the benefit of the main part of the image.

That's not to say it's bad though. Obviously it the fat part of the image benefits. The same is true when you adjust the contrast curves in the normal way. Effectively you sacrifice less important information at the extremes (or wherever) to emphasize more important information in the middle (or wherever.)

[Frederic Da Vitoria]

2012/12/19 JohnPW <johnpw...@gmail.com>

I played a little with o1 in Gimp. Here is what I found.

First I thought about using the Shadows and Highlights plugin http://registry.gimp.org/node/116 I thought that it should achieve the same kind of results. To my surprise, I could not, actually, I was getting inverse results, I mean inverse when compared to o2. So I decided to use the good old curves filter. I applied a sigmoid curve. I don't know how to describe this best, but I'll try: I dragged a point near the bottom left of the curve slightly up and left, and a point near the top right of the curve slightly down and right. The result should be to lighten the shadows and darken the highlights, thus revealing details in those parts. This should be something like what is achieved with HDR. I did reach those results, but at the same time, I lost contrast, which after all was to be expected. Then I applied the reverse sigmoid on the original picture, and reached an enhanced contrast, which seems closer to what I see in o2. But I noticed that I saw more details in the shadows of à2. So I believe that the faux-bracketing results are closer to a "D" shaped curve, with a point near the bottom left of the curve slightly up and left and a point near the top right of the curve slightly up and left too. This means that enfuse does not apply a sigmoid curve, but it seems he gives the preference to the lightest point.

[Bruno Postle]

On Wed 19-Dec-2012 at 12:13 +0100, Frederic Da Vitoria wrote:
>
> But now that I think of it more closely, I understand that
> JohnPW's question is still unanswered and that my answers
> completely missed the point. I expect the faux-bracketing to keep
> the lightest parts of the darkest exposure and the darkest parts
> of the lightest exposure.

I'm not entirely sure what you are trying to do, but Hugin will
extract 'bracketed' exposures from any photo. By default it uses a
'sigmoidal' camera response curve to map the data to linear space,
multiply and then map back again - This curve will be quite accurate
if you have calibrated your camera photometric parameters.

All you have to do is load your photo and increment Eev for the
input or output.

You can then enfuse these brackets, but this process only really
makes sense if you start with 16bit per channel data created from
RAW.

--
Bruno

[paul womack]

I don't think that's true. I believe (or at least strongly suspect ;-) ) that by applying steep contrast curve
to different tone segments and then using enfuse, I can achieve *localised* contrast enhancement, in mid tone
as well as in shadows and highlights.

From JohnPW's other comments, it looks as if I may want to do something
other than ImageMagick's sigmoidal mapping on the two extreme synthetic brackets.

BugBear

[paul womack]

paul womack wrote:

> From JohnPW's other comments, it looks as if I may want to do something
> other than ImageMagick's sigmoidal mapping on the two extreme synthetic brackets.

convert o1.tif -brightness-contrast +10 -sigmoidal-contrast 5x0% c000.tif
convert o1.tif -sigmoidal-contrast 5x25% c025.tif
convert o1.tif -sigmoidal-contrast 5x50% c050.tif
convert o1.tif -sigmoidal-contrast 5x75% c075.tif
convert o1.tif -brightness-contrast -10 -sigmoidal-contrast 5x100% c100.tif
enfuse --output=o2.tif c000.tif c025.tif c050.tif c075.tif c100.tif

So - when stretching (emphasising...) the highlights I also knock the down a bit,
and (conversely) when doing the shadow I bring them up a bit.

The mid ranges were already handled nicely by the sigmoid.

BugBear

[paul womack]

Ignore that - it's worse!!

BugBear

[JohnPW]

I'm glad this is stimulating discussion. This is the kind of thing I enjoy reading here (especially when somebody can explain things they know.)

Anyway, I'd like to figure out some things about sigmoidal contrast. Is a "sigmoidal contrast" simply an approach to setting the contrast curve we all know from photography and digital imaging? In other words, is it a subset of  possible contrast curves that could be uses which follow a sigmoidal shape as described in the formula?

From what I can understand, this means it is a typical contrast curve but:

• with the endpoints locked down at blackest black and and whitest white

• with a single inflection point somewhere in the middle

• and a sigmoidal (s) shape  between perfectly straight and infinitely steep (essentially a step function)

• presumably this function always has a positive slope and the 's' shape is never inverted into a backward 's' shape.

Are my assumptions correct?

[Frederic Da Vitoria]

Apart from the "and a sigmoidal (s) shape between perfectly straight and infinitely steep (essentially a step function)" (my English is not good enough to understand your meaning, so I can't say if this is correct or not), yes, this is correct. In the Gimp curves filter, the sigmoidal curve could be inflected as a printed "S", in which case the results are accentuated (by increasing the dynamic range in the middle tones and losing details in the extremes), or like a rounded "Z" and this results subjectively in a loss of contrast but should improve the details in the extremes.

2012/12/20 JohnPW <johnpw...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[JohnPW]

I mean that as the contrast factor increases, the curve trends to be more like a step function (where all pixels to the left of the midpoint become black and all to the right become white.)

Attached a horrible pdf drawing (sorry I had no handy vector drawing tool and had to draw with the trackpad too!)

I assume the inflection point of the sigmoid curve only shifts along the diagonal as the contrast factor is changed. Is this correct? If so, at 100% the invlection point is at the white point and the slope of the curve coming out of the white point is is very steep (essentially straight down. 

If instead, the inflection point stays at the same level (only moves left and right,) it would be even steeper. No, I guess this is impossible as the curve would emerge from the middle of the right side of the graph (and the white point would not be anchored at the top right.) Yup, I'm just letting my thoughts wander here.  :-)

Anyway, with such a steep curve coming out of the white point, surely this would effectively blow out the highest of the highlights a good way down the scale, wouldn't it? Which would make details in the extremes disappear.

John

[Frederic Da Vitoria]

In my experience, the sigmoid tends to stay in the limits of the first
schema in your pdf. A very small deviation has a huge impact so that
if you are not looking for strange-looking results, you tend to stay
close to the diagonal, especially with jpegs where doing too much
correction triggers banding. For example, here are the 3 curves I used
on o1 for lowering contrast, increasing contrast, and the third
D-shaped curve which gives the results closest to faux-bracketing.

2012/12/21, JohnPW <johnpw...@gmail.com>:

>> 2012/12/20 JohnPW <johnpw...@gmail.com <javascript:>>

>>> hugi...@googlegroups.com<javascript:>

>>> To unsubscribe from this group, send email to

>>> hugin-ptx+...@googlegroups.com <javascript:>

[JohnPW]

After working over my vacation to find and understand information on the sigmoidal curve as implemented in ImageMagick, I have concluded (correctly or not) that there is a bug in the implementation of it in IM. The formulas I can find don't work as expected. Specifically the method of scaling the sigmoidal curve appears to be faulty. It works pretty well at high β values (10 or above) and middling α values (between .4-.6.) But outside those limits, the curve wanders off it's endpoints, especially at the origin.

Perhaps this is why the bugbear's script seems not to work quite in the way I expected. (Or perhaps I am wrong?)

In any case, it appears the IM folks are aware of the problem and are impoving it in IM 7 (and making the sigmoidal contrast function more symmetric, and reversible.) It may be that they have already done this and a simple move to the newest version will address it. I can't really tell.

Attached are some graphs I did to see what the various versions of the function were doing.

[JohnPW]

Sorry, I forgot to remove the first 2 pages before posting.

[JohnPW]

And always more information shows up after I post. It looks like this formula improvement may have been made some years ago. I'm not sure what improvement it is they have planned for v7.

I suppose the documentation where they use the faulty formula as an example could be updated ;-)

[bul...@gmail.com]

Great script, using it nearly daily.

But you should change

  my $cmd = "convert $in -sigmoidal-contrast 5x$i\% $o"; 

to

  my $cmd = "convert $in -format tif -compress none -sigmoidal-contrast 5x$i\% $o"; 

or

  my $cmd = "convert $in -format tif -compress lzw -sigmoidal-contrast 5x$i\% $o"; 
since jpeg-compressed TIFFs will be recompressed and lose quality. The same is valid if $in is a jpeg file itself.

Cheers

M. Bullinger


On Tuesday, December 11, 2012 5:06:06 PM UTC+1, bugbear wrote:

JohnPW wrote:
> Why not faux-bracket the source images first, then stack and enfuse them before stitching?
> This is similar to making bracketed images from RAW files (eliminates alignment/movement difficulties common to conventional bracketing.)
> I have to admit, most of my panos are from jpegs shot with cheap point and shoots that don't do RAW (and using TIFF is too onerous.)

I just threw (almost literally) a perl
script together to do this, and the results are impressive.

   BugBear (script appended)

Here it is:

#!/usr/bin/perl

use strict;
use warnings;

sub mk {
     my ($in) = @_;
     my $list;
     for(my $i = 0; $i <= 100; $i += 20) {
        my $o = sprintf("c%03d.tif", $i);
        my $cmd = "convert $in -sigmoidal-contrast 5x$i\% $o";
        `$cmd`;
        $list .= " $o";
     }
     return $list;
}

sub enf {
     my ($out, $list) = @_;
     my $cmd = "enfuse --output=$out $list";
     `$cmd`;
}

unless(scalar(@ARGV) == 2) { die "in, out" };

my $in = $ARGV[0];
my $out = $ARGV[1];
my $list = mk($in);
enf($out, $list);