RAW Support in Hugin

1,358 views
Skip to first unread message

Adam

unread,
Jun 24, 2008, 10:53:25 AM6/24/08
to hugin and other free panoramic software
Is there away to work directly on Canon RAW files with Hugin? I would
love to be able to do all my stitching on the RAW files and keep the
RAW info so I can adjust exposure on the full pano.

What's the best practices for taking RAW files and building great
panoramas from them?

Thanks,
Adam

John McAllister

unread,
Jun 24, 2008, 1:39:42 PM6/24/08
to hugi...@googlegroups.com
Hugin cannot handle RAW files as input.
The best idea, I think, is to synchronise the adjustment that you make to a
set of RAW images and output them as 16 bit TIFFs as source files for Hugin.
That leaves plenty of scope for later adjusments to the final image.


Milan Knížek

unread,
Jun 24, 2008, 4:30:40 PM6/24/08
to hugi...@googlegroups.com
Adam píše v Út 24. 06. 2008 v 07:53 -0700:
Is there away to work directly on Canon RAW files with Hugin?  I would
love to be able to do all my stitching on the RAW files and keep the
RAW info so I can adjust exposure on the full pano.
I am not sure it would be a benefit to include a simple RAW conversion in Hugin (then the camera built-in JPEG might produce better results, since it is optimised for the particular camera/chip by the producer). Converting RAW files to images is a rather complex task with many variables and algorithms available and specialised programs do a better job.

Some RAW converters allow to save the conversion settings for a later re-use (e.g. bibble pro, ufraw on linux), so you can safely remove the temporary TIFFs and keep just the RAW files, conversion ini file, Hugin's pto file and the final panorama image.


What's the best practices for taking RAW files and building great
panoramas from them?
I believe the practise would be the same as for any other image.
Keep low ISO to avoid noise and watch for overexposure in any of RGB channels in the important parts of image. Should the dynamic range of your camera not be enough to record the tonal range you require, try to bracket the exposure +/- few EVs and use HDR+tone-mapping or exposure fusion (both HDR and exp. fusion is part of Hugin's development version) to get the final image.

Regards,

Milan Knizek
knizek (dot) confy (at) volny (dot) cz
http://www.milan-knizek.net - about linux and photography

Gary Summers

unread,
Jun 24, 2008, 5:41:03 PM6/24/08
to hugi...@googlegroups.com
Le Mardi 24 Juin 2008 22:30, Milan Knížek a écrit :
> Some RAW converters allow to save the conversion settings for a later
> re-use (e.g. bibble pro, ufraw on linux), so you can safely remove the
> temporary TIFFs and keep just the RAW files, conversion ini file,
> Hugin's pto file and the final panorama image.

Bibble Lite does keep the parameters tos, in a *.bis file.
It also does a good job at recovering high lights.

GS

Tom Sharpless

unread,
Jun 25, 2008, 12:09:13 PM6/25/08
to hugin and other free panoramic software
Hi Adam,

I rarely shoot panos RAW with my EOS 30D. The extra 4 bits are hard
to exploit, and often don't add all the dynamic range I really need.
Instead I take everything as JPEGs auto-bracketed +/- 2 stops. As
hugin still does not handle bracketed series well, I either stitch
them with PTGui (which does) or merge them to hdr and stitch those
with hugin.

The only case in which I would shoot RAW would be for an evenly lit
scene that needed ultimate color gamut. Though common in still life
and architectural photography, such situations are rare in panography,
in my admittedly limited experience. I would batch convert the RAW
series to 16 bit tiffs with Photoshop's Camera Raw (using TCA
correcton and targeting the ProPhoto colorspace), then stitch away.

It would be nice if the stitchers could do TCA correction, which is
really useful with ultrawide lenses. Although best done on RAW data,
it would help JPEG image quality too.

Regards, Tom

slaterson

unread,
Jun 26, 2008, 12:42:54 PM6/26/08
to hugin and other free panoramic software
this topic is something i have been pondering for several months now
(working with raw files for use in a panorama). i have found it takes
a lot of processing time and can take a ton of reviewing/clicking on
the individual photos in each panorama. after running a few tests
earlier this year i wrote a perl script that does a lot of the photo
processing for me. here are the steps i take, i am sure there is room
for improvement:

