Workflow for manual 16 bit blending of Hugin panoramas using 8 bit gimp

[torger]

I sometimes need to blend Hugin panoramas partly manually for best
results, for example moving water. I like Gimp's layer masks but find
its 8 bit limitation problem since I want a 16 bit tiff as end result,
so I can adjust colors, exposure etc after the panorama has been
assembled.

Here's a trick to workaround gimp's limitation, using imagemagick and
libtiff tools (also free software). This workflow allows for hand-made
Gimp blending through layer masks, but you cannot do retouching like
clone/heal and such stuff, if required that must be left to a final 8
bit step.

I use Rawtherapee here as raw handling software (free), but you could
be using something else.

The workflow for blending panorama output from Hugin is a bit extra
complicated (compared to just blending normal images) due to cropped
tif images with canvas size larger than the image itself which neither
Gimp or Imagemagick handles well, so one have to do some extra steps.
For 16 bit panorama editing and blending a 64 bit system with lots of
RAM (8 gig or more) is recommended. The TIF files easily get larger
than a gig.

1. Take photos for your panorama
- It's ok to have different exposure on different parts of the
panorama, just make sure there is sufficent overlap so Hugin
can figure out exposure.
- Wide overlap also makes it easier to resolve difficult fitting,
since there's a larger area to do blending in.
2. Develop to 16 bit tiff in RawTherapee, with minimal conversion
settings
- Use a wide gamut icc on output (for example prophoto), so color
space selection can be left to later.
- No sharpening, no curves, no exposure correction, no black level
adjustment etc
- If you want deconvolution sharpening is however preferably
applied here on the individual images.
- No lens distortion correction necessary, Hugin has that built in.
- Enable Highlight reconstruction. This may alter exposure a
little
but Hugin can deal with this.
- CA correction, noise reduction if necessary is ok to apply here.
3. Use Hugin to make the panorama.
- Hand-made control points often superior to auto, especially in
difficult conditions (stuff moving in the pictures)
- Use the image with the brightest highlights as Exposure Anchor
to
avoid clipping
- Select "Remapped images: Exposure corrected, low dynamic range"
as
output. Disable any panorama output, it won't be needed.
- Or maybe you want stitched output too, it may be nice to use
as base and do manual blends only on the difficult parts.
- Cropped tiff output from Nona should be enabled (default).
Unfortunately most tiff programs don't handle cropped tiffs well
either and this workflow becomes much more messy with it, but it
is worth it from a memory consumption perspective (gimp consumes
a lot less memory with cropped layers).
4. Make multipage tiff from Hugin output, using tiffcp.
- Example command: tiffcp ho-0001.tif ho-0002.tif ... ho-000N.tif
multipage.tif
- Multipage tiff is required for Gimp to open all layers with
correct offsets and canvas size.
5. Blend the panorama using Gimp
- If not already done, in preferences increase the allowed RAM
consumption to say 80% of your RAM, hopefully several gigabytes.
Gimp becomes very slow to work with if RAM cache is too small.
- Open the multipage tiff, pages as layers. Convert to 8 bit (will
be done automatically), but keep color space.
- If you by some reason only want a subset of the layers, still
open all layers so that you get the correct canvas size, and
then remove unwanted layers.
- Blend the images in Gimp using layer masks until satisfactory
panorama stitching is achieved
- Save each layer as an individual tiff. Next version of Gimp will
probably support multilayer tiff which will make this step less
cumbersome. There are also some scripts out there to save layers
as tiffs.
- The layer mask should be transferred to the tiff alpha channel
(default).
6. Make flat versions of Hugin tif output to be used for alpha channel
application.
- This is messy but necessary due to poor canvas/offset handling in
imagemagick/gimp.
- You need to know Hugin canvas size and top/left offset, this can
be seen in the Hugin project, or be calculated from the tif,
use tiffinfo to get information:
ImageFullWidth: 12229 (canvas x size)
ImageFullLength: 16187 (canvas y size)
Resolution: 150, 150 pixels/inch
Position: 11.5133, 17.7667 (x offset = resolution * 11.5133 =
150 * 11.5133 = 1727 pixels)
- You also need the crop size, can be found out in Gimp or Hugin
project.
- Make flat, cropped and repaged versions of the hugin output
layers, the canvas size, offset and crop must be given because
imagemagick does not get it:
"convert ho-0000.tif -page 12229x16187 -flatten \
-crop 8736x12291+1727+2665 +repage flat-0000.tif"
7. Apply the alpha channel from the Gimp output on the original 16 bit
Hugin output, using Imagemagick
- "composite -compose Dst_In ho-0000-gimp.tif flat-0000.tif \
masked-0000.tif"
- The masks will of course be 8 bit and up-converted to 16 bit,
but
this is no problem for image quality, since blending is dithered
and the actual blended image data is 16 bit.
8. Combine the masked 16 bit output to one large tiff
- Note that layers must be combined in the same order as they are
in
gimp. Use the same ordering throughout the workflow.
- Imagemagick requires huge amounts of memory if all layers are
combined at once. You may need to do it a few layers at a time.
Example convert 1.tif 2.tif 3.tif -flatten s1.tif
convert s1.tif 4.tif 5.tif -flatten s2.tif
...
convert sN X.tif Y.tif -flatten pano.tif
9. Final processing in RawTherapee
- Color correction, exposure correction, sharpening, shadows/
highligths etc
- This final processing step does not alter the 16 bit panorama
tif
so it can be made over and over again with different settings,
which is a key feature of this workflow.

I hope someone finds it useful. Improvements to the workflow or tips
of other programs that can do this in a simpler way are also welcome.

[David Haberthür]

Hey Torger.

Post by torger
I sometimes need to blend Hugin panoramas partly manually for best
results, for example moving water. I like Gimp's layer masks but find
its 8 bit limitation problem since I want a 16 bit tiff as end result,
so I can adjust colors, exposure etc after the panorama has been
assembled.

[snip]

Post by torger
The workflow for blending panorama output from Hugin is a bit extra
complicated (compared to just blending normal images) due to cropped
tif images with canvas size larger than the image itself which neither
Gimp or Imagemagick handles well, so one have to do some extra steps.
For 16 bit panorama editing and blending a 64 bit system with lots of
RAM (8 gig or more) is recommended. The TIF files easily get larger
than a gig.

[snip]

