Re: [hugin-ptx] Something simple I'm doing wrong with 360 pano: sideways/upside images?

[clepsydrae]

Thanks for the response! -- Turns out I was too quick to describe the CPs 
as "sensible" -- I paid closer attention, did some tests, etc, and as you 
say, with the problematic images there were some pairs of images with 
clusters of CPs that were pretty close to each other. I am still surprised 
that it managed to rotate the images, but I can see that better CPs would 
solve things. Indeed, I did a run (after lining the images up roughly) with 
CPfind using "--celeste --prealign" and it worked well.

So, user error, as usual. :-)

Thanks.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/45ee9f93-bb89-406b-b73c-056c3f0d3582n%40googlegroups.com.

[hugin-ptx] Something simple I'm doing wrong with 360 pano: sideways/upside images?

[clepsydrae]

I've successfully stitched panos and aligned stacks and such in the past 
with hugin, but I'm newly on version 2020.0.0.2f576e5d5b4a (Kubuntu 21.10)

I open hugin, add 36 images (taken with canon 10-18 at 10mm, portrait 
orientation, on EOS-100D, exported from Canon software to 16bit TIFF). 
These are just me turning in a circle, nothing too crazy, plus a couple 
extra images higher/lower than the horizon. I set the Lens type to 
equirectangular.

Focal length shows as expected: 10mm, multiplier 1.62.

I find CPs with CPFind+celeste. It finds ~1600 CPs. They look very good, in 
general. Maybe 10 CPs in the clouds (which I removed manually once, but not 
on other attempts) -- generally good, no crazy CPs.

I optimize (tried Positions and View, Positions/View/Barrel, and Everything 
without translation). I go to View->Control Points to check things out and 
roughly half of the images are now turned sideways, upside down, etc. These 
are all images that had sensible CPs in them. They still do, but all the 
CPs are of course sideways now (still in correct positions). There is only 
visual gibberish in the panosphere.

Any tips as to what I'm doing wrong? Everything seems to be working 
perfectly until the optimization. Thanks!

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/0dd2e2a6-5196-4e4c-86c7-6cb9d69e21a7n%40googlegroups.com.

Re: [hugin-ptx] strange issues with 360 pano?

[clepsydrae]

Aha, sounds like that 2010 post was indeed my issue: 
https://wiki.panotools.org/Hugin_FAQ#Why_does_my_output_covers_only_180.C2.B0.3F

"Always read the FAQ!" :-)

Upshot, as I understand it: if optimizing for translation, the pano must be 
less than 180 degrees HFOV.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/9f4cd714-2b2b-4474-a9de-41519a00f2c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] strange issues with 360 pano?

[clepsydrae]

> Certainly doing just the dark images doesn't help.  But I'm probably 
> out of my depth here.  Maybe others can venture an opinion at to what 
> optimization parameters make sense.
>

It seems to find CPs just fine, judging by inspection of points, and given 
that the optimization works great (when translation is not optimized)... 
I've used cpfind to find good points in images much darker than these, too, 
and it seemed fine? (Also, these are 16bit tiffs, so there's possibly more 
room at the bottom of the range to work with, even if the camera doesn't 
really use all those bits.)

Doing some more googling, it seems that I was unwise to use translation 
optimization, as it's for cases where the tripod is really moved (e.g. 
capturing the nadir of a spherical 360 pano or other cases where the tripod 
is e.g. picked up and moved). I thought it was OK for small movements as 
well (e.g. non-calibrated non-pano-head tripod)... must have read that 
wrong somewhere.

This post  
seems to talk about something similar, but it's from 2010 so I'm not sure I 
should pay much attention to it...

Thanks for the scripting/HDR tips. I haven't found an automatic HDR program 
that can match what one can do with manual blending (using luminosity 
masks), but I was planning to try letting hugin make the HDR attempt, and 
assuming it doesn't satisfy, was going to align/pano everything in hugin, 
export each HDR layer separately, and then blend in GIMP. Someday I will 
get around pano stuff on the command line. Now that I'm finally learning 
how to use hugin properly, though, I like it a lot. :-)

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/f1e89e7f-cf45-46cb-baa9-3dc21f432ada%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] strange issues with 360 pano?

[clepsydrae]

Thanks for looking at it!

1.  The images are underexposed by about 5 EV.  The control point 
> detectors just can't cope.
>

Yeah these are actually just the dark frames of a three-exposure bracketed 
HDR stack. Now that I have things sorted (see above) I'll incorporate the 
other exposures as well.

2.  The images show extreme vignetting in the corners.


That's just due to a polarizing filter on the wide-angle lens (which is why 
vignetting correction didn't help). The hope was that it would disappear 
when pano'd, and it seems it has (thankfully).

3.  There was dirt at the top of the images, slightly to left of 
> centre.  It wasn't visible until the images were lightened.
>

Yeah. Gonna fix it in post. :-)

In passing, you probably don't need that many images for a circular 
> panorama (not 360°; that includes a complete sphere).


Thanks for the tip.

Here's what I've gotten to 
 now that I'm not 
optimizing translation. Very happy with the results. Just need to 
understand why translation optimization confused it so much... maybe the CP 
detection on dark images, as you suggested?

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/72bacec6-6ac8-429a-9bcb-c5761a779833%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: strange issues with 360 pano?

[clepsydrae]