1) take the photos (hand held, lots of overlap between photos, manual
mode on the camera - i set exposure for slightly underexposed photos
based on the best lite area of the panorama when possible)
2) transfer files to the computer
3) run my perl script which does the following:
a) using ufraw-batch, analyze each photo to detect 'auto' exposure
and black point (using camera wb settings, or appropriate wb setting)
b) write each photo's 'auto' settings to a text file for review
later if needed, i also write many other settings from ufraw to the
text file
c) calculate statistics (std dev, mean, median, etc...) for the
photos in the group, these go in the text file also
d) process the group of photos for each set of 'auto' exposure and
black-point found in step a above (this is very time consuming and
resource heavy - for instance, if there are just 6 photos in the
group, the script generates 6 sets of 6 photos each for a total of 36
images)
* for the next update of my script, i am going to have it process
only a handful of these exposure settings, the min, max, mean, etc...
when there are 20 or 30 or 57 photos to deal with, it very quickly
becomes unmanageable to process every exposure setting)
4) i run hugin and generate a panorama and blend it with enfuse
(currently i generate a panorama for each exposure and then blend
manually with enfuse, i'll be trying the hdr capabilities of hugin
soon, though)

John McAllister

unread,
Jun 26, 2008, 1:12:04 PM6/26/08
to hugi...@googlegroups.com
Alternatively... use Adobe Bridge.

Dale Beams

unread,
Jun 26, 2008, 8:16:19 PM6/26/08
to hugi...@googlegroups.com
I have very bad exposure with my camera.  In part because of what I'm doing I am sure.  I would love to test your script.  I think I could nice it and then let it run all night on 70+ photos.  I'd like to see if this is a possible solution to under/over exposure in a set of photos.




> Date: Thu, 26 Jun 2008 09:42:54 -0700
> Subject: [hugin-ptx] Re: RAW Support in Hugin
> From: campbell.c...@gmail.com
> To: hugi...@googlegroups.com

slaterson

unread,
Jun 27, 2008, 1:48:07 AM6/27/08
to hugin and other free panoramic software
On Jun 26, 5:16 pm, Dale Beams <drbe...@hotmail.com> wrote:
> I have very bad exposure with my camera.  In part because of what I'm doing I am sure.  I would love to test your script.  I think I could nice it and then let it run all night on 70+ photos.  I'd like to see if this is a possible solution to under/over exposure in a set of photos.

dale,
i just uploaded my script here to the google groups site. the file
name is perl_panorama_to_tiff3. note that there is a line in the
script that will run enfuse on each set of photos for the various
exposures - this line is commented so it won't run. also, i am not a
developer so the script may not be the best quality/optimum methods.
it definitely works, though. just run it in the directory where your
raw files sit, mine come out as cr2 files. happy to hear feedback and
improvements.

23

unread,
Jun 28, 2008, 10:14:13 AM6/28/08
to hugin and other free panoramic software
Processing the RAW files to 16 BIT, stitching then deleting the 16 BIT
files has worked for me fine. I tend to shoot all RAW because I am
doing interior photos where colour needs to be accurate like photos of
people's art.

I archive my PTO file, RAW, XMP files (RAW processing data from
Photoshop) and a small JPEG preview of the stitched image.

If I need more exposure latitude than 16 BIT, I stitch multiple
versions of the photo, one for each bracketed exposure. I can't get
enfuse to output a natural contrast range, although I still try
sometimes, so I blend manually in Photoshop. This way I get to choose
exactly where I want highlights. It takes time but the results are
pretty good. And 16 BIT files can be lightened up a huge amount
without suffering from noise or banding, only limited by your camera
noise. Just make sure you process the TIFF with no clipping (no 0 or
255 RGB values). Even if it looks too dark or light you can fix it
later. 16 BIT is forgiving.

The only problem with 16 BIT is it takes forever. So on an average
scene if you won't be printing huge or press-quality, 8 BIT will do.

One more thing I try to use colour profiles all the way through. (Does
this work in Hugin? I had to write it into the code on Hugin-OS X)
Reply all
Reply to author
Forward
0 new messages