My HDR panoramic work flow goes something like this: stitch first bracketed set, save image and .PTO. Open up .PTO file with a text editor and replace the images with the next ones in the set. Load into Hugin, stitch and save image, then edit .PTO again and replace with final set of images for the last stitch (I usually bracket at 0EV, -2EV and +2EV). This results in 3 panoramas which should line up perfectly as the control points and thus warping of all images should be identical. The 3 images are then loaded into Dynamic Photo HDR or Qtpfsgui where they’re aligned (without the need for any intervention) and merged to HDR prior to tone mapping. I always stitch first and tone map second so you can get a global rather than local preview of the tone map output.
The other day I made a mistake when editing the .PTO files and failed to replace a couple of the images. Only after I’d stitched the pano did I realise my mistake. So I decide it was time for a little hack to automate the image replacement process from within Hugin.
I’ve added a few extra buttons to the images panel, ‘Bracket up’ and ‘Bracket down’:
Once you’ve finished your first pano, simply hit the ‘Bracket up’ button. My function will scan the image file name for a number, increment it by one, then search original image’s directory for the new image. If it finds all the images in the next series it will then replace all the current ones and update the list, but will not alter any of the panorama’s other settings. Hit ‘Bracket down’ and it will do exactly the same but look for the previous images in the set. If it succeeds a message will pop up:
Open up the preview window and you should see a darker or lighter pano with all setting intact. Hit stitch, repeat for all bracketed sets and stitch again and you’re ready for HDR.. and no messy editing of .PTO files in sight.
You can download this patch from here. I’ve tested it under Ubuntu and Centos using SVN 3555. For Ubuntu, I had to install libboost-regex and libboost-regex-dev packages; under Centos I had to add some Boost suffixes to the relevant section in FindBoost.cmake (since I’d built Boost from source). Since Boost is a prerequisite for building Hugin (it uses the Thread library), other platforms might not need any modification.
Let me know if this is useful to you, it has definitely shortend my workflow in the last few days.
Ultrawide 
5 Comments
Very neat. It quickly cuts short through one of hugin’s main workflow disadvantages: the lack of a fixed relationship amongst shots in the stack.
A more permanent fix would be one that enables to load all the brackets at once and to “bind” the stacks, making their position, lens and perspective correction parameters constant within the stack.
The one issue I see with this hack is if there is movement in the scene. A moving object may cause the blending seams to be located differently on the EV layers to be merged.
The advantage of merging to HDR in hugin (rather than in the HDR software) is that the blending is truly seamless. And it will become even better once the deghosting code that is currently lingering in http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/deghosting/ is put to good use.
For now this automation hack is our best option – combined with Bruno Postle’s ptomerge.
I’ve downloaded the patch and will try it out. My next workflow is likely to be:
– optimize EV0 and save .PTO
– bracket up and save .PTO
– bracket down and save .PTO
– ptomerge
– stitch the HDR
thanks to your new buttons, it will take much less time to do exposure stacking.
Couldn’t you (using unpatched hugin):
– create your first panorama:
– save it: File -> Save
– start a new project: File -> New
– use a template: File -> Apply Template
– finally pick your saved project and hugin will prompt for the next set of images?
The usefulness of your patch is that you don’t have to remember the filesnames, so there could be a more generic use: Photographers with expensive panoramic heads repeatedly use the same template for different panoramas, not just for bracketed sequences in a single panorama – A button that simply loaded the next n images in a folder, applying the current settings, this would be useful for them too.
Yuv, your ptomerge workflow is an interesting one. I’ll take a look at the deghosting code.. if we could turn that into a panel in Hugin then merging to HDR with Hugin becomes really useful. It would be pretty easy to add a button which adds the next series to the panorama (retaining the initial set), taking the settings from the equivalent image in the previous set, but keeping the panorama settings the same. I should be able to add that fairly easily if you like. But without internal deghosting it would be easier to create the HDR in Qtpfsgui etc. at the moment.
Bruno, my motivation was having to deal with a lot of bracketed sets each with a lot of images. It’s the selection (or replacement when editing the .pto) of the files which is a chore.. It’s the difference between at least 21 clicks (for 7 shots x 3) and maybe the odd mistake vs 3 clicks.
I’ve not really used templates before though, I usually take more of an ‘edit the .pto by hand (or perl)’-type approach. Could have saved a bit of time this way I guess.
кремлевская диета как высчитать у.едиета вареное яйцо курица кефир творог обезжиренный йогурточищение кишечника с помощью овощной диетыкак похудеть с помощью клизмы с сольюяблочно-молочная диетамонтиньяк диета сайтантицеллюлитные программы на савушкина в спбдиетологи в краснодареневесом кто похуделотрыжка диетадиетолог в петербургепосле развода мне удалось похудетьдиетическое меню для беременныхдиеты в моде за здоровьеовощной суп для похудения с сельдереемкак похудеть на 13 кг за месяцсколько времени в день нужно бегать чтоб похудетьпрепараты для снижение аппетита и весагречичная диета и что во время этой диеты можно естьдиета как похудеть на 10 кг за14 дней
One Trackback/Pingback
[…] you should not try to do is something like this patch by 2008 student Tim (likely 2009 mentor). It is very nice, but it was done after a Summer of […]