Aha -- it seems to be related to optimization of translation... I inspected 
the .pto and saw some extreme-seeming values for TrX, TrY, and TrZ. I 
started over and did not optimize translation and the issue doesn't happen.

I chose to optimize for translation because I was on a crappy tripod 
without any kind of calibration for the image plane vs. the pivot point -- 
was that a bad idea?

Here is the .pto 
 
in case it's interesting (and if you don't want to download the 2GB zip 
file just to see the pto.)

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/142057f9-31c2-4499-89c7-6e1f2a099e0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] strange issues with 360 pano?

[clepsydrae]

On Monday, August 13, 2018 at 4:58:30 PM UTC-7, Groogle wrote:
>
> > Smaller images are fine as long as they show the problem.
>

...if the 2GB file is ridiculous I can try to make a small version of the 
issue... let me know, thanks!

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/f924ba3b-2b6a-48d5-8336-a329e7905e3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] strange issues with 360 pano?

[clepsydrae]

Thanks, Groogle -- when the image is stitched, it stitches the same as it 
does in the preview, with clipped edges, only about half the expected HFOV 
(although the edges aren't jagged as they appear in the preview, but 
straight... ? )

Perhaps this .mp4 will make things a bit more clear 
<http://caseyconnor.org/pub/image/hugin/hugindemo.mp4>.

Some other oddities: I noticed that the CPs between the "invisible" image 
pairs don't show up in the fast preview window, even though they are in 
fact present. See this demo image 
<http://caseyconnor.org/pub/image/hugin/panotestissue5.png>. The CPs on the 
"front" side of the panosphere image plane show up fine.

I have uploaded all the test images and the demo .pto here 
<http://caseyconnor.org/pub/image/hugin/hugintest.zip> -- but be warned 
that it is a 2GB file. It is uploading now and should be done at the latest 
in ~45 minutes (18:30 PDT/UTC-7, 01:30 UTC).

Thanks for any time anyone has for this!

-c

On Monday, August 13, 2018 at 4:58:30 PM UTC-7, Groogle wrote:
>
> On Monday, 13 August 2018 at 15:31:59 -0700, clepsydrae wrote: 
> > Howdy -- I'm attempting a pano made of 14 images (~10mm on a 1.62x 
> APS-C). 
> > CPFind doesn't find CPs well unless I drag the images to a rough correct 
> > overlap, so I do that first. 
> > 
> > Then CPFind finds the CPs, I remove some CPs from the clouds, and 
> > optimization (Pos/Trans/View/Barrel) does a good job. (~average error of 
> 10 
> > pixels.) 
> > 
> > Now the panosphere looks perfect, but the preview pane exhibits some 
> kind 
> > of odd clipping. ... 
>
> I've frequently seen that the preview shows problems that don't exist 
> in the final stitched image.  Have you tried stitching?  Unfortunately 
> I find the panosphere pretty useless, and the views you show are hard 
> to interpret. 
>
> If the image doesn't stitch well, can you put the source images and 
> project file somewhere where people can look at them?  Smaller images 
> are fine as long as they show the problem. 
>
> Greg 
> -- 
> Sent from my desktop computer. 
> Finger groo...@gmail.com  for PGP public key. 
> See complete headers for address and phone numbers. 
> This message is digitally signed.  If your Microsoft mail program 
> reports problems, please read http://lemis.com/broken-MUA 
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/61dd42cc-8d0b-4f33-8333-3a8591236047%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] strange issues with 360 pano?

[clepsydrae]

Howdy -- I'm attempting a pano made of 14 images (~10mm on a 1.62x APS-C). 
CPFind doesn't find CPs well unless I drag the images to a rough correct 
overlap, so I do that first.

Then CPFind finds the CPs, I remove some CPs from the clouds, and 
optimization (Pos/Trans/View/Barrel) does a good job. (~average error of 10 
pixels.)

Now the panosphere looks perfect, but the preview pane exhibits some kind 
of odd clipping. In this demo image you can see 
 that the 
panosphere wraps around perfectly with properly aligned images, but the 
preview window is cut off (approx 180 degree HFOV). This is also how the 
image exports when stitched.

If I try to drag individual images around the panosphere, "strange" things 
happen. Sometimes the images become gradually clipped as they move 
 in the 
panosphere, but appear normal in the preview pane. Sometimes the opposite 
happens: images look fine in the panosphere, but clip in the preview pane 
.

What am I missing?

Here are the optimized parameters 
.

...doesn't look too crazy, right?

Thanks for any ideas!

-

Operating System: Linux 4.13.0-46-generic x86_64
Architecture: 64 bit
Free memory: 4812004 kiB

Hugin
Version: 2018.1.0.aac6fbdf0772
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/casey/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Libraries
wxWidgets: wxWidgets 3.0.3
wxWidgets Library (wxGTK port)
Version 3.0.3 (Unicode: wchar_t, debug level: 1),
Runtime version of toolkit used is 2.24.
Compile-time GTK+ version is 2.24.31.

libpano13: 2.9.19 
Boost: 1.62.0
Exiv2: 0.25
SQLite3: 3.19.3
Vigra: 1.11.0
LittleCMS2: 2.7

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/a33dc88a-d7bd-41aa-ae98-075cf1f230e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] aligning star pics with hugin... recommended cpfind params?

[clepsydrae]

Thanks for that Sequator tip -- good to know about it and I'll try it next 
time. I'm pretty happy with my Hugin flow at this point, but it is a bit 
slow and tedious, so if Sequator is purpose-built for the task, that bodes 
well!