I confess that I haven't fully read your tutorial/workflow, but have seen that it's very refined and thought out. I suggest you add this to the PanoTools wiki (http://wiki.panotools.org/) so People not following the mainling list (and search engines) can pick it up and it's not buried in the archive of the mailing list.
Also, when adding it there, other people can improve on the workflow as you suggested.

Cheers, Habi

[torger]

Ok! Now it's there:

http://wiki.panotools.org/16_bit_panorama_blending_using_8_bit_Gimp

Post by David Haberthür
Hey Torger.

Post by torger
I sometimes need to blend Hugin panoramas partly manually for best
results, for example moving water. I like Gimp's layer masks but find
its 8 bit limitation problem since I want a 16 bit tiff as end result,
so I can adjust colors, exposure etc after the panorama has been
assembled.

[snip]

Post by torger
The workflow for blending panorama output from Hugin is a bit extra
complicated (compared to just blending normal images) due to cropped
tif images with canvas size larger than the image itself which neither
Gimp or Imagemagick handles well, so one have to do some extra steps.
For 16 bit panorama editing and blending a 64 bit system with lots of
RAM (8 gig or more) is recommended. The TIF files easily get larger
than a gig.

[snip]
I confess that I haven't fully read your tutorial/workflow, but have seen that it's very refined and thought out. I suggest you add this to the PanoTools wiki (http://wiki.panotools.org/) so People not following the mainling list (and search engines) can pick it up and it's not buried in the archive of the mailing list.
Also, when adding it there, other people can improve on the workflow as you suggested.
Cheers, Habi

[kfj]

Post by torger
I sometimes need to blend Hugin panoramas partly manually for best
results, for example moving water. I like Gimp's layer masks but find
its 8 bit limitation problem since I want a 16 bit tiff as end result,
...

Gimp's failure to finally deliver 16 bit output has annoyed me very
much. Most of your work flow consists of circumventing this nuisance.
Thumbs up for your having found a way nevertheless, but I still hope
16 bit will finally come to gimp.

Can it be that difficult? I think they already have some higher-bit
processing under the hood (this GEGL stuff). And I also seem to
remember they had a product vision of themselves to be more of an
image processing software than a paint program. Their scope,
processing-wise, clearly is directed towards serious use. But 8 bits
is amateur stuff. I've almost lost faith in them and try to do my work
in other programs. I sometimes feel they suffer from dinosaur
syndrome. Another case for a clean rewrite? Or can the new shooting
star on the OS image processing scene please step forward?

Kay

[Gnome Nomad]

Post by kfj

Post by torger
I sometimes need to blend Hugin panoramas partly manually for best
results, for example moving water. I like Gimp's layer masks but find
its 8 bit limitation problem since I want a 16 bit tiff as end result,
...

Gimp's failure to finally deliver 16 bit output has annoyed me very
much. Most of your work flow consists of circumventing this nuisance.
Thumbs up for your having found a way nevertheless, but I still hope
16 bit will finally come to gimp.
Can it be that difficult? I think they already have some higher-bit
processing under the hood (this GEGL stuff). And I also seem to
remember they had a product vision of themselves to be more of an
image processing software than a paint program. Their scope,
processing-wise, clearly is directed towards serious use. But 8 bits
is amateur stuff. I've almost lost faith in them and try to do my work
in other programs. I sometimes feel they suffer from dinosaur
syndrome. Another case for a clean rewrite? Or can the new shooting
star on the OS image processing scene please step forward?

I do my photo processing (from 48-bit RAW files) using Bibble Lab's
Bibble Light. Yes, closed source, costs money, but it's a native Linux
app, just about the fastest RAW image processor around, and does all of
its filtering/processing in 48-bit color. (48-bit = 3 16-bit color
channels.) I also use Rawtherapee and UFRaw and such, but they're not
nearly as capable.

GIMP is definitely not in the professional leagues yet. I sometimes
think that they've been so busy optimizing things under the hood for
8-bit color that they're kind of painting themselves into a corner when
it comes to 16-bit color. Or they just figure that nobody really needs
16-bit color ...
--
Gnome Nomad
***@gmail.com
wandering the landscape of god
http://www.cafepress.com/otherend/

[torger]

Actually why Gimp does not have 16 bit is because many/most do think
it is not important. That you don't see any difference between 16 and
8 bit. And sure, if you downsample 16 bit to 8 you typically don't see
any difference (especially if the downsampling does dithering), and
discussion has usually ended there. However, as we know 16 bit
workflow is about being able to save color correction, color space
reduction, curves, exposure tuning, highlight/shadow tuning etc to
last rather than having to do it first (before stitching in case of
panoramas, which is difficult). Making an 8 bit tiff with prophoto
color space and then start do all that processing on that and you have
true banding problems.

The wide availability of competent Raw developer software and better
cameras with higher dynamic range is however starting to change
things. More and more people start becoming aware of the merits of 16
bit editing. Today 16 bit editing is a much more wanted feature than
just a few years ago. Hopefully the Gimp team is becoming aware of
that, but it seems to me that they could use a helping hand -- there
are too few developers and too much to do currently...

I also own Bibble but has only so far used the 32 bit version and it
cannot handle more than 30 megapixels or so, not sure what the 64 bit
version can do. I've learnt RawTherapee followed the developer
versions and get very good results out of it (I think it produces
better image quality than Bibble) so for my "fine art" photography it
has become my raw developer of choice. It has no problem of dealing
very large 16 bit tiff files either, as long as it is the 64 bit
version and the computer has enough RAM.

Post by Gnome Nomad

Post by kfj

Post by torger
I sometimes need to blend Hugin panoramas partly manually for best
results, for example moving water. I like Gimp's layer masks but find
its 8 bit limitation problem since I want a 16 bit tiff as end result,
...

Gimp's failure to finally deliver 16 bit output has annoyed me very
much. Most of your work flow consists of circumventing this nuisance.
Thumbs up for your having found a way nevertheless, but I still hope
16 bit will finally come to gimp.
Can it be that difficult? I think they already have some higher-bit
processing under the hood (this GEGL stuff). And I also seem to
remember they had a product vision of themselves to be more of an
image processing software than a paint program. Their scope,
processing-wise, clearly is directed towards serious use. But 8 bits
is amateur stuff. I've almost lost faith in them and try to do my work
in other programs. I sometimes feel they suffer from dinosaur
syndrome. Another case for a clean rewrite? Or can the new shooting
star on the OS image processing scene please step forward?

I do my photo processing (from 48-bit RAW files) using Bibble Lab's
Bibble Light. Yes, closed source, costs money, but it's a native Linux
app, just about the fastest RAW image processor around, and does all of
its filtering/processing in 48-bit color. (48-bit = 3 16-bit color
channels.) I also use Rawtherapee and UFRaw and such, but they're not
nearly as capable.
GIMP is definitely not in the professional leagues yet. I sometimes
think that they've been so busy optimizing things under the hood for
8-bit color that they're kind of painting themselves into a corner when
it comes to 16-bit color. Or they just figure that nobody really needs
16-bit color ...
--
Gnome Nomad
wandering the landscape of godhttp://www.cafepress.com/otherend/

[paul womack]

Post by torger
Actually why Gimp does not have 16 bit is because many/most do think
it is not important. That you don't see any difference between 16 and
8 bit.

Some algorithms (esp the many MANY filters, often
from third parties) may well be coded using lookup tables,
and byte packing (you can usefully pack RGB into
a single 32 bit value for "bulk" processing).

I (for example) have used an AxB lookup
table, where A and B are bytes, to implement
alpha masking. The table has 65536 entries.
If A and B are 16 bit, the lookup
table gets a good deal bigger.

These tricks are used to give user-friendly
speed.

So changing to 16 bit may involve not just recompilation
with different typedefs, but re-evaluation
of algorithms, and some reimplementation.

BugBear

[Carlos Eduardo G. Carvalho (Cartola)]

Hi Toger and others,

I understand your point of view. I have already tried to shoot raw and have
used RawTherapy and ufraw. After some tries and comparing the final results
with the one using same pictures as JPGs, I decided to stop shooting raw,
because my eyes really didn't see difference and working with raw takes more
time. I usually use only 8 bit JPGs also for HDR, enfuse and tonemapping
jobs.

For example, I have already made a test with one picture. I shoot it in
raw+jpg and manipulated it to make a lower and a higher exposition pic so I
could then make an HDR or a simple enfuse. I really found the result of the
JPGs equal or even better then the one obtained with the raw - maybe I am
clever with the JPGs tools :)

I spite of that, I always feel that I could have failed somehow and that I
am loosing something. If so many people use raw it might be better. Can you
or somebody here give me some references, hints, tips so I can try to find
that thing I lost and maybe be really impressed by the difference of working
with raw and 16 bit tiff?

Thanks, Cartola.

Post by torger
Actually why Gimp does not have 16 bit is because many/most do think
it is not important. That you don't see any difference between 16 and
8 bit. And sure, if you downsample 16 bit to 8 you typically don't see
any difference (especially if the downsampling does dithering), and
discussion has usually ended there. However, as we know 16 bit
workflow is about being able to save color correction, color space
reduction, curves, exposure tuning, highlight/shadow tuning etc to
last rather than having to do it first (before stitching in case of
panoramas, which is difficult). Making an 8 bit tiff with prophoto
color space and then start do all that processing on that and you have
true banding problems.
The wide availability of competent Raw developer software and better
cameras with higher dynamic range is however starting to change
things. More and more people start becoming aware of the merits of 16
bit editing. Today 16 bit editing is a much more wanted feature than
just a few years ago. Hopefully the Gimp team is becoming aware of
that, but it seems to me that they could use a helping hand -- there
are too few developers and too much to do currently...
I also own Bibble but has only so far used the 32 bit version and it
cannot handle more than 30 megapixels or so, not sure what the 64 bit
version can do. I've learnt RawTherapee followed the developer
versions and get very good results out of it (I think it produces
better image quality than Bibble) so for my "fine art" photography it
has become my raw developer of choice. It has no problem of dealing
very large 16 bit tiff files either, as long as it is the 64 bit
version and the computer has enough RAM.

Post by Gnome Nomad

Post by kfj

Post by torger
I sometimes need to blend Hugin panoramas partly manually for best
results, for example moving water. I like Gimp's layer masks but find
its 8 bit limitation problem since I want a 16 bit tiff as end result,
...

Gimp's failure to finally deliver 16 bit output has annoyed me very
much. Most of your work flow consists of circumventing this nuisance.
Thumbs up for your having found a way nevertheless, but I still hope
16 bit will finally come to gimp.
Can it be that difficult? I think they already have some higher-bit
processing under the hood (this GEGL stuff). And I also seem to
remember they had a product vision of themselves to be more of an
image processing software than a paint program. Their scope,
processing-wise, clearly is directed towards serious use. But 8 bits
is amateur stuff. I've almost lost faith in them and try to do my work
in other programs. I sometimes feel they suffer from dinosaur
syndrome. Another case for a clean rewrite? Or can the new shooting
star on the OS image processing scene please step forward?

I do my photo processing (from 48-bit RAW files) using Bibble Lab's
Bibble Light. Yes, closed source, costs money, but it's a native Linux
app, just about the fastest RAW image processor around, and does all of
its filtering/processing in 48-bit color. (48-bit = 3 16-bit color
channels.) I also use Rawtherapee and UFRaw and such, but they're not
nearly as capable.
GIMP is definitely not in the professional leagues yet. I sometimes
think that they've been so busy optimizing things under the hood for
8-bit color that they're kind of painting themselves into a corner when
it comes to 16-bit color. Or they just figure that nobody really needs
16-bit color ...
--
Gnome Nomad
wandering the landscape of godhttp://www.cafepress.com/otherend/

--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
http://wiki.panotools.org/Hugin_FAQ
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/hugin-ptx

[torger]

Getting good results out of a raw developer can be quite difficult, it
takes some practice. The free tools are not the easiest to work with.
Lightroom is probably "the best" concerning user friendliness etc, but
with the newly released RawTherapee 3.0 it is also a very competent
tool that can produce very good results, but it is not like pressing a
button and out comes a perfect picture, one have to do lots of manual
tuning.

Working with RAW takes more time, it can take a lot of more time.
Especially when newbie so it takes longer time to find suitable
parameters.

When using JPEG, the camera itself has done tone-mapping, contrast,
white balance etc decisions for you. Altering them is possible to some
extent, but the larger the changes you do the more of a problem it is
that it is only 8 bit and some info from the raw file has already been
thrown away.

One could say that working with RAW instead of JPEG is more about
creative control than quality.

To create a great landscape picture to make a print to hang on the
wall you may need to optimize clouds separately from the water, and
that separately from the forest or whatever is in the picture. You
develop several layers from the same raw file and merge them together
in an external software (many of the commercial raw developers support
layers in them). Perhaps you work for days on that single image. Doing
such operations on JPEG input does not make sense.

When changes are small, and there is low dynamic range in the picture
etc, 8 bit JPEG may work just fine. But when you start to want to do
changes like described above there is a major risk not shooting RAW
and not having 16 bit workflow, since you may run into trouble further
down the workflow.

Then there are single key features that can have very high value --
superior highlight reconstruction is very valuable to me as a
landscape photographer which often stretch the dynamic range of the
camera. With JPEG the camera has done the highlight reconstruction
already (which uses a safe rather than the best algorithm) and no
further can be made. Pushing shadows is also common in landscape
photography or other conditions when you don't have 100% control of
the lighting, and then it is valuable to have that extra dynamic range
the RAW file provides. The better the dynamic range gets in the
cameras, the more valuable RAW format will be, because it becomes a
larger difference between what JPEG can represent and what the camera
can capture.

The raw developers such as RawTherapee also have nice features
concerning sharpening, color correction, tone mapping etc, although
that can to some extent be performed on JPEGs, it works better on RAW,
so if you want to do that kind of image processing it is natural to
shoot RAW.

If you're happy with what the camera does for you, then it's fine. If
all you do is stitch and do no postprocessing on that, 8 bit JPEG is
fine. Some of us like to have more control though.

On Aug 4, 2:20 pm, "Carlos Eduardo G. Carvalho (Cartola)"

Post by Carlos Eduardo G. Carvalho (Cartola)
Hi Toger and others,
I understand your point of view. I have already tried to shoot raw and have
used RawTherapy and ufraw. After some tries and comparing the final results
with the one using same pictures as JPGs, I decided to stop shooting raw,
because my eyes really didn't see difference and working with raw takes more
time. I usually use only 8 bit JPGs also for HDR, enfuse and tonemapping
jobs.
For example, I have already made a test with one picture. I shoot it in
raw+jpg and manipulated it to make a lower and a higher exposition pic so I
could then make an HDR or a simple enfuse. I really found the result of the
JPGs equal or even better then the one obtained with the raw - maybe I am
clever with the JPGs tools :)
I spite of that, I always feel that I could have failed somehow and that I
am loosing something. If so many people use raw it might be better. Can you
or somebody here give me some references, hints, tips so I can try to find
that thing I lost and maybe be really impressed by the difference of working
with raw and 16 bit tiff?
Thanks, Cartola.

