Prioritizing images with greater detail?

[Craig B]

Is it possible to get Hugin to prioritize images with higher detail/sharpness when stitching?

I recently started doing photomicrographic panoramas using a reversed lens setup and a 3-axis stage. Overall, my results are good, I have adequate resolution into the 5μm range. Initially I tried to use CaptureOne to merge my photos to a DNG but I ran into its upper size limit (715mp) and I'm working with Hugin now for the larger ones.

I have learned how to get excellent alignment, clean up bad points, optimize, and output to bigtiff/non-ZFW compression so that I don't exceed the 4gb TIF file limit.

After all that, I finally have an image I can view in Photoshop and while the stitch looks clean, I can tell that Hugin is not prioritizing images with greater sharpness because I must've shifted something during the set and some images are a little out of focus.

I have looked and can't find any option in the GUI to get Hugin to prioritize sharper images. I found some potentially out of date references to setting contrast or entropy weighting, but particularly for entropy, I am not quite sure what it does.

Would one of those or another option achieve the result I want? Or is there a way to have Hugin treat it is a focus stack+panorama so it will prioritize the photo of greatest detail?

Any help would be great! I will also be trying these options myself, but with each run taking around 1hr to complete, it will be slow going (hence taking the time to ask for help!)

[wirz]

Hi Craig,

I'm not entirely sure if I understand the setup of photos you want to
assemble -- do you have a number of focus stacks that you want to blend
such that each stack has a good version of each pixel in at least one
image, or do you have a pano without focus stacks where some images are
slightly out of focus and should be used but only as little as possible?

Hugin itself cannot prioritise images (but there are exclude/include
masks to exclude or force-include regions of one image). However, focus
stacking works via enfuse which prioritises pixels based on content (for
further fine tuning there settings for weights that manage
exposure/saturation/contrast/entropy).

So, in the first case it's simply first fuse, then blend ("Exposure
fused from stacks", with the option of extra settings for enfuse). In
the second case, I think the main question is whether there is any
parallax error between adjacent images: If so, I'd try masks but it wont
be perfect. If there isn't, there is no reason not to fuse partially
overlapping images into a stack and favour high contrast pixels.

cheers, lukas wirz

[Craig B]

Hi Lukas, appreciate the reply!

It sounds like your understanding in the first case matches what I am trying to do.

It was supposed to be a 49 photograph panorama taken completely planar with no focus/depth adjustments.
At some point I must've shifted the holder or the camera and lost the focus which results in some of the source images being out of focus.
As you said, "... a pano without focus stacks where some images are slightly out of focused and should be used but only as little as possible."

The majority looks good, but here is a crop from the panorama I started running this morning (on the way out to work) compared to one of the source images of the same area.
As you can see, this source image is quite a lot sharper than the stitched image. In some cases the soft photo may be necessary to complete the pano, but not here.

One complication I've seen in trying to get it to work, most of the instructions are older pertaining to command line and I am using the GUI.
So for example, when I set options, it says "do not set -w ... arguments as they are set by Hugin." I don't see anywhere I can even change such a setting if it would help and including --wContrast=1 just caused it to throw an error.