-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/c2df1baa-7cf4-4599-a49b-2f1ce24a6771%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] aligning star pics with hugin... recommended cpfind params?

[clepsydrae]

Thanks as always for the excellent help -- I got the images to align by 
doing as you said: paying more attention to the CPs. align_image_stack was 
finding bad matches, but I was getting fooled when I was checking the 
points. Closer inspection revealed that they were bad. I ended up having to 
make manual points for the 1-63 pair, as well as a few internal pairs 
(1-21, 21-42, 42-63). I then optimized the 1-21-42-63 set (with 
Positions/Barrel/View, as Bruno suggested), then I did a custom 
optimization with 1-21-42-63 fixed, and the result wasn't perfect, but it 
was close enough to get the job done.

It's good to know about the ability to optimize/align subsets of images, 
thanks for that!

-c

On Tuesday, July 24, 2018 at 9:56:43 AM UTC-7, T. Modes wrote:
>
>
>
> Am Montag, 23. Juli 2018 22:31:25 UTC+2 schrieb clepsydrae:
>>
>> Maybe it is sufficient to connect all images sequentially and then run 
>> align_image_stack only on the first and last image to connect them.
>>>
>>> (align_image_stack can only cope with a limited amount of movement. It 
>>> this is too big between first and last image you can do it e.g. to link 
>>> only every tenth image - connect images 0, 10, 20, 30, 40, 50 and 60)
>>>
>>
>> Thanks -- I tried that (1-63 as well as connecting 1-7, 7-14, 14-21, etc, 
>> plus 2-62) -- it might have helped a little bit, but didn't really make a 
>> difference. The statistical pull of each immediate image connection seems 
>> too strong.
>>
> Have you checked the cp between the first and the last image? Are the ok? 
> Or have the many stars fouled align_image_stack and it has selected a 
> neighbor star? How big is the error between the first and the last? 
> Maybe optimize first only the first and the last image. Then leave them 
> fixed and optimize the other images.
>
>
>> (I used the Fast Preview window to add these control points -- I assume 
>> that was your meaning.)
>>
> No, I meant to select only a subset of the images in the images tab and 
> run then align_image_stack on the subset. 
>
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/44232960-d797-46e5-b348-09dbcbc8b43d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] aligning star pics with hugin... recommended cpfind params?

[clepsydrae]

> Am Sonntag, 22. Juli 2018 23:35:30 UTC+2 schrieb clepsydrae:
>>
>> Thanks T. Modes -- align_image_stack does a great job of finding points 
>> but it appears that align_image_stack only matches pair-wise between 
>> sequential images, 1-2, 2-3, 3-4, 4-5, etc... Those image pairs are aligned 
>> very well, but I have 63 images in this stack so the error compounds too 
>> much from the first to the last, so it doesn't work overall.
>>
> Either they are aligned or not. So I don't know what you mean.
>

It's probably me who is confused, but: this is a stack of star field 
images, mostly overlapping. 1-2 aligns fine, 2-3 aligns fine, etc. 
Presumably there is a small error between each alignment though, so when I 
compare the alignment of 1-63 it has drifted, making the stack not useful 
for doing gmic median_image.

Maybe it is sufficient to connect all images sequentially and then run 
> align_image_stack only on the first and last image to connect them.
> (align_image_stack can only cope with a limited amount of movement. It 
> this is too big between first and last image you can do it e.g. to link 
> only every tenth image - connect images 0, 10, 20, 30, 40, 50 and 60)
>

Thanks -- I tried that (1-63 as well as connecting 1-7, 7-14, 14-21, etc, 
plus 2-62) -- it might have helped a little bit, but didn't really make a 
difference. The statistical pull of each immediate image connection seems 
too strong.

(I used the Fast Preview window to add these control points -- I assume 
that was your meaning.)

Do you think there is any way I can preprocess these underexposed images to 
be more usable with cpfind (so I can use them as proxy images for 
alignment)? As mentioned above, simple brightening did not work, and it 
doesn't seem likely that constrast enhancement will help since the stars 
are already pretty bright compared to the sky...

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/6c513453-e565-4f56-ab5c-89d24a62a80a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] aligning star pics with hugin... recommended cpfind params?

[clepsydrae]

Thanks T. Modes -- align_image_stack does a great job of finding points but 
it appears that align_image_stack only matches pair-wise between sequential 
images, 1-2, 2-3, 3-4, 4-5, etc... Those image pairs are aligned very well, 
but I have 63 images in this stack so the error compounds too much from the 
first to the last, so it doesn't work overall.

Is there a way to make align_image_stack check all pairs?

(Also -- what algorithm is used by the fast preview window when you create 
points in a rectangle with "create control points here"? Is it controlled 
by prefs -> Control Points Editor options?)

GnomeNomad -- thanks, I tried with and without --fullscale.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/746f12dc-8f0d-4c88-928b-c04d81132c28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] aligning star pics with hugin... recommended cpfind params?

[clepsydrae]

 

> Hmm. Make copies of images, convert them to B (1 bit color), pull into 
> Hugin and cpfind/optimize/etc on those. Save project, replace B versions 
> with color, stitch?
>

Thanks David -- I did try two versions of that method: one where I did a 
curves adjustment that brought out the stars and crushed everything else to 
black, and one that just boosted everything (including the noise floor). 
Neither worked (cpfind found no points at all, which was even worse than 
before). I tried true 1bit as you suggest and hugin said it didn't support 
1bit and suggested greyscale, so I converted the 1bit images to 8bit 
greyscale. None of the cpfind methods I tried with that found any CPs.