Post by torger
Actually why Gimp does not have 16 bit is because many/most do think
it is not important. That you don't see any difference between 16 and
8 bit. And sure, if you downsample 16 bit to 8 you typically don't see
any difference (especially if the downsampling does dithering), and
discussion has usually ended there. However, as we know 16 bit
workflow is about being able to save color correction, color space
reduction, curves, exposure tuning, highlight/shadow tuning etc to
last rather than having to do it first (before stitching in case of
panoramas, which is difficult). Making an 8 bit tiff with prophoto
color space and then start do all that processing on that and you have
true banding problems.
The wide availability of competent Raw developer software and better
cameras with higher dynamic range is however starting to change
things. More and more people start becoming aware of the merits of 16
bit editing. Today 16 bit editing is a much more wanted feature than
just a few years ago. Hopefully the Gimp team is becoming aware of
that, but it seems to me that they could use a helping hand -- there
are too few developers and too much to do currently...
I also own Bibble but has only so far used the 32 bit version and it
cannot handle more than 30 megapixels or so, not sure what the 64 bit
version can do. I've learnt RawTherapee followed the developer
versions and get very good results out of it (I think it produces
better image quality than Bibble) so for my "fine art" photography it
has become my raw developer of choice. It has no problem of dealing
very large 16 bit tiff files either, as long as it is the 64 bit
version and the computer has enough RAM.

Post by Gnome Nomad

Post by kfj

Post by torger
I sometimes need to blend Hugin panoramas partly manually for best
results, for example moving water. I like Gimp's layer masks but find
its 8 bit limitation problem since I want a 16 bit tiff as end result,
...

Gimp's failure to finally deliver 16 bit output has annoyed me very
much. Most of your work flow consists of circumventing this nuisance.
Thumbs up for your having found a way nevertheless, but I still hope
16 bit will finally come to gimp.
Can it be that difficult? I think they already have some higher-bit
processing under the hood (this GEGL stuff). And I also seem to
remember they had a product vision of themselves to be more of an
image processing software than a paint program. Their scope,
processing-wise, clearly is directed towards serious use. But 8 bits
is amateur stuff. I've almost lost faith in them and try to do my work
in other programs. I sometimes feel they suffer from dinosaur
syndrome. Another case for a clean rewrite? Or can the new shooting
star on the OS image processing scene please step forward?

I do my photo processing (from 48-bit RAW files) using Bibble Lab's
Bibble Light. Yes, closed source, costs money, but it's a native Linux
app, just about the fastest RAW image processor around, and does all of
its filtering/processing in 48-bit color. (48-bit = 3 16-bit color
channels.) I also use Rawtherapee and UFRaw and such, but they're not
nearly as capable.
GIMP is definitely not in the professional leagues yet. I sometimes
think that they've been so busy optimizing things under the hood for
8-bit color that they're kind of painting themselves into a corner when
it comes to 16-bit color. Or they just figure that nobody really needs
16-bit color ...
--
Gnome Nomad
wandering the landscape of godhttp://www.cafepress.com/otherend/

--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
http://wiki.panotools.org/Hugin_FAQ
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/hugin-ptx

[torger]

Oh, one more thing. Nowadays cameras get more and more advanced "tone
mapping" settings to deal with how to compress the extra dynamic range
the newer cameras can capture into a JPEG. If you work with RAW, it is
your own artistic decision how you tone map your image.

With a 16 bit workflow you can be more "careless" (=flexible), that is
you can for example use prophoto color space although it is larger
than necessary, and you can have more than one exposure/color
correction step etc. With 8 bit you need to take care to maximize the
use of every bit and be careful not to degrade the quality in follow
on processing.

Anyway, there are several smaller reasons why you would want to shoot
RAW and have 16 bit workflows that together add up to the decision to
go that way, but it is a bit hard to come up with a single short
answer. You have to make your own decision if you need it or not.

Looking at what professionals do, RAW shooting, lightroom and
photoshop (does 16 bit) is kind of industry standard. If you as an
amateur want to use free software and still have the ability to have a
professional workflow, things are today actually looking quite good
with one exception - there's no good free software photoshop
alternative for photographers. If Gimp would be 16 bit it would be,
but it is not. As some have pointed out it is unfortunately not as
trivial as one may think to make Gimp support 16 bit, so it probably
won't happen still for a few years.

But as always, if one really needs it there are commercial
alternatives. The above trick with gimp/imagemagick helps me to do 16
bit workflows in most cases though, so I personally don't need
photoshop just yet... :-)

Post by torger
Getting good results out of a raw developer can be quite difficult, it
takes some practice. The free tools are not the easiest to work with.
Lightroom is probably "the best" concerning user friendliness etc, but
with the newly released RawTherapee 3.0 it is also a very competent
tool that can produce very good results, but it is not like pressing a
button and out comes a perfect picture, one have to do lots of manual
tuning.
Working with RAW takes more time, it can take a lot of more time.
Especially when newbie so it takes longer time to find suitable
parameters.
When using JPEG, the camera itself has done tone-mapping, contrast,
white balance etc decisions for you. Altering them is possible to some
extent, but the larger the changes you do the more of a problem it is
that it is only 8 bit and some info from the raw file has already been
thrown away.
One could say that working with RAW instead of JPEG is more about
creative control than quality.
To create a great landscape picture to make a print to hang on the
wall you may need to optimize clouds separately from the water, and
that separately from the forest or whatever is in the picture. You
develop several layers from the same raw file and merge them together
in an external software (many of the commercial raw developers support
layers in them). Perhaps you work for days on that single image. Doing
such operations on JPEG input does not make sense.
When changes are small, and there is low dynamic range in the picture
etc, 8 bit JPEG may work just fine. But when you start to want to do
changes like described above there is a major risk not shooting RAW
and not having 16 bit workflow, since you may run into trouble further
down the workflow.
Then there are single key features that can have very high value --
superior highlight reconstruction is very valuable to me as a
landscape photographer which often stretch the dynamic range of the
camera. With JPEG the camera has done the highlight reconstruction
already (which uses a safe rather than the best algorithm) and no
further can be made. Pushing shadows is also common in landscape
photography or other conditions when you don't have 100% control of
the lighting, and then it is valuable to have that extra dynamic range
the RAW file provides. The better the dynamic range gets in the
cameras, the more valuable RAW format will be, because it becomes a
larger difference between what JPEG can represent and what the camera
can capture.
The raw developers such as RawTherapee also have nice features
concerning sharpening, color correction, tone mapping etc, although
that can to some extent be performed on JPEGs, it works better on RAW,
so if you want to do that kind of image processing it is natural to
shoot RAW.
If you're happy with what the camera does for you, then it's fine. If
all you do is stitch and do no postprocessing on that, 8 bit JPEG is
fine. Some of us like to have more control though.
On Aug 4, 2:20 pm, "Carlos Eduardo G. Carvalho (Cartola)"

Post by Carlos Eduardo G. Carvalho (Cartola)
Hi Toger and others,
I understand your point of view. I have already tried to shoot raw and have
used RawTherapy and ufraw. After some tries and comparing the final results
with the one using same pictures as JPGs, I decided to stop shooting raw,
because my eyes really didn't see difference and working with raw takes more
time. I usually use only 8 bit JPGs also for HDR, enfuse and tonemapping
jobs.
For example, I have already made a test with one picture. I shoot it in
raw+jpg and manipulated it to make a lower and a higher exposition pic so I
could then make an HDR or a simple enfuse. I really found the result of the
JPGs equal or even better then the one obtained with the raw - maybe I am
clever with the JPGs tools :)
I spite of that, I always feel that I could have failed somehow and that I
am loosing something. If so many people use raw it might be better. Can you
or somebody here give me some references, hints, tips so I can try to find
that thing I lost and maybe be really impressed by the difference of working
with raw and 16 bit tiff?
Thanks, Cartola.

Post by torger
Actually why Gimp does not have 16 bit is because many/most do think
it is not important. That you don't see any difference between 16 and
8 bit. And sure, if you downsample 16 bit to 8 you typically don't see
any difference (especially if the downsampling does dithering), and
discussion has usually ended there. However, as we know 16 bit
workflow is about being able to save color correction, color space
reduction, curves, exposure tuning, highlight/shadow tuning etc to
last rather than having to do it first (before stitching in case of
panoramas, which is difficult). Making an 8 bit tiff with prophoto
color space and then start do all that processing on that and you have
true banding problems.
The wide availability of competent Raw developer software and better
cameras with higher dynamic range is however starting to change
things. More and more people start becoming aware of the merits of 16
bit editing. Today 16 bit editing is a much more wanted feature than
just a few years ago. Hopefully the Gimp team is becoming aware of
that, but it seems to me that they could use a helping hand -- there
are too few developers and too much to do currently...
I also own Bibble but has only so far used the 32 bit version and it
cannot handle more than 30 megapixels or so, not sure what the 64 bit
version can do. I've learnt RawTherapee followed the developer
versions and get very good results out of it (I think it produces
better image quality than Bibble) so for my "fine art" photography it
has become my raw developer of choice. It has no problem of dealing
very large 16 bit tiff files either, as long as it is the 64 bit
version and the computer has enough RAM.

Post by Gnome Nomad

Post by kfj

Post by torger
I sometimes need to blend Hugin panoramas partly manually for best
results, for example moving water. I like Gimp's layer masks but find
its 8 bit limitation problem since I want a 16 bit tiff as end result,
...

