Use RAW Photos with Hugin ?

[KenO]

Can Hugin use RAW photos?

If not would be glad to be an Alpha or Beta Tester.

Ken

[phar...@gmail.com]

On Mon, Mar 28, 2011 at 5:27 PM, KenO <kenit...@yahoo.com> wrote:

> Can Hugin use RAW photos?
>
> If not would be glad to be an Alpha or Beta Tester.

Why wouldn't you want to process those RAW files into JPG, TIFF or
whatever before loading them into Hugin? Isn't the concept of RAW
supposed to be to allow for the processing of the file by the
photographer in order to achieve the results that are desired? To
perform that function n Hugin would require an entirely additional
operational requirement that could likely be better done by a separate
application that is designed specifically for that purpose. If you
desire automatic processing of RAW files, you might as well just shoot
in JPG or TIFF to begin with, or so it seems to me.

Steve

[Jeffrey Martin]

Agree, RAW input for stitching is a bad idea. At the very least you want to set white balance on your raw images (although it's true hugin can fix white balance, this is not ideal)

Even if Hugin did have raw input, it would simply use dcraw for this most probably. I'm not in favor of adding this as a feature, there are many more important things Hugin needs!

[kfj]

On 28 Mrz., 23:27, KenO <kenithol...@yahoo.com> wrote:
> Can Hugin use RAW photos?

I'd like to shed a slightly different light on the topic. Why does
anyone want to process RAW in hugin? There are different motivations:

- to wrench the last bit of quality from the images that would be lost
in a TIFF: the green channel effectively yields 1.4 times the
resolution, for example. Potentially very useful.

- to save the RAW conversion - the RAWs are there, you want a pano,
you'd like to not have to launch the RAW converter before feeding the
data to hugin

I'd assume the first motivation will be relevant for special purposes,
e.g. calibration or focus stacks. But I don't think it's awfully
relevant in most paographers' every day work - converted RAWs or even
good JPGs will do the trick just fine. So my suspicion is that the
main motivation to use RAW is the second: save the conversion. Maybe
it's enough to just defer the conversion? I don't know about other RAW
formats, but Canon's CR2 contains en embedded 'thumbnail' - this sound
pokey, but in fact it's something like a good 1.5 megapixels in size,
and has well enough detail to run a CPG on it. In fact it's very
crisp, having been scaled down from the original 12 MP my camera
yields. So it's entirely feasible to extract this image, using
something like

ufraw-batch --embedded-image IMG_XXXX.CR2

and make a panorama from the preview images. Don't laugh. The embedded
preview has the same geometry as the RAW image. So you can - later,
and maybe in a batch run overnight, have the RAWs expanded and the pto
file upsacaled to work on the full-size images, and do a stitch from
them. I've written a pto upscaler precisely for the purpose - batching
the other stuff is (relatively) trivial, but a nice batch file would
of course help... The upscaler is here:

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/scale_pto.py

This one isn't hsi/hpi but plain Python. I admit I haven't looked at
the script in a while, but it should work nevertheless. The approach
has a few good points, like saving time and space - a bonus for laptop
users and travellers. Instead of the emberdded preview image, it's of
course just as well to use output from the RAW converter at smaller
scaleand in a compact format - in fact this is even better. Why?

In the proposed workflow I always felt there was one thing missing.
Hugin can very nicely take care of exposure, colour and lens geometry,
but there is one point which can be crucial which is left in the
domain of the RAW processors: tca. Correcting tca with a RAW procesor
changes image goemetry and stands in the way of my 'upscaled
thumbnail' approach. You can use an external tca corrector in your
toolchain on both the thumbnail and the processed RAW, but this
approach has always had less appeal to me since it involves yet
another warp with the accompanying degradation in quality - not to
mention the extra processing time.

Kay

[Oliver H]

Hi

OK this is an old thread but support of RAW images may be fine.

I am using Hugin version 2013.0.0.4692917e7a55 on Ubuntu 14.04.
RAW files does not seem to be supported because I get the following error :

Could not decode image: P6140137.ORF Abort

I have imported this picture generated by Hugin from two JPEG files
https://commons.wikimedia.org/wiki/File:Cale_plouer_hugin_2014.jpg

The defect is the wrong contrast between the left and the right pictures (see the little girl in the middle of the picture).
If Hugin could support RAW images, this defect could be corrected by Hugin.

Cheers
Oliver H

[David W. Jones]

I process RAW files using RawTherapee; gives me much more control over
conversion, noise reduction, etc. Then I save them as 16-bit TIFF, which
gives me the full dynamic range of the original RAW file in a format
that Hugin understands just fine.

> <http://bazaar.launchpad.net/%7Ekfj/+junk/script/view/head:/main/scale_pto.py>

>
>
> This one isn't hsi/hpi but plain Python. I admit I haven't looked at
> the script in a while, but it should work nevertheless. The approach
> has a few good points, like saving time and space - a bonus for laptop
> users and travellers. Instead of the emberdded preview image, it's of
> course just as well to use output from the RAW converter at smaller
> scaleand in a compact format - in fact this is even better. Why?
>
> In the proposed workflow I always felt there was one thing missing.
> Hugin can very nicely take care of exposure, colour and lens geometry,
> but there is one point which can be crucial which is left in the
> domain of the RAW processors: tca. Correcting tca with a RAW procesor
> changes image goemetry and stands in the way of my 'upscaled
> thumbnail' approach. You can use an external tca corrector in your
> toolchain on both the thumbnail and the processed RAW, but this
> approach has always had less appeal to me since it involves yet
> another warp with the accompanying degradation in quality - not to
> mention the extra processing time.
>
> Kay

--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com