Also, I don't recall if you mentioned this earlier. Do you do noise 
> reduction on your images before pulling them into Hugin?
>

No -- since the reason for the stack is that I intend to do a gmic 
median_image for the purpose of noise reduction I didn't want to do any 
per-image NR. Would it help for CP-creation? My experiment described just 
above seemed to imply it would not (since the first curve adjustment 
effectively removed a lot of noise.) I.e. it seems like the only way cpfind 
is finding anything at all is by matching subtle variations in the darker 
areas.

How would -starfield mode define what a "star" is? A threshold of 
> brightness, size, what?
>

I confess cluelessness, but it seems like cpfind is not designed to look 
for little bright points in a dark field. but rather to match more textural 
image areas. Even on the stack that worked, half of the control points it 
found were in the ~black areas (though I assume it was still using the 
nearby stars to locate the CP) and there were plenty of CPs that were 
obviously wrong, where "obviously" is defined as a human looking at stars. 
:-) Meaning the CP is clearly not just using bright, contrasty points to 
make decisions. (Which makes sense, since it's not an astronomical imaging 
tool.)

It seems like a "dumb" version of cpfind could be told to just find stars, 
defined as less than X pixels in diameter and with a certain degree of 
contrast to the background (or even just a brightness threshold as you 
describe).

I'm sure the author(s) of cpfind don't want to create a special algorithm 
for every type of image in the world, but it seems like star field 
alignment is common enough application that it might make sense. And since 
it seems so hard to make cpfind do it (see above thread), and since it 
seems like it "should" be among the most simple kinds of alignment to do, 
that maybe it's a good suggestion? Or maybe it just belongs in a different 
CP tool altogether.

(Or maybe someone knows some magic I can pass to cpfind on the command line 
to make it work!)

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/f33f3129-bfb0-4fe2-b2f0-b44b3567a98e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] aligning star pics with hugin... recommended cpfind params?

[clepsydrae]

> >The first and last image (representing the largest spatial shift from the 
> >stars rotating in the sky) are still off by 5 or 10 pixels. 
>
> I would first check that you are optimising enough lens parameters, at 
> least barrel distortion and angle of view (in addition to positions).
>

Brilliant Bruno, that was exactly it: including barrel distortion solved 
it. (Optimizing for View as well made it a little bit worse, which I guess 
makes sense because the camera was on a tripod... ?) I still needed to use 
my custom cpfind options as described above, but the alignment and 
subsequent median_image worked great.

Excited, I turned to a second stack of star pictures, but for some reason I 
can't figure a way to make cpfind find good control points on them.

They are also underexposed, but very similar to the first stack, and there 
are still plenty of medium-white stars, and in fact there is less low-level 
noise in these images than the previous stack. I understand that these 
dark, almost featureless photos are not the typical use case for cpfind, 
but maybe there is something I can do to make this work?

In case anyone has a sec to take a look, here is a demo project with just 
two of the images and an exclusion mask over the foreground elements:

http://caseyconnor.org/pub/image/hugin_demo.zip

I think you'll find that the default CPfind settings will find no points. 
With my custom cpfind options it generates 4 points, but two of them are 
obviously wrong. I've been tweaking the cpfind options and with this:

--fullscale --sieve1width 10 --sieve1height 10 --sieve1size 100 
--sieve2width 5 --sieve2height 5 --sieve2size 5 --kdtreesteps 100 
--ransaciter 100 --ransacmode rpy -o %o %s

...I can generate 8 points, 2 of which are bad. That's pretty good, but 
when I try it with all the images (there are 63 in this stack) it just 
doesn't find enough points. Very many pairs of images have no points at all 
and the final alignment is poor.

Anything I can do to get better feature matches?

I tried to pre-process the images to be brighter, find the CP's, with the 
idea of then swapping the original images back in before stitching. When I 
did that I couldn't find any CP's at all, which surprised me.

Any thoughts on what to do? Thanks!
-c

(P.S. it'd be great if there was a --starfield mode that just looked for 
bright points to align!)

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/f45a41eb-0d59-45c6-97c1-d2cb1e87650c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] aligning star pics with hugin... recommended cpfind params?

[clepsydrae]

Hi -- I have 30 pics that form a stack of star pictures with which I intend 
to do a median image average with gmic. They are a bit unerexposed. I'm 
trying to use hugin to align them.

I mask out the ground and horizon, etc, and have hugin align just the star 
field. The default cpfind doesn't do a great job, so I've created my own CP 
detection params:

--fullscale --sieve1width 15 --sieve1height 15 --sieve1size 100 
--kdtreesteps 500 --ransaciter 2000 --ransacmode rpy -o %o %s

...this has improved things a lot, and the remapped images are very close, 
but it's still not close enough to do the median image calculation. The 
first and last image (representing the largest spatial shift from the stars 
rotating in the sky) are still off by 5 or 10 pixels.

I don't really understand the parameters I'm playing with (except maybe the 
sieve* params) so I'm just ignorantly shooting in the dark. Any tips on how 
to make this better?

Thanks for any ideas!

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/75a78204-e9d0-4d53-90cf-1630a84839b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: FR: a few improvements to masks

[clepsydrae]

Thank you for the reply, T. Modes -- that's a great feature to know about.