Gimp's failure to finally deliver 16 bit output has annoyed me very
much. Most of your work flow consists of circumventing this nuisance.
Thumbs up for your having found a way nevertheless, but I still hope
16 bit will finally come to gimp.
Can it be that difficult? I think they already have some higher-bit
processing under the hood (this GEGL stuff). And I also seem to
remember they had a product vision of themselves to be more of an
image processing software than a paint program. Their scope,
processing-wise, clearly is directed towards serious use. But 8 bits
is amateur stuff. I've almost lost faith in them and try to do my work
in other programs. I sometimes feel they suffer from dinosaur
syndrome. Another case for a clean rewrite? Or can the new shooting
star on the OS image processing scene please step forward?

I do my photo processing (from 48-bit RAW files) using Bibble Lab's
Bibble Light. Yes, closed source, costs money, but it's a native Linux
app, just about the fastest RAW image processor around, and does all of
its filtering/processing in 48-bit color. (48-bit = 3 16-bit color
channels.) I also use Rawtherapee and UFRaw and such, but they're not
nearly as capable.
GIMP is definitely not in the professional leagues yet. I sometimes
think that they've been so busy optimizing things under the hood for
8-bit color that they're kind of painting themselves into a corner when
it comes to 16-bit color. Or they just figure that nobody really needs
16-bit color ...
--
Gnome Nomad
wandering the landscape of godhttp://www.cafepress.com/otherend/

--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
http://wiki.panotools.org/Hugin_FAQ
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/hugin-ptx- Dölj citerad text -

- Visa citerad text -

[kfj]

Post by torger
Oh, one more thing. Nowadays cameras get more and more advanced "tone
mapping" settings to deal with how to compress the extra dynamic range
the newer cameras can capture into a JPEG. If you work with RAW, it is
your own artistic decision how you tone map your image.
...

as is pretty much everything else. You can change the white balance,
for example, with the exact same results you would have got from
setting it differently on the camera. The only thing you can't do is
change the actual exposure of the sensor.

In my long experience with computers I've learned one thing: If I have
high-quality data, I keep them in their native format or in a
losslessly compressed version of it. Moore's law will take care of the
rest - storage expenses, processing power... but once you let go of
the high quality data, you can never recover, and a few years down the
line you'll rue it.

Kay

[Carlos Eduardo G. Carvalho (Cartola)]

Post by kfj

Post by torger
Oh, one more thing. Nowadays cameras get more and more advanced "tone
mapping" settings to deal with how to compress the extra dynamic range
the newer cameras can capture into a JPEG. If you work with RAW, it is
your own artistic decision how you tone map your image.
...

as is pretty much everything else. You can change the white balance,
for example, with the exact same results you would have got from
setting it differently on the camera. The only thing you can't do is
change the actual exposure of the sensor.
In my long experience with computers I've learned one thing: If I have
high-quality data, I keep them in their native format or in a
losslessly compressed version of it. Moore's law will take care of the
rest - storage expenses, processing power... but once you let go of
the high quality data, you can never recover, and a few years down the
line you'll rue it.

Oh yeah, in this you are totally right! I am a Unix system analist since
1992... have already learned that. The problem is that I don't do that in my
personal life :) How often do one make backups at home? I am lazy with that
too :(

Recently (2009/2010 I guess) I have erased the original separated pics after
have finished a 360x180 panorama. At that time I didn't know it was possible
to separate the images in cube format to easily edit the nadir...

Post by kfj
Kay
--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
http://wiki.panotools.org/Hugin_FAQ
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/hugin-ptx

[Carlos Eduardo G. Carvalho (Cartola)]

I see. I'd like to thank you very very much for the long and clarifying
message. I'm surely going to give it a try again. I'm a unix guy so usually
not afraid of reading, learning and command line things. With your
information I guess I can focus on what can make some difference. I also do
many landscape shoots and sometimes I really think the picture could be
better. Here is an example:

http://wp.me/p1AGa0-5R

It was the end of the day, few light. I had to use a very high ISO value as
I was using a long pole (6m/19.7ft) and the wind didn't let me use longer
shutter times. The machine didn't stop, making it also difficult to make
auto bracketing as it would do one longer shot. The scene has high dynamic
ranges. I had to do that pseudo HDR with enfuse with 3 images from the
original JPG to simulate different expositions. As I said I am only shooting
in JPG now, but I really think this could be a very good situation to test
raw processing.

Do you have or know anywhere where I can see samples done with and without
raw? I have already seen some, but none have called my attention very much.

Thanks!

Post by torger
Oh, one more thing. Nowadays cameras get more and more advanced "tone
mapping" settings to deal with how to compress the extra dynamic range
the newer cameras can capture into a JPEG. If you work with RAW, it is
your own artistic decision how you tone map your image.
With a 16 bit workflow you can be more "careless" (=flexible), that is
you can for example use prophoto color space although it is larger
than necessary, and you can have more than one exposure/color
correction step etc. With 8 bit you need to take care to maximize the
use of every bit and be careful not to degrade the quality in follow
on processing.
Anyway, there are several smaller reasons why you would want to shoot
RAW and have 16 bit workflows that together add up to the decision to
go that way, but it is a bit hard to come up with a single short
answer. You have to make your own decision if you need it or not.
Looking at what professionals do, RAW shooting, lightroom and
photoshop (does 16 bit) is kind of industry standard. If you as an
amateur want to use free software and still have the ability to have a
professional workflow, things are today actually looking quite good
with one exception - there's no good free software photoshop
alternative for photographers. If Gimp would be 16 bit it would be,
but it is not. As some have pointed out it is unfortunately not as
trivial as one may think to make Gimp support 16 bit, so it probably
won't happen still for a few years.
But as always, if one really needs it there are commercial
alternatives. The above trick with gimp/imagemagick helps me to do 16
bit workflows in most cases though, so I personally don't need
photoshop just yet... :-)

Post by torger
Getting good results out of a raw developer can be quite difficult, it
takes some practice. The free tools are not the easiest to work with.
Lightroom is probably "the best" concerning user friendliness etc, but
with the newly released RawTherapee 3.0 it is also a very competent
tool that can produce very good results, but it is not like pressing a
button and out comes a perfect picture, one have to do lots of manual
tuning.
Working with RAW takes more time, it can take a lot of more time.
Especially when newbie so it takes longer time to find suitable
parameters.
When using JPEG, the camera itself has done tone-mapping, contrast,
white balance etc decisions for you. Altering them is possible to some
extent, but the larger the changes you do the more of a problem it is
that it is only 8 bit and some info from the raw file has already been
thrown away.
One could say that working with RAW instead of JPEG is more about
creative control than quality.
To create a great landscape picture to make a print to hang on the
wall you may need to optimize clouds separately from the water, and
that separately from the forest or whatever is in the picture. You
develop several layers from the same raw file and merge them together
in an external software (many of the commercial raw developers support
layers in them). Perhaps you work for days on that single image. Doing
such operations on JPEG input does not make sense.
When changes are small, and there is low dynamic range in the picture
etc, 8 bit JPEG may work just fine. But when you start to want to do
changes like described above there is a major risk not shooting RAW
and not having 16 bit workflow, since you may run into trouble further
down the workflow.
Then there are single key features that can have very high value --
superior highlight reconstruction is very valuable to me as a
landscape photographer which often stretch the dynamic range of the
camera. With JPEG the camera has done the highlight reconstruction
already (which uses a safe rather than the best algorithm) and no
further can be made. Pushing shadows is also common in landscape
photography or other conditions when you don't have 100% control of
the lighting, and then it is valuable to have that extra dynamic range
the RAW file provides. The better the dynamic range gets in the
cameras, the more valuable RAW format will be, because it becomes a
larger difference between what JPEG can represent and what the camera
can capture.
The raw developers such as RawTherapee also have nice features
concerning sharpening, color correction, tone mapping etc, although
that can to some extent be performed on JPEGs, it works better on RAW,
so if you want to do that kind of image processing it is natural to
shoot RAW.
If you're happy with what the camera does for you, then it's fine. If
all you do is stitch and do no postprocessing on that, 8 bit JPEG is
fine. Some of us like to have more control though.
On Aug 4, 2:20 pm, "Carlos Eduardo G. Carvalho (Cartola)"

Post by Carlos Eduardo G. Carvalho (Cartola)
Hi Toger and others,
I understand your point of view. I have already tried to shoot raw and

have

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
used RawTherapy and ufraw. After some tries and comparing the final

results

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
with the one using same pictures as JPGs, I decided to stop shooting

raw,

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
because my eyes really didn't see difference and working with raw takes

more

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
time. I usually use only 8 bit JPGs also for HDR, enfuse and

tonemapping

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
jobs.
For example, I have already made a test with one picture. I shoot it in
raw+jpg and manipulated it to make a lower and a higher exposition pic

so I

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
could then make an HDR or a simple enfuse. I really found the result of

the

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
JPGs equal or even better then the one obtained with the raw - maybe I

am

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
clever with the JPGs tools :)
I spite of that, I always feel that I could have failed somehow and

that I

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
am loosing something. If so many people use raw it might be better. Can

you

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
or somebody here give me some references, hints, tips so I can try to

find

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
that thing I lost and maybe be really impressed by the difference of

working

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
with raw and 16 bit tiff?
Thanks, Cartola.

Post by torger
Actually why Gimp does not have 16 bit is because many/most do think
it is not important. That you don't see any difference between 16 and
8 bit. And sure, if you downsample 16 bit to 8 you typically don't

see

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger
any difference (especially if the downsampling does dithering), and
discussion has usually ended there. However, as we know 16 bit
workflow is about being able to save color correction, color space
reduction, curves, exposure tuning, highlight/shadow tuning etc to
last rather than having to do it first (before stitching in case of
panoramas, which is difficult). Making an 8 bit tiff with prophoto
color space and then start do all that processing on that and you

have

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger
true banding problems.
The wide availability of competent Raw developer software and better
cameras with higher dynamic range is however starting to change
things. More and more people start becoming aware of the merits of 16
bit editing. Today 16 bit editing is a much more wanted feature than
just a few years ago. Hopefully the Gimp team is becoming aware of
that, but it seems to me that they could use a helping hand -- there
are too few developers and too much to do currently...
I also own Bibble but has only so far used the 32 bit version and it
cannot handle more than 30 megapixels or so, not sure what the 64 bit
version can do. I've learnt RawTherapee followed the developer
versions and get very good results out of it (I think it produces
better image quality than Bibble) so for my "fine art" photography it
has become my raw developer of choice. It has no problem of dealing
very large 16 bit tiff files either, as long as it is the 64 bit
version and the computer has enough RAM.

