It doesn't really make sense to me to feed *completely* unprocessed image files to hugin. I try to do the basic processing first, export to 16-bit TIFF, stitch the files and then edit the resulting TIFF in darktable *again*, for any additional processing. I should mention that I'm usually only stitching ~2-4 images, not complete immersive panoramas.
Things that I do pre-hugin: wb, noise reduction, lens correction (with vignetting!), and sometimes exposure (the amount that equals "expose-to-the-right" for brightest image, if I didn't get it right in the camera). It seems better to at least do the noise reduction before distorting the image. The lens correction means hugin doesn't have to worry as much about those issues (I still use the colorimetric correction, but the changes are generally very small). On the other hand, I never bother to rotate or otherwise alter the image dimensions, since this is better done in hugin, automatically or manually. I will *sometimes* do some amount of shadow recovery pre-hugin, if I suspect that a large amount will be required, since in that case it seems better to do from the RAW. I've never had a problem with this creating bad matches between images as long as the same settings are applied to all, but in theory I suppose this could happen. Generally any other processing happens on the second pass through darktable, particularly sharpening or local contrast enhancement. I'm not claiming that this is *the correct* workflow, but it's what makes sense to me... I'm interested to see what anybody else has to say, thanks for bringing the topic up for discussion. -- junkyardsparkle @ 2014-12-21 Micha Krause <[email protected]>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > When creating panoramas, I first use Darktable to edit the individual > RAWs, export them as jpeg, load the jpegs in hugin, create the panorama. > > This works, but I would prefer it the other way around, first using > hugin on unprocessed files, and then process the final Panorama in DT. > > Hugin can't process raws, so I played around with EXR, TIFF (float) > and TIFF 16 Bit. > > Using EXR, I get black images in Hugin previews, but Hugins EXR output > contains the panorama, sadly working blind in Hugin is not realy an > option for me. > > Using floating TIFF, shows somthing in Hugins Preview which vaguely > resembles the Images. > > Using 16 bit Tiff works. > > My first idea was to disable all processing in DT including WB, but > when I tried to WB the resulting panorama, I got weird blue colors in > white highlights. > > Leaving the WB on, works better, however without further processing > (linear base curve etc.) The images in hugin are often dark, and hard > to work with. > > If I simply use DT default processing, I risk blowing highlights, in > which case 16Bit won't help me (Not sure what would happen with a > float-format in this case). > > To sum it up: it sucks. > > Is anyone using this type of Workflow (hugin first, then DT)? > If you do, could you share what filetypes, processing, etc, are > working for you? > > > Micha Krause > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlSW5asACgkQfAR45tA28LiVIwCff2wuUTa0Jz1aTu+2pDBMYHP2 > PCQAoJBpLYbX6OwFx1xhMdXpYRMPikff > =yUDG > -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Darktable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-users