I'm not experienced in it's use, so I apologize if I'm missing something, 
but "Edit CP" seems to have a few problems for my use-case:

- (this is the biggest issue:) I can select a rectangle, but it applies in 
the same position to all the images; the value of masks is that if a tree 
branch blows into a chosen area, I can mask it out on an image. For a 
complex set of images, with branches blowing around and so forth, I need to 
mask each image a little differently, and this is where having a real "only 
consider making points here" mask would be much easier to work with 
compared to the exclusion masks (or the Edit CP approach)
- similarly, when the images move a lot relative to each other the 
rectangle isn't always overlapping the same region in each image
- I can only draw rectangles, which makes it a little difficult to work 
with strangely shaped areas (which is easy to do with masks)
- the fast preview window is pretty low-resolution (compared to the mask 
editing window) so it's hard to draw an accurate rectangle (it's hard to 
see references like thin tree branches that disappear in the low-res 
preview version of the image.)

To be more clear, the use-case is this: a picture of waterfall behind many 
trees. There is a steady, relatively unmoving part of the image: that of 
the rocks on either side of the waterfall. But there is the moving water, 
and the many trees that are blowing around. I go through all the images and 
mask everything out except the steady rocks. This works great, it just 
takes a really long time to do for 20 images, with lots of tree branches in 
various positions, etc. I have to make 6-8 masks per image and adjust many 
of them to fit each individual image. Then I have to individually remove 
every single mask when done making the CPs.

Here's an example image: http://caseyconnor.org/pub/image/scall-take2.jpg

You can see how most of that image consists of moving, dynamic stuff that 
has to be masked out differently in each frame, while there is still a 
solid, unmoving part of the image which is also in different parts of each 
frame depending on the branches, etc.

I understand if this is not a high priority, and maybe it's difficult to 
code the "only make CPs here" mask; maybe not many people use Hugin for 
alignment. But such a mask would be really handy in these situations!

It would really help to have a "remove all masks" button, though. :-)

Thanks for the consideration,
-c

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/502903ae-8f6d-401a-9140-dfa02968c969%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] FR: a few improvements to masks

[clepsydrae]

[Where is the best/least annoying place to post feature requests for Hugin?]

I use hugin to align stacks of images before I run a gmic image averaging 
(median function) on them. It works great, but my images sometimes have 
many moving components in the foreground (tree branches and so forth, 
blowing in the wind) and I want to align the images based on just a few 
small parts of the image backgrounds, so I need to constrain where control 
points are generated.

I can use masks to get this done, but there are a few GUI issues that make 
it pretty slow, so I wanted to suggest a few (hopefully simple?) changes:

1) a new mask type specifically for CP constraining. I can use "Exclude 
region" and "exclude region from all images of this lens" to prevent CPs 
from being generated, and it works great, but I can't do the opposite. 
Ideally this new mask would be something like "constrain CPs to this 
region"; multiple such regions would allow CPs in all of them, and 
everything outside of them would not get CPs. (If "permit" and "exclude" 
overlap, one could be chosen to override.)

Without this feature, the result is that I often have to make several 
overlapping masks to effectively block out everything except a few small 
areas. The ability to just circle a few features that I know are stable and 
tell hugin to look for CPs in those regions would be fantastic.

2) a command to remove all masks from all images. Recently I was aligning 
20 images, and had to generate 7 masks for each, which was 140 masks, each 
requiring 2 clicks to remove. (I have to remove all masks before outputting 
the remapped/aligned images.)

3) the ability to select/copy/paste/delete multiple masks at once on a 
given image. This would make the creation of the 140 masks a lot easier to 
manage.

Thanks for considering! And let me know if some of this already exists and 
I'm just unaware.

-c

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/cbc5c995-4108-4f9a-92b7-f46e897a0955%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Stitching very large panorama ("gigapixel" scale)

[clepsydrae]

(I should probably also mention that this is a LDR, stitching as "Exposure 
corrected, low dynamic range", and all the images have identical 0 EV 
adjustments.)

It seems like the stitcher is actually using a different image for the area 
near the seam when the cropping is in use. E.g. here is the area in the 
non-cropped-up stitch:

http://caseyconnor.org/pub/image/no_crop_no_seam.png

...maybe that's expected and understood. Is there anyway to do slicing 
manually?

Thanks!

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/9b3e628a-74f8-48ff-b4b2-75fb393ff53c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Stitching very large panorama ("gigapixel" scale)

[clepsydrae]

Thanks Erik, I'm checking that out...

In the mean time, I tried generating the panorama in two sections using the 
crop controls (e.g. crop values left/right 123, 15000 for the first image, 
and 15000, 27992 for the second image) and then use 'montage' to join them.

The result is that there is a visible seam along the crop line... I was a 
little surprised to see that... maybe there is something I don't understand 
about how the stitching works -- I'd have expected the seam to be clean?

Here's a close crop of part the seam: 
http://caseyconnor.org/pub/image/crop_seam.png

Any way to prevent that?

(That seam is not present when I do a normal stitch of the whole image.)

-c

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/302929bb-9b21-4b8b-9f79-a2cdcfdc59c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Stitching very large panorama ("gigapixel" scale)

[clepsydrae]

I have a very large pano that fails when stitching. (I didn't see anything 
informative on the log console.) It's about 585MP in (desired) size, and 
I'm unable to generate a TIF, JPG, or PNG. I think it's running out of RAM?