Post by Gnome Nomad

Post by kfj

Post by torger
I sometimes need to blend Hugin panoramas partly manually for

best

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad

Post by kfj

Post by torger
results, for example moving water. I like Gimp's layer masks but

find

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad

Post by kfj

Post by torger
its 8 bit limitation problem since I want a 16 bit tiff as end

result,

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad

Post by kfj

Post by torger
...

Gimp's failure to finally deliver 16 bit output has annoyed me

very

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad

Post by kfj
much. Most of your work flow consists of circumventing this

nuisance.

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad

Post by kfj
Thumbs up for your having found a way nevertheless, but I still

hope

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad

Post by kfj
16 bit will finally come to gimp.
Can it be that difficult? I think they already have some

higher-bit

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad

Post by kfj
processing under the hood (this GEGL stuff). And I also seem to
remember they had a product vision of themselves to be more of an
image processing software than a paint program. Their scope,
processing-wise, clearly is directed towards serious use. But 8

bits

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad

Post by kfj
is amateur stuff. I've almost lost faith in them and try to do my

work

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad

Post by kfj
in other programs. I sometimes feel they suffer from dinosaur
syndrome. Another case for a clean rewrite? Or can the new

shooting

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad

Post by kfj
star on the OS image processing scene please step forward?

I do my photo processing (from 48-bit RAW files) using Bibble Lab's
Bibble Light. Yes, closed source, costs money, but it's a native

Linux

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad
app, just about the fastest RAW image processor around, and does

all of

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad
its filtering/processing in 48-bit color. (48-bit = 3 16-bit color
channels.) I also use Rawtherapee and UFRaw and such, but they're

not

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad
nearly as capable.
GIMP is definitely not in the professional leagues yet. I sometimes
think that they've been so busy optimizing things under the hood

for

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad
8-bit color that they're kind of painting themselves into a corner

when

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad
it comes to 16-bit color. Or they just figure that nobody really

needs

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by Gnome Nomad
16-bit color ...
--
Gnome Nomad
wandering the landscape of godhttp://www.cafepress.com/otherend/

--
You received this message because you are subscribed to the Google

Groups

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger
"Hugin and other free panoramic software" group.
http://wiki.panotools.org/Hugin_FAQ
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/hugin-ptx- Dölj citerad text -

- Visa citerad text -

--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
http://wiki.panotools.org/Hugin_FAQ
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/hugin-ptx

[torger]

On Aug 4, 9:43 pm, "Carlos Eduardo G. Carvalho (Cartola)"

Post by Carlos Eduardo G. Carvalho (Cartola)
Do you have or know anywhere where I can see samples done with and without
raw? I have already seen some, but none have called my attention very much.
Thanks!

Just for fun, I took a Canon G11 compact camera hand held shot for
which I had both JPG and RAW, and made a RAW conversion. It is not the
best quality of the source material, a bit noisy and unsharp, but an
interesting comparison nevertheless. I made my creative conversion a
bit "over the top" on purpose.

Unprocessed JPEG from camera highest quality (cropped the top though
for better composition):
Loading Image...

Here's the creative RAW conversion:
Loading Image...

Here's when I have tried to replicate as close as possible the same
creative conversion but basing it on the original jpeg:
Loading Image...

My intention of the creative composition was to enhance the sunlight
and make it as saturated as experienced at sight, and increase
generally the contrast in the clouds.

Some observations:

- You can make the same conversion using JPEG as source, so you get
the same image but with worse technical quality.
- The RAW version may look more noisy, because it has not been jpeg
compressed and noise was so low that I did not reduce it further.
Random noise is better to keep for prints than removing it which dulls
colors and kills detail.
- On a quick view of reduced size images the JPEG version may look
better.
- Banding/block artifacts not visible in the orignal jpeg has become
visible after processing, for example in the bright parts of the sky.
- The RAW conversion gains from highlight recovery in the brightest
part of sunlight.
- The RAW conversion has a bit better detail, no smearing from JPEG
compression
- The JPG conversion has lost details in the low contrast parts of the
remote landscape due to lack of tones, which are still there in the
RAW conversion
- I did not correct CA for the JPEG, was not easy to do with my
software (rawtherapee), but automatic for RAW.

In short - don't expect RAW and 16 bit workflows to "blow you away",
there are a number of subtle quality improvements which at least I
find important. I don't like the idea of spending lots and lots of
money on cameras and lenses just to throw away quality in post.

[Carlos Eduardo G. Carvalho (Cartola)]

Torger, I'd like to thank you very much again. I've explained many points
that I need to understand better. I'll really try to learn more about raw
and its post processing details. Thank you for these image examples, I
really appreciated. I have already printed in big sizes from some little
planets based on my 360 panos and I think this is an example where a raw
original file can make difference. I guess printed images show some details
you can't see on the screen.

Thanks!

Carlos E G Carvalho (Cartola)
http://cartola.org/360

On Aug 4, 9:43 pm, "Carlos Eduardo G. Carvalho (Cartola)"

Post by Carlos Eduardo G. Carvalho (Cartola)
Do you have or know anywhere where I can see samples done with and

without

Post by Carlos Eduardo G. Carvalho (Cartola)
raw? I have already seen some, but none have called my attention very

much.

Post by Carlos Eduardo G. Carvalho (Cartola)
Thanks!

Just for fun, I took a Canon G11 compact camera hand held shot for
which I had both JPG and RAW, and made a RAW conversion. It is not the
best quality of the source material, a bit noisy and unsharp, but an
interesting comparison nevertheless. I made my creative conversion a
bit "over the top" on purpose.
Unprocessed JPEG from camera highest quality (cropped the top though
http://www.torger.org/temp/img_jpg_unprocessed.jpg
http://www.torger.org/temp/img_from_raw.png
Here's when I have tried to replicate as close as possible the same
http://www.torger.org/temp/img_from_jpg.png
My intention of the creative composition was to enhance the sunlight
and make it as saturated as experienced at sight, and increase
generally the contrast in the clouds.
- You can make the same conversion using JPEG as source, so you get
the same image but with worse technical quality.
- The RAW version may look more noisy, because it has not been jpeg
compressed and noise was so low that I did not reduce it further.
Random noise is better to keep for prints than removing it which dulls
colors and kills detail.
- On a quick view of reduced size images the JPEG version may look
better.
- Banding/block artifacts not visible in the orignal jpeg has become
visible after processing, for example in the bright parts of the sky.
- The RAW conversion gains from highlight recovery in the brightest
part of sunlight.
- The RAW conversion has a bit better detail, no smearing from JPEG
compression
- The JPG conversion has lost details in the low contrast parts of the
remote landscape due to lack of tones, which are still there in the
RAW conversion
- I did not correct CA for the JPEG, was not easy to do with my
software (rawtherapee), but automatic for RAW.
In short - don't expect RAW and 16 bit workflows to "blow you away",
there are a number of subtle quality improvements which at least I
find important. I don't like the idea of spending lots and lots of
money on cameras and lenses just to throw away quality in post.
--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
http://wiki.panotools.org/Hugin_FAQ
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/hugin-ptx

[Yuval Levy]

Post by torger
Unprocessed JPEG from camera highest quality (cropped the top though
http://www.torger.org/temp/img_jpg_unprocessed.jpg

The clouds are grey, as I imagine they are intended to be.

Post by torger
http://www.torger.org/temp/img_from_raw.png
Here's when I have tried to replicate as close as possible the same
http://www.torger.org/temp/img_from_jpg.png

The clouds are blue in both processed images. Is this intended? Or are the
images above just one layer that you use to produce the final image?

Post by torger
My intention of the creative composition was to enhance the sunlight
and make it as saturated as experienced at sight, and increase
generally the contrast in the clouds.

So the next step would be to mask out the other parts of the image and use
another process for them?

Thank you for sharing so much interesting information about your workflow.

Yuv

[torger]

The clouds are blue in both processed images.  Is this intended?  Or are the
images above just one layer that you use to produce the final image?

Well, I intentionally wen't over the top with the image to stress the
jpeg a little bit more, so I have put in both more saturation and
contrast than I would do normally. The clouds are very pale blue in
the raw file so the blue color comes just from heavily increased
saturation, so yes it is intended. In a saner version I would still do
the same things, but not pull the sliders so far... :-)

Post by torger
My intention of the creative composition was to enhance the sunlight
and make it as saturated as experienced at sight, and increase
generally the contrast in the clouds.

So the next step would be to mask out the other parts of the image and use
another process for them?
Thank you for sharing so much interesting information about your workflow.

I already did that kind of process here. I used rawtherapee, and it
does not (yet) support layers/versions so it is a bit cumbersome, but
I did four renditions, one for the foreground, one for the water, one
for the sunlight and one for the clouds with different settings
(differences in curves, saturation, exposure, and detail settings).
The foreground has moderately increased saturation, sunlight a lot,
and clouds somewhere inbetween. Clouds has a lot increased contrast,
while foreground is not so much so etc. I used more aggressive
sharpening in the foreground than on the clouds. Then I loaded them as
layers and masked them together in Gimp.

Normally this image would probably not need this multistep workflow,
why I need to split in sections is because of the extreme settings,
I'm for example using an insane amount of local contrast on the clouds
which would break everything else in the picture. However, even for
"simple" pictures, when I want to make a "print quality" version for I
often re-process then and give them this kind of treatment to do more
subtle improvements, afterall I think postprocessing is kind of fun
too. In landscapes scenes there are typically 2 - 4 sections that I
treat with separate parameters and then blend together. I also do
dodge-and-burn this way (like to have layer masks for everything, has
a non-destructive feel to it). So for a hugin stitched panorama, this
treatment takes place after stitching is complete - thus important to
have it in 16 bit tiff so continued processing maintains quality.

[Carlos Eduardo G. Carvalho (Cartola)]

Hi, have you already seen this kind of workflow?

http://photoblog.edu-perez.com/2009/02/hdr-and-linux.html

I guess I have already posted it here, but anyway...

I don't think it is good for every situation, but have already used some
times with good results. Note: I did it without RAW, working directly with
JPGs.

[ ]s,

Carlos E G Carvalho (Cartola)
http://cartola.org/360

Post by torger

Post by Yuval Levy
The clouds are blue in both processed images. Is this intended? Or are

the

Post by Yuval Levy
images above just one layer that you use to produce the final image?

Well, I intentionally wen't over the top with the image to stress the
jpeg a little bit more, so I have put in both more saturation and
contrast than I would do normally. The clouds are very pale blue in
the raw file so the blue color comes just from heavily increased
saturation, so yes it is intended. In a saner version I would still do
the same things, but not pull the sliders so far... :-)

