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!

[Bruno Postle]

On 18 July 2018 06:36:47 BST, clepsydrae wrote:
>Hi -- I have 30 pics that form a stack of star pictures with which I
>intend to do a median image average with gmic.

>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 would first check that you are optimising enough lens parameters, at least barrel distortion and angle of view (in addition to positions).

Then I would use the Control Points table to examine all the control points with the highest error - if they look like they should be ok, then manually add more control points to nearby features and re-optimise, otherwise delete the points (and re-optimise).

If you still have trouble, upload the photos somewhere and post the link here.

--
Bruno

[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!)

[David W. Jones]

On July 18, 2018 4:48:43 PM HST, clepsydrae <cleps...@gmail.com> wrote:
>
> 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!)

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

Just wondering if B&W would make search for control points easier.

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

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


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

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

[clepsydrae]

 

Hmm. Make copies of images, convert them to B&W (1 bit color), pull into Hugin and cpfind/optimize/etc on those. Save project, replace B&W 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!)

[David W. Jones]

On 07/18/2018 06:22 PM, clepsydrae wrote:
>
> Hmm. Make copies of images, convert them to B&W (1 bit color), pull
> into Hugin and cpfind/optimize/etc on those. Save project, replace
> B&W 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?

Possibly. Others can explain about how cpfind works, but I think it
works on areas rather than specific points. Otherwise, how is it
supposed to determine that Bright Spot A in upper left isn't the same as
Bright Spot B in lower right?

> 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.

Don't know. I haven't worked with starfield images like yours. Perhaps
setting a few manual control points in Hugin would help get the process
started?

> 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.

Well, it does pick control points on edges of things or where edges
intersect, at least on my ordinary photos.

> 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).

That would make sense to me!

> 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.

Something worth mentioning to them. They may know of others using cpfind
in similar situations as yours, people who could give you some ideas.
Somebody has to prepare all those astronomical photos for publication!

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

Don't know. IIRC, you were having it run with the --fullscale option?
Does it do any better without that?

--

[T. Modes]

Am Donnerstag, 19. Juli 2018 04:48:44 UTC+2 schrieb clepsydrae:

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.

Maybe align_image_stack is a better choice which this task.

But align_image_stack does not cope with masks, so would need to clean up the cp after running align_image_stack manually (remove all cp in masks from menu).

[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.

[T. Modes]

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.

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)

Is there a way to make align_image_stack check all pairs?

No, it works only sequential. Also in the case of 63 images it would increase the processing time significantly - now you would need to process 1953 image pairs - sequentially "only" 62.

 

(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?)

The same as align_image_stack, but not on the original images, instead it remaps the image first to selected panorama projection and works there.

[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...

[T. Modes]

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. 

[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

[Jim Watters]

I was trying a similar thing of aligning images of stars. Could not get the feature matching to work with any of the default parameters.

Add images. Set each one as a new lens

Create mask to exclude foreground. Copy and paste to all images. (Wish you could select multiple images to do this)

I but modified Align image stack, then got tons of control points. Used the Edit | Remove control points in masks, to remove the unwanted control points.

-f %v -e --corr=0.4 -v -p %o %i
-e = Assume input images are full frame fisheye
-corr=0.4 = correlation threshold for identifying control points default 0.9

Did not try anything in between. It seamed I got very few bad values.

Choosing many different combination of images to get them all connected.

Optimizing y, p, r, x, y, z, b

Use this as a template.

This was still a lot of work. Before I finished I was told of a better way.

Sequator. Specifically made to stack star images. It can work on RAW images, can incorporate Dark Frame, and cam stack the foreground and stars separately with the freeze option.
https://sites.google.com/site/sequatorglobal/

My final result
http://photocreations.ca/Saints_Rest_Beach/index.html

Jim Watters

--
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+...@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.

[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!