Assuming RAM is the cause, is there a way I can use RAM smarter for this 
step? Maybe I should split the nona step from the enblend step?

I don't really care what file format it stitches to, as long as I can do 
16bit (or better).

I suppose I could use the crop controls to generate it in two or more 
pieces. I was hoping there might be an automated method. :-)

I have 16GB RAM. If I stitch a smaller version of the panorama, say 100MP, 
it works fine. I watch RAM usage bounce from around 50% to 90% while it's 
enblending, and then it just fails at some point, which led me to the idea 
that the RAM might be to blame.

Thanks for any ideas!
-c

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/0ec77ef4-4075-43c6-8225-3925fad5d1ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: GMIC images render all-white from hugin?

[clepsydrae]

Oops, correction:

gmic 16bit_input.tif -/ 65535 -o 32bit_float_output.tif

...in the above example "16bit_input.tif" is actually 32bit-float, in the 
range [0,65535]

To convert to 16bit integer:

gmic 32bit_float_range_65535.tif -o 16bit_integer_output.tif,ushort

-c

On Thursday, April 27, 2017 at 11:10:24 PM UTC-7, clepsydrae wrote:
>
> Just a follow-up, in case anyone finds the thread:
>
> gmic 16bit_input.tif -/ 65535 -o 32bit_float_output.tif
>
> ...will change the range to [0,1] and make the image work in GIMP, work 
> better in hugin, etc.
>
> ( -/ 255 for 8bit images, of course. )
>
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/fe45ca66-705c-432c-8fa4-1b026e9588e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: GMIC images render all-white from hugin?

[clepsydrae]

Just a follow-up, in case anyone finds the thread:

gmic 16bit_input.tif -/ 65535 -o 32bit_float_output.tif

...will change the range to [0,1] and make the image work in GIMP, work 
better in hugin, etc.

( -/ 255 for 8bit images, of course. )

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/c98b023d-cbe4-4c7a-86a3-576d9d48e2bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: GMIC images render all-white from hugin?

[clepsydrae]

Thank you for looking at it! -- I'll pass this to the G'MIC developer. -c

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/6c8057ad-805e-491f-b00d-d6271058273e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: GMIC images render all-white from hugin?

[clepsydrae]

Here is a new set: http://caseyconnor.org/pub/image/smallexample2.zip

The output of hugin is "hugin_output.tif".

When creating these examples, it became clear that there are bugs 
everywhere surrounding high-bit-depth tiff's (meaning, not in hugin, but 
every viewer, editor, processor I used...) The only program that seems to 
open everything as expected is Luminance HDR.

Files in the zip:

original.tif -- the original image exported from Canon Digital Photo 
Professional
original2.tif -- a copy of original.tif used for processing
aligned000?.tif - the result of "align_image_stack --gpu -C -a aligned 
original*.tif
aligned_then_gmic.tif -- the result of gmic -median_files aligned\*.tif -o 
aligned_then_gmic.tif
hugin_output.tif -- the result of running a simple rectilinear stitch on 
aligned_then_gmic.tif
aligned_then_gmic.pto -- the pto used to do that
other_example.tif -- another strangely-behaving .tif file in case it's 
useful (hugin can't open this one, maybe? But Luminance HDR can.)

...none of the processed .tif files open properly in GIMP, but some of them 
can be recovered by changing to an integer format. hugin_output.tif can not 
be reecovered (though again, Luminance HDR opens it fine, and so does 
hugin).

Thanks for any time you have to check it out. I'm on the gimp user list 
asking questions about this as well.

-c

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/aa5de28a-e1ef-47f8-9de4-cf684c1678c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] GMIC images render all-white from hugin?

[clepsydrae]

> I just tried to read your output_from_TIF using the image viewer, it 
> reported being unable to read RGB data. That image viewer handles my 
> 16-bit-per-channel TIFF images without problems, so I suspect the viewer 
> doesn't like 32-bit float. Same result trying to read your source TIFFs, 
> too. So I suspect a problem with the viewer, possibly in a library.
>

Yeah... I guess I should take it up with the GIMP crew. G'MIC authors 
mention how odd it is that 32bit float is not well supported in viewers and 
editors, given that the standard is apparently long-established. It just 
seemed odd that I can open the 32bit-float source images in GIMP, hugin can 
open the same source images, but the 32bit float written result from hugin 
doesn't work in GIMP (or anything else I can find except Luminance HDR). 
That made me wonder if Hugin was making a mistake.

I opened it in GIMP 2.8.18 and it reported "Unsupported layout, no RGBA 
> loader". I think that's because GIMP doesn't support 16-bits per 
> channel, let alone 32-bit floating point.
>

Yeah, GIMP 2.9.5 adds 32bit float support (and 64bit float in windows). 
Even so, 32bit float images from G'MIC don't work quite right: I have to 
open the file and then change precision to an integer format to see it 
properly (and IIRC I have to also remove the alpha channel to avoid 
issues.) So, there are bugs still. I brought it up a couple times on the 
GIMP mailing list without success (others could not reproduce) but I'll try 
again.

You might consider using Luminance HDR to convert from 32-bit-floating 
> point to JPG. Here's a link to what I got from Luminance:
>

That's kind, thanks -- I can actually just use G'MIC in 16-bit integer 
mode, so I make something that works. But I appreciate the assist. :-)

Really nice shot, though - I like the feathery water contrasted with the 
> sharp detail of the rock face.