Post by Yuval Levy

Post by torger
My intention of the creative composition was to enhance the sunlight
and make it as saturated as experienced at sight, and increase
generally the contrast in the clouds.

So the next step would be to mask out the other parts of the image and

use

Post by Yuval Levy
another process for them?
Thank you for sharing so much interesting information about your

workflow.
I already did that kind of process here. I used rawtherapee, and it
does not (yet) support layers/versions so it is a bit cumbersome, but
I did four renditions, one for the foreground, one for the water, one
for the sunlight and one for the clouds with different settings
(differences in curves, saturation, exposure, and detail settings).
The foreground has moderately increased saturation, sunlight a lot,
and clouds somewhere inbetween. Clouds has a lot increased contrast,
while foreground is not so much so etc. I used more aggressive
sharpening in the foreground than on the clouds. Then I loaded them as
layers and masked them together in Gimp.
Normally this image would probably not need this multistep workflow,
why I need to split in sections is because of the extreme settings,
I'm for example using an insane amount of local contrast on the clouds
which would break everything else in the picture. However, even for
"simple" pictures, when I want to make a "print quality" version for I
often re-process then and give them this kind of treatment to do more
subtle improvements, afterall I think postprocessing is kind of fun
too. In landscapes scenes there are typically 2 - 4 sections that I
treat with separate parameters and then blend together. I also do
dodge-and-burn this way (like to have layer masks for everything, has
a non-destructive feel to it). So for a hugin stitched panorama, this
treatment takes place after stitching is complete - thus important to
have it in 16 bit tiff so continued processing maintains quality.
--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
http://wiki.panotools.org/Hugin_FAQ
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/hugin-ptx

[torger]

Yes I have visited that web page before, when I was searching for HDR
workflows in Linux :-).

Which workflows that work depends a bit on what one's goal is. To me,
it is important that there are no visible artifacts even at close
inspection, ghosting, seams, etc, and I most often strive for a
natural look. So when I do HDR it is rarely to achieve a cool "HDR
look", but to increase the dynamic range in problematic light, so it
is often only about merging 2-3 exposures where the brightly lit parts
is from the shorter exposures, and I blend in that manually. I usually
keep some light overexposure on the brighter parts since it often
looks more natural (provides some glow to it). For this type of goal
the automatic tools can rarely produce as good results. However, if
one want to achieve a cool HDR look with exaggerated texture and
cartoon-like tone mapping real HDR tools are required. In some cases
it may be useful to combine both automatic tools and manual blending.

But one can also have the view that some minor artifacts are ok, and
it is more important with a quick workflow. Often manual blending is
quicker than one may think though. The toughest cases is where it must
be a sharp transition between the various exposures, the seam may then
be more or less a pixel-by-pixel work, but often one can get away with
a few feathered selections and gradients.

If working with free tools, it is kind of good to prefer the more
manual approaches, since I don't see free software being near as good
as say photomatix when it comes to automatic HDR.

On Aug 7, 1:21 pm, "Carlos Eduardo G. Carvalho (Cartola)"

Post by Carlos Eduardo G. Carvalho (Cartola)
Hi, have you already seen this kind of workflow?
http://photoblog.edu-perez.com/2009/02/hdr-and-linux.html
I guess I have already posted it here, but anyway...
I don't think it is good for every situation, but have already used some
times with good results. Note: I did it without RAW, working directly with
JPGs.
[ ]s,
Carlos E G Carvalho (Cartola)http://cartola.org/360

Post by torger

The clouds are blue in both processed images.  Is this intended?  Or are

the

images above just one layer that you use to produce the final image?

Well, I intentionally wen't over the top with the image to stress the
jpeg a little bit more, so I have put in both more saturation and
contrast than I would do normally. The clouds are very pale blue in
the raw file so the blue color comes just from heavily increased
saturation, so yes it is intended. In a saner version I would still do
the same things, but not pull the sliders so far... :-)

Post by torger
My intention of the creative composition was to enhance the sunlight
and make it as saturated as experienced at sight, and increase
generally the contrast in the clouds.

So the next step would be to mask out the other parts of the image and

use

another process for them?
Thank you for sharing so much interesting information about your

workflow.
I already did that kind of process here. I used rawtherapee, and it
does not (yet) support layers/versions so it is a bit cumbersome, but
I did four renditions, one for the foreground, one for the water, one
for the sunlight and one for the clouds with different settings
(differences in curves, saturation, exposure, and detail settings).
The foreground has moderately increased saturation, sunlight a lot,
and clouds somewhere inbetween. Clouds has a lot increased contrast,
while foreground is not so much so etc. I used more aggressive
sharpening in the foreground than on the clouds. Then I loaded them as
layers and masked them together in Gimp.
Normally this image would probably not need this multistep workflow,
why I need to split in sections is because of the extreme settings,
I'm for example using an insane amount of local contrast on the clouds
which would break everything else in the picture. However, even for
"simple" pictures, when I want to make a "print quality" version for I
often re-process then and give them this kind of treatment to do more
subtle improvements, afterall I think postprocessing is kind of fun
too. In landscapes scenes there are typically 2 - 4 sections that I
treat with separate parameters and then blend together. I also do
dodge-and-burn this way (like to have layer masks for everything, has
a non-destructive feel to it). So for a hugin stitched panorama, this
treatment takes place after stitching is complete - thus important to
have it in 16 bit tiff so continued processing maintains quality.
--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
http://wiki.panotools.org/Hugin_FAQ
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/hugin-ptx

[torger]

It is unfortunately a quite large job to put together a good RAW vs
JPG comparison. In the simple cases, there won't be much of a
difference, i e if I strive to get the same look as the camera JPG has
with my RAW file there won't be much of a difference. If there are any
blown highlights, they can be better restored with good raw software,
that's about it. Plus you can get a little bit better on the micro
level, a bit better detail. Correcting chromatic abberation is better
done in the RAW file directly on the native camera RGB channels rather
than on a processed JPG for example. The in-camera JPG is already
sharpened, and you may do better sharpening in the RAW software,
deconvolution-based for example. The micro detail is fine stuff
though, about maximizing the percieved resolution. It's subtle, and it
is up to you if it is important or not.

You may start noticing more dramatic things when you process your
images more heavily, for example making multiple renditions and
merging them ("single file HDR"). The example you mention with pseudo
HDR from one JPG will most likely show better quality if based on a
RAW file. High ISO noise reduction can be better in RAW software than
in in camera - or even if it is not better with the RAW sofware you
can judge based on the image content what type of noise reduction you
need. You could even do localized noise reduction stuff.

Again, I'd say it is more about control, ability to affect how the
camera capture is represented in the print/on screen, than quality.
The best tools for photo post-processing assume a RAW workflow. The 16
bit workflow part (converting raw to 16 bit tiff rather than 8 bit and
process that) is a combined quality and flexibilty aspect. If you are
picky about quality and work with 8 bit, you'll have to decide for the
final exposure shadow pushing color space color correction etc before
going to 8 bit, but if you do 16 bit you can be more flexible and
leave color correction etc to last. Sending an 8 bit file or a 16 bit
file to the printer nearly always does not make any percieved
difference (many printers, even high end, only support 8 bit even),
but that is if you at the print step have a full quality file. If you
have passed your 8 bit file through multiple processing step that
alters tonal range/compression etc it won't be of full quality when
reaching the printer.

If you don't need to postprocess and is satisfied with what the camera
do automatically for you, then fine. If you do see a need to
postprocess then it would not be much of a discussion. You can shoot
combined JPEG+RAW if you want to decide after shooting what to do. I
started that way, but now when I'm quite skilled at RAW processing I
only shoot RAW regardless of project.

As for all of these discussions (one can see parallel discussions in
the audio world, do you need 24 bit/96 kHz in the studio?) you need to
decide for yourself.

On Aug 4, 9:43 pm, "Carlos Eduardo G. Carvalho (Cartola)"

Post by Carlos Eduardo G. Carvalho (Cartola)
I see. I'd like to thank you very very much for the long and clarifying
message. I'm surely going to give it a try again. I'm a unix guy so usually
not afraid of reading, learning and command line things. With your
information I guess I can focus on what can make some difference. I also do
many landscape shoots and sometimes I really think the picture could be
http://wp.me/p1AGa0-5R
It was the end of the day, few light. I had to use a very high ISO value as
I was using a long pole (6m/19.7ft) and the wind didn't let me use longer
shutter times. The machine didn't stop, making it also difficult to make
auto bracketing as it would do one longer shot. The scene has high dynamic
ranges. I had to do that pseudo HDR with enfuse with 3 images from the
original JPG to simulate different expositions. As I said I am only shooting
in JPG now, but I really think this could be a very good situation to test
raw processing.
Do you have or know anywhere where I can see samples done with and without
raw? I have already seen some, but none have called my attention very much.
Thanks!

Post by torger
Oh, one more thing. Nowadays cameras get more and more advanced "tone
mapping" settings to deal with how to compress the extra dynamic range
the newer cameras can capture into a JPEG. If you work with RAW, it is
your own artistic decision how you tone map your image.
With a 16 bit workflow you can be more "careless" (=flexible), that is
you can for example use prophoto color space although it is larger
than necessary, and you can have more than one exposure/color
correction step etc. With 8 bit you need to take care to maximize the
use of every bit and be careful not to degrade the quality in follow
on processing.
Anyway, there are several smaller reasons why you would want to shoot
RAW and have 16 bit workflows that together add up to the decision to
go that way, but it is a bit hard to come up with a single short
answer. You have to make your own decision if you need it or not.
Looking at what professionals do, RAW shooting, lightroom and
photoshop (does 16 bit) is kind of industry standard. If you as an
amateur want to use free software and still have the ability to have a
professional workflow, things are today actually looking quite good
with one exception - there's no good free software photoshop
alternative for photographers. If Gimp would be 16 bit it would be,
but it is not. As some have pointed out it is unfortunately not as
trivial as one may think to make Gimp support 16 bit, so it probably
won't happen still for a few years.
But as always, if one really needs it there are commercial
alternatives. The above trick with gimp/imagemagick helps me to do 16
bit workflows in most cases though, so I personally don't need
photoshop just yet... :-)