I have done focus stacking with Zerene and Photoshop, but the guides I see on doing it with Hugin are also out of date and seem to reference parameters I have no access to (unless they're running a standalone program for that purpose.) Can you help me out with getting the first part of your recommended solution started so I could move onto the "exposure fused from stacks" second part?

Once again, thank you!

[wirz]

Hi Craig,

> It was supposed to be a 49 photograph panorama taken completely planar with
> no focus/depth adjustments.
> At some point I must've shifted the holder or the camera and lost the focus
> which results in some of the source images being out of focus.

> As you said, *"... a pano without focus stacks where some images are
> slightly out of focused and should be used but only as little as possible."*

Got it.

> One complication I've seen in trying to get it to work, most of the
> instructions are older pertaining to command line and I am using the GUI.
> So for example, when I set options, it says "do not set -w ... arguments as
> they are set by Hugin." I don't see anywhere I can even change such a
> setting if it would help and including --wContrast=1 just caused it to
> throw an error.

You can set extra options for the blending and fusing programs,
inclusing enblend and enfuse, in Preferences/Programs. One point of
confusion is, that *currently* -w/-o/--compression refer to the
wrapping-mode, output-file, and compression, while in the old
description that you found there existed --wSomething -- these are not
meant by -w. These fusion options have been renamed and are now
--exposure-weight=w, --saturation-weight=w, etc, with w = [0.0 .. 1.0].
Have a look at enfuse --help. Unfortunately I don't know what weights
would be a good starting point.

> I have done focus stacking with Zerene and Photoshop, but the guides I see
> on doing it with Hugin are also out of date and seem to reference
> parameters I have no access to (unless they're running a standalone program
> for that purpose.)

I think the above should lead a step further. You could also share a
subset of the project, a few photos, at least one bad one, overlapping,
then I'd also give that a try.

cheers, lukas wirz

[Craig B]

Once again I appreciate the help.
I had to step away from this project for a little bit to work on other stuff but I am back.

I looked through the preferences several times but somehow missed the Program tab because it seemed unrelated.
I had also been looking for the GPU prioritization over CPU, but somewhere else I read that the GPU may be slower than CPU still.
I will be giving that a shot, as well as entering parameters for enfuse (when I did it in the fusion options there was no difference. I threw the outputs into Photoshop with a "difference" blending mode and everything was identical.)

As far as you know, does the fusion for most detail and the stitching for panorama have to be completed in two steps?

I've temporarily uploaded a selection of the source files where I saw the issue the most significantly here: https://u.pcloud.link/publink/show?code=kZCRRb5ZeOE3383m2v81I7UxerzaLy9x6ez7
I'll keep trying it myself, but if you end up trying it out with my images and have input based on that, I would be happy to see how your test goes.

Thank you!

[wirz]

Hi Craig,

> I had also been looking for the GPU prioritization over CPU, but somewhere
> else I read that the GPU may be slower than CPU still.

There are two components with GPU support: hugin/nona does GLSL and
enblend does openCl. I haven't done any benchmarking in a while, but I
think the current consensus is that GPU nona is worth it while GPU
enblend is not (although I use it, it's not terrible at least).

> I will be giving that a shot, as well as entering parameters for enfuse
> (when I did it in the fusion options there was no difference. I threw the
> outputs into Photoshop with a "difference" blending mode and everything was
> identical.)
>
> As far as you know, does the fusion for most detail and the stitching for
> panorama have to be completed in two steps?

Yes, conceptually the blending (ie, finding a seam line and glueing
together two components, aimed at not too large overlaps) and fusing
(ie, considering pixels from either image in the whole overlap area,
aimed at almost entirely overlapping images) stages are treated
separately, and enblend / enfuse are two programs that do one each. One
could have a program that takes aligned images and does a blending /
fusing combination but I'm not aware of one, and it wouldn't integrate
as well with hugin.

> I've temporarily uploaded a selection of the source files where I saw the
> issue the most significantly here:
> https://u.pcloud.link/publink/show?code=kZCRRb5ZeOE3383m2v81I7UxerzaLy9x6ez7
> I'll keep trying it myself, but if you end up trying it out with my images
> and have input based on that, I would be happy to see how your test goes.

I looked at your images for a bit. They're very pretty, is that an
anemone? I have two main comments about that:

-- For perfectly aligned images it should be possible to only fuse them
without blending, and I think that may be possible with your images.
However I'm not really getting that to work.
What I previously said about fusing options in Preferences/Programs
partly wrong, that sets only the default for new projects while the
setting for the current project is in the stitcher tab / processing.
One can verify that options have been set by opening the pto file. But
even then I'm not seeing any difference between default /
entropy=contrast=1.0 / entropy=contrast=0.3. I should look into that
some time but not today.

-- Looking at the sharpness of your images I'm not seeing significant
differences, maybe #6 is a bit worse, but the rest look mostly the same
to me. However, all of the images are *much* sharper at the centre than
off-centre, as many lenses are. The images are also overlapping much
more than they need to. So I'd just crop the images heavily and then
run exposure corrected LDR, really nothing fancy. That looks like this:
http://78.46.190.157:8080/anemone_pano.tgz (~520mb) It might be more
elegant to dump all images into a program and get this automatically,
but I think with the current images you wouldn't beat symmetric cropping.

Two useful/interesting things would be fusing such a pano setup, I think
that should work but I must be doing something wrong. And having a
blending program that comes up with a seam lines based on a cost
function for areas. That would also solve your problem here, but
enblend doesn't do that.


cheers, lukas wirz

[Craig B]

Thank you for your time sharing knowledge and giving a run with my photos.
I definitely see what you mean with respect to the edge falloff. The left side is worse than the right it looks like, and some are worse than others, but overall the centers are sharper.
I imagine the alignment could've been off resulting in keystoning and that would explain why it doesn't line up without adjustment. I had to do a lot of refinement of points and allow transformations to get it nearly perfect. I think in my project my max misalignment was around 1.2px and the average was like 0.3px after the transformations and visually the largest control point disparities were as good as I could hope to do it manually.

I am using a reversed 24mm lens on quite a lot of tubes and I thought I would be able to avoid soft edges since it's already sort of cropped into the middle of the lens, but I'm also thinking it might be because of the lens' spherical focal distance against an almost perfectly flat subject. I will print a calibration pattern and use it to verify coplanarity as well as check for sharpness falloff. I'm used to stitching panoramas in other programs like Photoshop which are quite a lot needier in terms of overlap so it's good to hear I can get away with less. I might shoot the next one in APS-C mode before I decide whether I need to try to source a better lens. Also intending to build another level onto my mechanicals to ensure that the camera is fixed compared to the subject.

This subject is a Cistus (hybrid probably) flower. I specialize in ultraviolet-induced visible fluorescence floral photography but I started exploring UVIVF floral microscopy during a project and wanted to continue doing it. The first panorama I did was a Phacelia and it was small enough Capture One handled it. It seems like C1 is pulling sharper parts of images, but I've also been pickier on this one and saw more flaws after I spent so much time on it. I have another one even larger than the Cistus (guessing around 1 gigapixel) that I need to develop but I needed to figure out how to use Hugin adequately and get the Cistus done first as a validation for the workflow.

The learning curve is steep, but I'm seeing how powerful it is. I am impressed with the focus stacking as well. Everyone always touts Zerene and Helicon as the only reasonable options, but Hugin does it rather well. I use Zerene or else I'd probably do Hugin for my stacks. As challenging as it is with the GUI, for everyone who did it/does it with CLI I am really impressed.

For now, I'll try your cropping concept since the result you shared looks generally satisfactory at this point and more consistent than my output.

I'll keep going and if I discover anything new/edifying or if I come to any serious conclusion about the source of my aberrations, I will post back if you're interested in seeing it through.

Thank you!

[wirz]

Hi Craig,

> The left
> side is worse than the right it looks like, and some are worse than others,
> but overall the centers are sharper.

Indeed, the left side is also worse than the right side, I had missed
that. Then the cropping should be asymmetric of course, unless the
images can be improved.

> This subject is a Cistus (hybrid probably) flower. I specialize in
> ultraviolet-induced visible fluorescence floral photography but I started
> exploring UVIVF floral microscopy during a project and wanted to continue
> doing it. The first panorama I did was a Phacelia and it was small enough
> Capture One handled it.

I found your other non-pano Phacelia, very nice!

> The learning curve is steep, but I'm seeing how powerful it is. I am
> impressed with the focus stacking as well. Everyone always touts Zerene and
> Helicon as the only reasonable options, but Hugin does it rather well. I
> use Zerene or else I'd probably do Hugin for my stacks. As challenging as
> it is with the GUI, for everyone who did it/does it with CLI I am really
> impressed.
>
> For now, I'll try your cropping concept since the result you shared looks
> generally satisfactory at this point and more consistent than my output.

In my proof of concept the control points could have been optimised
further, there was still room for improvement.

I gave the strategy of just fusing the images another try because it
really should work. While hugin seems to refuse to put non-overlapping
images into the same stack there is no such problem for enfuse itself.
So, one can generate individual remapped + not-exposure corrected images
from hugin and feed them into enfuse on the command line and get the
intended output (enfuse image1.tif image2.tif -o out.tif). I tried that
with a few different fusing options: entropy and contrast do work but
the differences between 0.0 (off) and 1.0 (max) are only visible in a
difference image. Soft-mask vs hard-mask are noticeably different but
I'm undecided which is better (probably soft-mask which is also the
default). There are plenty more options that I haven't tried, but if
this is an approach that works well otherwise you could spend some time
with that.
Hard-mask vs soft-mask: http://78.46.190.157:8080/cistus_fused.tgz (1040mb).

I don't know if this is a better approach than what I suggested
previously. Pure fusing fares better with blurry regions while blending
does better with minor parallax and aligned issues -- so it depends on
the input images.

> I'll keep going and if I discover anything new/edifying or if I come to any
> serious conclusion about the source of my aberrations, I will post back if
> you're interested in seeing it through.

It is always interesting to hear what finally worked!


cheers, lukas wirz

[Craig B]

So in the end I had issues exporting the files from Hugin with respect to file size limits (1.24GP at 16 bit did not play nicely with TIF format.)
I switched to AutoPano Giga because it has the ability to export a PSB file with all the layers included as aligned. In the end it was quite obvious that several of my source photos were faulty and both Hugin and APG did a decent job blending them as much as possible without seams. In the end I manually finished the panorama with manual blending and color/tone correction on the manually blended areas using the exported panorama as a skeleton.

Between the two I would say that Hugin is more powerful and definitely easier to edit the control points, but APG is more capable when it comes to export formats and generates CPs faster and more accurately, but it is much slower for previewing the aligned panorama. I'll be keeping both because I see each having a valid role and either will perform well when it comes to a panorama shot without as much shifting as I imparted in mine.

[David W. Jones]

Re TIF format and big file sizes...I've found out (thanks to folk on this list) that Hugin supports BigTIFF format. That can handle enormous file sizes, such as 1 terapixel. You might try that.

<http://www.bigtiff.org/>

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

Sent from my Android device with F/LOSS K-9 Mail.

[Craig B]

I read about bigtiff but at least on the GUI there was no way to turn it on and when I tried entering the switch in the output parameters it threw an error and would not output anything at all. I tried 2-3 times and after 30-40 minutes stitching/blending it would throw the error and terminate. Maybe I missed something on how one would enable it?

[David W. Jones]

Hi, Craig!

Someone sent me the BigTIFF executor to generate BigTIFF files. Here it is:

[General]
Description=Normal panorama, BigTIFF
StepCount=2
IntermediateImageType=tif

[Step0]
Description=Remapping images
Type=remap
Arguments=--bigtiff -v -r ldr -m TIFF

[Step1]
Description=Updating metadata
Type=exiftool
Result=%prefix%.tif
Arguments=-overwrite_original -TagsFromFile %image0% -ImageDescription -Make -Model -Artist -WhitePoint -Copyright -GPS:all -DateTimeOriginal -CreateDate -UserComment -ColorSpace -OwnerName -SerialNumber %result%

Copy paste that into a text file called bigtiff.executor. Put that file into the ~/.local/share/hugin folder. Sorry, I only use Linux, so I don't know where it belongs on Windows. MacOS is probably similar to Linux, but I don't know that, either. I suppose other folk on the list know those platforms.

To use it on a particular panorama project, open the project in Hugin. To run the executor from the main Hugin GUI, simply load the executor file using the Output menu option and select the "User defined output..." item.

Note: My Linux set up has BigTIFF support. I don't know what happens on systems without BigTIFF support; I'd guess an error message?

wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.

[tbransco]

The Windows 11 location for the bigtiff.executor file is <Your Hugin install folder>\share\hugin\data\output

Good luck!

Terry

[T. Modes]

tbransco schrieb am Donnerstag, 26. Juni 2025 um 02:21:23 UTC+2:

The Windows 11 location for the bigtiff.executor file is <Your Hugin install folder>\share\hugin\data\output

This is the wrong path. This folder is read only and should only used for the files distributed with the installer.

The user contributed files should go to c:\users\<USERNAME>\AppName\Roaming\hugin  

[Terrence Branscombe]

Thank you for this correction, Thomas.