Thanks! -- you should see it when the 57 other images that comprise that 
panorama are included. :-) Those were just two frames at random from the 
overall pano. :-)

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/cff0c893-ec75-4d41-ad80-2d8574d45891%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] GMIC images render all-white from hugin?

[clepsydrae]

Why, yes, they do! I've never used it before, but I just ran it, opened the 
result image ("Open HDR image"), and it shows right up.

Does that point towards a viewing issue, then? Or something being written 
wrong out of hugin?

Thanks!
-c

On Tuesday, April 25, 2017 at 7:53:39 PM UTC-7, GnomeNomad wrote:
>
> Hmm - do your output images work in HDR tools like Luminance HDR?
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/3e51dbbb-f6e9-4abd-8345-e6d47f97d358%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] GMIC images render all-white from hugin?

[clepsydrae]

I'm trying to make a pano from images that I ran through gmic 
-median_files, but the resulting pano is always all white.

Here is an example.pto if anyone has a second to check it -- the .zip is 
about 591 MB -- I can make a smaller one if that would be more useful: 
http://caseyconnor.org/pub/image/huginexample.zip

That uses just two images and stitches them together; the result (in the 
.zip file) is output_from_hugin.tif, which opens as all-white for me.

Gimp 2.9.5 in linux has some trouble opening high-precision images, but I 
can usually work around it. In any case, these results seem truly white: 
they open as white in linux gimp, windows gimp, photoshop (CS2), etc., so I 
don't think it's just a viewing issue?

Is there some file format issue happening? Or have I messed up my .pto 
somehow?