Post by torger
Getting good results out of a raw developer can be quite difficult, it
takes some practice. The free tools are not the easiest to work with.
Lightroom is probably "the best" concerning user friendliness etc, but
with the newly released RawTherapee 3.0 it is also a very competent
tool that can produce very good results, but it is not like pressing a
button and out comes a perfect picture, one have to do lots of manual
tuning.
Working with RAW takes more time, it can take a lot of more time.
Especially when newbie so it takes longer time to find suitable
parameters.
When using JPEG, the camera itself has done tone-mapping, contrast,
white balance etc decisions for you. Altering them is possible to some
extent, but the larger the changes you do the more of a problem it is
that it is only 8 bit and some info from the raw file has already been
thrown away.
One could say that working with RAW instead of JPEG is more about
creative control than quality.
To create a great landscape picture to make a print to hang on the
wall you may need to optimize clouds separately from the water, and
that separately from the forest or whatever is in the picture. You
develop several layers from the same raw file and merge them together
in an external software (many of the commercial raw developers support
layers in them). Perhaps you work for days on that single image. Doing
such operations on JPEG input does not make sense.
When changes are small, and there is low dynamic range in the picture
etc, 8 bit JPEG may work just fine. But when you start to want to do
changes like described above there is a major risk not shooting RAW
and not having 16 bit workflow, since you may run into trouble further
down the workflow.
Then there are single key features that can have very high value --
superior highlight reconstruction is very valuable to me as a
landscape photographer which often stretch the dynamic range of the
camera. With JPEG the camera has done the highlight reconstruction
already (which uses a safe rather than the best algorithm) and no
further can be made. Pushing shadows is also common in landscape
photography or other conditions when you don't have 100% control of
the lighting, and then it is valuable to have that extra dynamic range
the RAW file provides. The better the dynamic range gets in the
cameras, the more valuable RAW format will be, because it becomes a
larger difference between what JPEG can represent and what the camera
can capture.
The raw developers such as RawTherapee also have nice features
concerning sharpening, color correction, tone mapping etc, although
that can to some extent be performed on JPEGs, it works better on RAW,
so if you want to do that kind of image processing it is natural to
shoot RAW.
If you're happy with what the camera does for you, then it's fine. If
all you do is stitch and do no postprocessing on that, 8 bit JPEG is
fine. Some of us like to have more control though.
On Aug 4, 2:20 pm, "Carlos Eduardo G. Carvalho (Cartola)"

Post by Carlos Eduardo G. Carvalho (Cartola)
Hi Toger and others,
I understand your point of view. I have already tried to shoot raw and

have

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
used RawTherapy and ufraw. After some tries and comparing the final

results

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
with the one using same pictures as JPGs, I decided to stop shooting

raw,

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
because my eyes really didn't see difference and working with raw takes

more

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
time. I usually use only 8 bit JPGs also for HDR, enfuse and

tonemapping

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
jobs.
For example, I have already made a test with one picture. I shoot it in
raw+jpg and manipulated it to make a lower and a higher exposition pic

so I

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
could then make an HDR or a simple enfuse. I really found the result of

the

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
JPGs equal or even better then the one obtained with the raw - maybe I

am

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
clever with the JPGs tools :)
I spite of that, I always feel that I could have failed somehow and

that I

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
am loosing something. If so many people use raw it might be better. Can

you

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
or somebody here give me some references, hints, tips so I can try to

find

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
that thing I lost and maybe be really impressed by the difference of

working

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)
with raw and 16 bit tiff?
Thanks, Cartola.

Post by torger
Actually why Gimp does not have 16 bit is because many/most do think
it is not important. That you don't see any difference between 16 and
8 bit. And sure, if you downsample 16 bit to 8 you typically don't

see

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger
any difference (especially if the downsampling does dithering), and
discussion has usually ended there. However, as we know 16 bit
workflow is about being able to save color correction, color space
reduction, curves, exposure tuning, highlight/shadow tuning etc to
last rather than having to do it first (before stitching in case of
panoramas, which is difficult). Making an 8 bit tiff with prophoto
color space and then start do all that processing on that and you

have

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger
true banding problems.
The wide availability of competent Raw developer software and better
cameras with higher dynamic range is however starting to change
things. More and more people start becoming aware of the merits of 16
bit editing. Today 16 bit editing is a much more wanted feature than
just a few years ago. Hopefully the Gimp team is becoming aware of
that, but it seems to me that they could use a helping hand -- there
are too few developers and too much to do currently...
I also own Bibble but has only so far used the 32 bit version and it
cannot handle more than 30 megapixels or so, not sure what the 64 bit
version can do. I've learnt RawTherapee followed the developer
versions and get very good results out of it (I think it produces
better image quality than Bibble) so for my "fine art" photography it
has become my raw developer of choice. It has no problem of dealing
very large 16 bit tiff files either, as long as it is the 64 bit
version and the computer has enough RAM.

Post by kfj

Post by torger
I sometimes need to blend Hugin panoramas partly manually for

best

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by kfj

Post by torger
results, for example moving water. I like Gimp's layer masks but

find

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by kfj

Post by torger
its 8 bit limitation problem since I want a 16 bit tiff as end

result,

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by kfj

Post by torger
...

Gimp's failure to finally deliver 16 bit output has annoyed me

very

Post by torger

Post by Carlos Eduardo G. Carvalho (Cartola)

Post by torger

Post by kfj
much. Most of your work flow consists of circumventing

...
read more »

[kfj]

... oh, and one more thing.

Post by torger
5. Blend the panorama using Gimp
   - The layer mask should be transferred to the tiff alpha channel
     (default).
6. Make flat versions of Hugin tif output to be used for alpha channel
   application.

Your main aim seems to be correct masking of the individual images.
Since my favourite way of dealing with panorama work is staying
withing hugin if at all possible, I've come to use a lot of masking
inside hugin. The masks are just simple 1-bit ones, but by cleverly
combining include and exclude masks one can sometimes still get the
desired result. One method which I use at times is to proceed in
stages: make partial panoramas, reload those into a new hugin project
and proceeed from there. The mask logic is a bit hard to grasp
initially, and the include masks may 'bite' you if you're not careful,
but once you've got the hang of it there's a lot you can do.

The masking code seems to be evolving steadily, and I have high hopes
that excursions to other software for correct masking will become less
and less necessary. Your workflow also shows that in the end you want
to be back in hugin, presumably because the blending by enblend is
just so good.

Kay

[torger]

Yes I do work with the mask in Hugin too, it is great.

I do not aim specifically at some use case, I just know that some like
to use Gimp for blending panoramas, their reasons may vary. I guess
some just like to have that pixel-per-pixel control.

From my perspective, the main lacking feature in Hugin (or rather

enblend) that causes me to use Gimp at times is that enblend can only
do narrow seams. Narrow seams are preferably whenever possible, but to
make invisible seams in a wavy water it does not work that well. Then
I find it better to make very wide blends, yes you lose sharpness with
wide blends but sharpness in wavy water is to me less important than
invisible seams.

Another special use case is that I've come across lately is that I
sometimes do simple focus stacking, say for a 2x8 50mm lens mosaic I
use f/5.6 focused at long distance to get maximum sharpness on those
(leaving foreground out of focus), and do another sweep with say f/14
at hyperfocal distance to cover close objects where structures are
larger and thus the f/14 diffraction is less of a problem. Stitching
that stuff is not enblend too good at, I usually do one enblend-
stitched layer with the f/5.6 and one with the f/14 and then make the
seams between them manually in the Gimp. You could do it with masking
in Hugin too (masking out all out-of-focus parts), but I currently
find using Gimp as more efficient.

... oh, and one more thing.

Post by torger
5. Blend the panorama using Gimp
   - The layer mask should be transferred to the tiff alpha channel
     (default).
6. Make flat versions of Hugin tif output to be used for alpha channel
   application.

Your main aim seems to be correct masking of the individual images.
Since my favourite way of dealing with panorama work is staying
withing hugin if at all possible, I've come to use a lot of masking
inside hugin. The masks are just simple 1-bit ones, but by cleverly
combining include and exclude masks one can sometimes still get the
desired result. One method which I use at times is to proceed in
stages: make partial panoramas, reload those into a new hugin project
and proceeed from there. The mask logic is a bit hard to grasp
initially, and the include masks may 'bite' you if you're not careful,
but once you've got the hang of it there's a lot you can do.
The masking code seems to be evolving steadily, and I have high hopes
that excursions to other software for correct masking will become less
and less necessary. Your workflow also shows that in the end you want
to be back in hugin, presumably because the blending by enblend is
just so good.
Kay

[kfj]

Post by torger
enblend can only
do narrow seams. Narrow seams are preferably whenever possible, but to
make invisible seams in a wavy water it does not work that well.

are you sure you use a recent version? I find the intelligent seam
placement leaves very little to be disired. But then I've not used it
on very wavy water...

Post by torger
Another special use case is that I've come across lately is that I
sometimes do simple focus stacking, say for a 2x8 50mm lens mosaic I
use f/5.6 focused at long distance to get maximum sharpness on those
(leaving foreground out of focus), and do another sweep with say f/14
at hyperfocal distance to cover close objects where structures are
larger and thus the f/14 diffraction is less of a problem. Stitching
that stuff is not enblend too good at, I usually do one enblend-
stitched layer with the f/5.6 and one with the f/14 and then make the
seams between them manually in the Gimp. You could do it with masking
in Hugin too (masking out all out-of-focus parts), but I currently
find using Gimp as more efficient.

Try and make stacks of two of the photos. Then set hugin to stitch a
panorama made from stacks and set the enfuse parameters for a focus
stack, something like

--exposure-weight=0 --saturation-weight=0 --contrast-weight=1

This way, the focus stacks are fused in the first step, and then the
results from stacking are blended by enblend. This should work just
fine without further ado - just make sure that the images in the
stacks occupy roughly the same positions.

Kay

[torger]

Thanks for the tip. I've used enfuse before but I have not been
satisfied with the results, I may revisit it though. It is probably
more successful with focus stacking than HDR (which is what I have
experimented with before). The way I work with panoramas is that I
either do a quick-and-dirty automatic version where quality is not too
important, or I prepare it for fine art print quality, and then
control and quality is more important than the time it takes to
produce. I do use the automatic tools when they produce better
results. When I do manuals seams it is usually only for a part of the
picture.