I can see the images fine in the fast preview window -- everything looks 
great. There is no exposure adjustment happening (that I'm aware of). I'm 
doing an "exposure corrected, low dynamic range" pano output. File format 
choice for output doesn't seem to matter. Remapper is nona (with cropping 
enabled, but i don't think it made a difference turning it off?), blender 
is default enblend.

GMIC outputs 32bit float images (examples included in .zip), so I assume 
that's related? If I do similar panos in hugin with 16bit-integer tiffs 
(before any GMIC work) it all works fine.

I tried to read everything applicable and search around -- sorry if this is 
an old question.

Thanks!
-c

---

Kubuntu 16.10
Gimp 2.9.5 pixls.us AppImage commit 224722
GMIC Version 2.0.0 (pre-release #013117)

Operating System: Linux 4.8.0-46-generic x86_64
Architecture: 64 bit
Free memory: 3711400 kiB

Hugin
Version: 2016.3.0.044ebb48818c
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/casey/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Libraries
wxWidgets: wxWidgets 3.0.2
wxWidgets Library (wxGTK port)
Version 3.0.2 (Unicode: wchar_t, debug level: 1),
Runtime version of toolkit used is 2.24.
Compile-time GTK+ version is 2.24.30.

libpano13: 2.9.19
Boost: 1.61.0
Exiv2: 0.25
SQLite3: 3.14.1
Vigra: 1.11.0
LittleCMS2: 2.7


-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/4766cde5-15b1-47c2-a93f-2cadb64c4fc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: My method image alignment (for taking median) isn't working?

[clepsydrae]

Thanks as always -- I promise to read more documentation before posting any 
more questions. :-)

It's working great now. I'm not able to beat align_image_stack's 
performance, but I can match it, and the reason I can't beat it seems to be 
the source images, not my lack of hugin skills. There are a couple objects 
in the foreground and too much parralax shifting with the background, so it 
can't make a fantastic alignment.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/cd7d68ed-e83e-4063-9a1a-e927ffe01f13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: My method image alignment (for taking median) isn't working?

[clepsydrae]

Latest from nightlies PPA fixes the CP placement issue with masks, thanks! 
I'm getting an interesting result now -- bug, or user error?

- enable rotation search in prefs -> CP Editor
- add images
- add exclusion mask on first image for all images by this lens
- CPFind without --multirow
- remove mask
- fine tune all points; results are beautiful; 19 or 20 points between all 
image pairs, large green bars, points look great, positioned well
- optimize: position, translation; resultant error is <2 pixels (images are 
3456x5184)
- on stitch page: rectilinear, calc FOV, calc optimal size, export remapped 
images: no exposure correction, low DR

Result: there is still significant offset between most images.

I discovered that in GIMP I can open a badly-aligned pair, do a simple x/y 
shift (10 or 20 pixels), and the entire image aligns very well, but as they 
are output from hugin they are not aligned. Should I expect them to be?

I noticed that images that were rotated or skewed in processing have more 
transparency around the edges, and don't align well with images with less 
transparency around the edges. So I tried using "fit crop to images", and 
they all get much closer to alignment. But they were still not perfect; and 
there is still some transparency around the edges despite doing the 'fit 
crop'.

So I tried doing "fit crop', and then I further cropped in manually an 
additional 200 pixels on each border to make sure there was no surrounding 
transparency. Result: the images are (close to) perfectly aligned!

So does this reflect some lack of understanding on my part about how the 
stitcher works, or is there a bug?

Thanks!
-c

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/49043309-b31c-4ad9-87d8-82154cf79c62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: My method image alignment (for taking median) isn't working?

[clepsydrae]

Brilliant, thanks for the reply and thanks even more for the fix! I'll 
check out the nightly and/or try building it.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/b9ea3f80-3df3-4124-b1ce-782bf243a9cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: My method image alignment (for taking median) isn't working?

[clepsydrae]

I tried using masks to prevent CP from ending up in the water, but didn't 
have luck.

I tried with a single mask on the first image, set to "exclude region from 
all images of this lens". I also tried several runs with a mask on each 
image, set to each of the the different "exclude" options (exclude region 
from stack, exclude region) -- none of them prevented CPFind from making 
CPs inside the masked-off area.

The Control Point Detectors setting I was using was a custom one I made to 
use CPfind, where the arguments are simply "-o %o %s" (i.e. I just removed 
"--multirow" from the default setting).

Am I still doing something wrong?

Thanks!

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/d55177f9-8b0f-4c00-b6cc-5be33717db9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: My method image alignment (for taking median) isn't working?

[clepsydrae]

> So I'll try changing --multirow to --allimages
>

...er, don't know where I got that. :-) Change to: So I'll try removing 
"--mutlirow" and let it use the default matching strategy.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/c3aae6b0-2331-443a-adaa-358c7d2a1c74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: My method image alignment (for taking median) isn't working?

[clepsydrae]

Thanks for the great tips -- I'll give them a try.

Cpfind has 4 different matching strategies, which influence which image 
> pairs will be checked. These strategies are described in the help file 
> (also online http://wiki.panotools.org/Cpfind#Matching_strategy 
> 
>  
> )
>

Ah, I saw those but thought that the "Type" drop-down in the CP Detector 
dialog was choosing that value for CPfind -- on closer look I see I was 
mistaken. So I'll try changing --multirow to --allimages and see what 
happens (and if it's too slow).

Align_image_stack is using a completely different algorithm. Matching every 
> image pair would result in long running time. So only consecutive image 
> pairs are matched (consecutive in this sense means images with similar 
> exposure. To skip this and use the order as given on the command line add 
> the switch --use-given-order to align_image_stack command line.)
>

Just out of curiosity, since --use-given-order searches pairs like 0 <> 1 
<> 2 <> 3 ... does that cause significant compound error when you have e.g. 
23 images?

Thanks for the other tips as well -- very useful!

-c

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/2030de6a-71f1-4cef-a0da-e1429ef32242%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: My method image alignment (for taking median) isn't working?

[clepsydrae]

Quick correction: CPFind does find CPs between all image pairs (although 
only a few on some pairs despite the images being nearly identical), but 
align_image_stack doesn't find CPs for most pairs. I just ran it and with 
e.g. image #2, it found 134 CPs with #1 and 134 with #3, but no CPs with 
any other image.

Regardless, the results are similar with both CP algorithms.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/476fdae2-b4df-4d9f-953f-ad9bf07b9ea7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] My method image alignment (for taking median) isn't working?

[clepsydrae]

Hi!

I have 23 stacked frames I'm trying to align before taking a median of them 
(identical exposures). My normal process is to use align_image_stack (Linux 
CLI) and then gmic -median_files. Works great.

But this particular set of pictures is of a stream and waterfall: lots of 
moving water with a background of trees and a couple of stationary boulders 
in the foreground.

align_image_stack does an impressive job, considering how hard the frames 
must be to align (they are handheld shots, so there is even some 
perspective shift happening) but it's not close enough to use; the median 
comes out with blurry trees and boulders.

I thought I might do better by aligning them manually in hugin (version 
2016.2.0.be8da0221960 in Kubuntu 16.10, libpano13: 2.9.19), but I'm not 
having success. Here's my process --

- add the images
- i've tried both CPFind and align_image_stack for CPs
- after CPs are made, I make a mask on all 23 images (using copy/paste and 
tweaking) to mask all the moving water areas
- Edit -> remove control points in masks -- this removes the points in the 
moving water areas, since they are almost all bad CPs
- remove all masks (calculating the frame size was hanging forever, so I 
had to do this to prevent the hang)
- i've tried making lots of custom CP's as well (see below)
- for geometric optimization I've tried a variety of combinations, 
including a custom x/y/rotate set, positions/translation/view, positions, 
etc
- photometric is "low dynamic range"
- I scroll through all the CPs and confirm their sanity, deleting any bad 
ones
- in the stitcher i've been using rectilinear (and tried equirectangular as 
well)
- calculate the FOV, size, etc
- output is "no exposure correction, low dynamic range"

align_image_stack makes a lot of CPs that don't seem useful. CPFind seems a 
lot more sensible (at least a lot more like what I would choose myself: 
points spread out across the frame). But neither method works well in the 
end. The result is often that a few pairs of images are aligned with 
amazing precision, but many images are way off (like 50 pixels or more).

When I look in the project, I see that the pairs of images that are 
perfectly aligned have CPs between them, and the images that are poorly 
aligned have few CPs, or more often no CPs at all, between them.

So my first question: is there some way to encourage 
hugin/CPFind/align_image_stack to create CPs between more pairs of images? 
It seems to leave most of the image pairs without CPs -- as if it has some 
built-in limit to how many image pairs it will attempt to align.

I tried making manual CPs from the anchor image to all of the other images. 
This helped a little, but the end result was still not usable. Making 
manual CPs between all 23 images is obviously not workable. :-)

Second question: is there something wrong with my process? It just seems 
odd that I can't beat an automatic run of align_image_stack with all this 
manual attention.

Hugin, by the way, is incredible. :-)

Thanks in advance for any ideas!
-c

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/0a994fad-9497-4b23-aeae-88560d02f948%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.