Post by kfj

Post by torger
enblend can only
do narrow seams. Narrow seams are preferably whenever possible, but to
make invisible seams in a wavy water it does not work that well.

are you sure you use a recent version? I find the intelligent seam
placement leaves very little to be disired. But then I've not used it
on very wavy water...

Post by torger
Another special use case is that I've come across lately is that I
sometimes do simple focus stacking, say for a 2x8 50mm lens mosaic I
use f/5.6 focused at long distance to get maximum sharpness on those
(leaving foreground out of focus), and do another sweep with say f/14
at hyperfocal distance to cover close objects where structures are
larger and thus the f/14 diffraction is less of a problem. Stitching
that stuff is not enblend too good at, I usually do one enblend-
stitched layer with the f/5.6 and one with the f/14 and then make the
seams between them manually in the Gimp. You could do it with masking
in Hugin too (masking out all out-of-focus parts), but I currently
find using Gimp as more efficient.

Try and make stacks of two of the photos. Then set hugin to stitch a
panorama made from stacks and set the enfuse parameters for a focus
stack, something like
--exposure-weight=0 --saturation-weight=0 --contrast-weight=1
This way, the focus stacks are fused in the first step, and then the
results from stacking are blended by enblend. This should work just
fine without further ado - just make sure that the images in the
stacks occupy roughly the same positions.
Kay

[kfj]

Post by torger
Thanks for the tip. I've used enfuse before but I have not been
satisfied with the results, I may revisit it though. It is probably
more successful with focus stacking than HDR (which is what I have
experimented with before).

It is also evolving. The current bleeding edge may still be encumbered
by the odd bug, but do make sure you have at least a recent stable
version. Enfuse is a complex tool with lots of parameters to tinker
with, and, as I've maintained in a recent thread, tweaking them
pays :)

Enfuse does not actually do HDR images. It does exposure blending,
which is a process of selecting the 'best' bits from a set of images
and blending them smoothly, to produce a synthetic image which only
resembles tonemapped HDR - actually it may well be more pleasant to
look at than the latter. I recommend warmly you to read the enfuse
manual - it's one of hugin's helper programs that comes with a well-
written, comprehensive manual.

Post by torger
The way I work with panoramas is that I
either do a quick-and-dirty automatic version where quality is not too
important, or I prepare it for fine art print quality, and then
control and quality is more important than the time it takes to
produce. I do use the automatic tools when they produce better
results. When I do manuals seams it is usually only for a part of the
picture.

After a fair amount of using enfuse and enblend and with a fair
understanding of what's going on and an intermediate ability at
harmessing it's power, I'd reccomend you

- try spending as much time on tweaking enfuse parameters for one
image as you'd otherwise spend on your manual process. Compare where
that gets you - you may be surprised by the quality you can achieve
with the automatic process which you think quick-and-dirty

- do the experimental tweaking at lower resolution or small sections
to give you quick turnaround (this is where quick-and-dirty applies);
then, when you think you've hit the mark, do a run at higher
resolution.

- keep in mind that nothing keeps you from working on the result of
the automatic process. enfuse handles 16 bit TIFF, for example, so you
have quality material to process further.

- consider to use enfuse's output as additional layer in your manual
process. It may have done a good job in most places and only need a
bit of retouching here and there with bits from the original images.

Kay

[torger]

Your advice sounds really good, thanks. I do have quite good overview
what enfuse and enblend do, haven't followed recent developments
though. I work professionally with software development so I often do
use the bleeding edge stuff and compile myself and have no problem
using software that crashes now and then :-), so I'll probably give it
a try. If I would work professionally with photography I'd probably
only use the commercial tools to save time, but now I really like
using the free software alternatives since you get much more insight
into how the stuff works, and can affect the development more
directly.

Post by kfj

Post by torger
Thanks for the tip. I've used enfuse before but I have not been
satisfied with the results, I may revisit it though. It is probably
more successful with focus stacking than HDR (which is what I have
experimented with before).

It is also evolving. The current bleeding edge may still be encumbered
by the odd bug, but do make sure you have at least a recent stable
version. Enfuse is a complex tool with lots of parameters to tinker
with, and, as I've maintained in a recent thread, tweaking them
pays :)
Enfuse does not actually do HDR images. It does exposure blending,
which is a process of selecting the 'best' bits from a set of images
and blending them smoothly, to produce a synthetic image which only
resembles tonemapped HDR - actually it may well be more pleasant to
look at than the latter. I recommend warmly you to read the enfuse
manual - it's one of hugin's helper programs that comes with a well-
written, comprehensive manual.

Post by torger
The way I work with panoramas is that I
either do a quick-and-dirty automatic version where quality is not too
important, or I prepare it for fine art print quality, and then
control and quality is more important than the time it takes to
produce. I do use the automatic tools when they produce better
results. When I do manuals seams it is usually only for a part of the
picture.

After a fair amount of using enfuse and enblend and with a fair
understanding of what's going on and an intermediate ability at
harmessing it's power, I'd reccomend you
- try spending as much time on tweaking enfuse parameters for one
image as you'd otherwise spend on your manual process. Compare where
that gets you - you may be surprised by the quality you can achieve
with the automatic process which you think quick-and-dirty
- do the experimental tweaking at lower resolution or small sections
to give you quick turnaround (this is where quick-and-dirty applies);
then, when you think you've hit the mark, do a run at higher
resolution.
- keep in mind that nothing keeps you from working on the result of
the automatic process. enfuse handles 16 bit TIFF, for example, so you
have quality material to process further.
- consider to use enfuse's output as additional layer in your manual
process. It may have done a good job in most places and only need a
bit of retouching here and there with bits from the original images.
Kay

[kfj]

Post by torger
...
I work professionally with software development

greeings from an ex-pro :)

Post by torger
so I often do
use the bleeding edge stuff and compile myself and have no problem
using software that crashes now and then :-)

The bug which forced me to switch back from bleeding edge produced
annoying small artifacts in the images. But the stable version did
everything I need, so I haven't even checked if it's maybe been fixed
in the meantime

https://bugs.launchpad.net/enblend/+bug/787387

Post by torger
but now I really like
using the free software alternatives since you get much more insight
into how the stuff works, and can affect the development more
directly.

... and with hugin, you can now even use a SWIG interface to write
scripts and plugins in python that directly use hugin's backend code -
closest thing to touching the code yourself.

Kay

[torger]

I've done some more experiments with enfuse (for stacking), and did
some work with photomatix (for HDR) too, and I must say that to me
personally I find manual blending often more successful. It depends on
the use case of course (I work with high res landscape mosaics). The
thing is that the auto-fusers combine the exposures all over the
place, also in places when it would have been better to use only one
exposure. With manual blending my strive is to use single exposure in
as large areas as possible, and put seams in inconspicous places.

In one test I had a large tree in the foreground, in focus in one
layer, and out of focus in the other. However, the conditions were a
little windy (not much though) so the leaves are not in the exact same
position for the in-focus and out-of-focus layers. In manual blend,
this is no problem. I know that the whole tree should be from the
foreground-focus layer. Sure, some background showing through the
leaves is not as sharp as it would be if picked from the other layer
(if available, could be hidden behind a leaf, since leaves have
moved), but the visual impact of less sharpness there is not big, and
it would not be possible to make a good seam.

The fusers are not either to good at realizing if I have on an area of
the picture an ok sharp layer and a supersharp layer that I only want
the supersharp layer on that area, but instead they still mix in some
from the "ok" picture and effectively lowers the quality of the
supersharp. Landscape focus stacks I often do the way that I have a
whole-scene-in-focus layer (hyperfocal with small aperture), and a
maximum-sharpness-on-distant-small-detail-layer. From my experience
this is the way that work best in practice for landscape photography,
where conditions are rarely perfect (need to work fast, nearly always
a little wind etc), you always have the fallback the ok but less sharp
hyperfocal layer, and can add improvements in important distant
features from the supersharp layer.

In other conditions, other approaches are better. To me, it seems like
I more often encounter situations where manual methods work better
than automatic when it comes to fusing. For other users it may be the
other way around. It is great to have a toolbox with many different
methods to choose from.

Post by kfj

...
 I work professionally with software development

greeings from an ex-pro :)

so I often do
use the bleeding edge stuff and compile myself and have no problem
using software that crashes now and then :-)

The bug which forced me to switch back from bleeding edge produced
annoying small artifacts in the images. But the stable version did
everything I need, so I haven't even checked if it's maybe been fixed
in the meantime
https://bugs.launchpad.net/enblend/+bug/787387

but now I really like
using the free software alternatives since you get much more insight
into how the stuff works, and can affect the development more
directly.

... and with hugin, you can now even use a SWIG interface to write
scripts and plugins in python that directly use hugin's backend code -
closest thing to touching the code yourself.
Kay

[kfj]

Post by torger
In one test I had a large tree in the foreground, in focus in one
layer, and out of focus in the other. However, the conditions were a
little windy (not much though) so the leaves are not in the exact same
position for the in-focus and out-of-focus layers. In manual blend,
this is no problem. I know that the whole tree should be from the
foreground-focus layer. Sure, some background showing through the
leaves is not as sharp as it would be if picked from the other layer
(if available, could be hidden behind a leaf, since leaves have
moved), but the visual impact of less sharpness there is not big, and
it would not be possible to make a good seam.

With this scenario, the usefulness of automatic processes becomes
limited. At least you can use hugin to place all images and create the
foreground and the background layer. But then it's manual masking time
in a program that can edit proper alpha channels rather than using
hugin's simple on/off masks.

I think that if you mask out the bits of the layers which you want
nothing of in your final image (like, the out-of-focus tree) and use
smooth masks, so that there aren't any sharp discontinuities, you
should be able to fuse the masked images with enfuse - if I'm not
mistaken, both enfuse and enblend handle images with alpha channels
just fine.

Post by torger
The fusers are not either to good at realizing if I have on an area of
the picture an ok sharp layer and a supersharp layer that I only want
the supersharp layer on that area, but instead they still mix in some
from the "ok" picture and effectively lowers the quality of the
supersharp.

That is right and it can't be different since the fusion process only
looks at a very small area of the image at a time (like, 5X5 pixels or
so, you can choose). It has no notion of areas. The blending does,
though, and places it's seams intelligently. But you have to leave it
enough room to manoevre.

Kay