Photometry: time between images; number of comparison stars

Doesn’t work for newbies like me :pensive:

OK, I’ll give it a try, but remember: 5 downloads only :wink:
https://send.firefox.com/download/2d4f759afe732039/#wuTJv9Uqv-g7_BK3u5Iv8A

Download in progress.

Please try again. Does it work now?

Yes :+1:

1 Like

Hello.

I quickly did it (with experimental version of Siril) and that works fine. Should work with 0.9.12.


On this screenshot you can see how I make a selection around betelgeuse to align on one star.
It works.

In fact I’ve redone this after applying an ubanding algorithm. It was even better.
Then, after my aligned and unbanded sequence I’ve exported the resut in order to get a new aligned sequence.
That will be the sequence where I will try photometry.


In this screenshot you can see the light curve I have as a result.
You see that the light decreases.

But now, results are poor because your images have some issues and especially a lot of banding. You also have a huge move between your frames and that leads to an accuracy loss because some stars are too close from the edge at some time.

But, it works.

Thanks for your efforts.
I certainly don’t photometry often enough and my camera is not the best, so thank you for the hint to the ubanding algorithm.
I’m playing with the one star alignment (OSA) a bit now, but honestly I’m not getting nice results yet. The computation also takes much longer than global star alignment (GSA), but I will keep trying.

Again my thoughts about the GSA, maybe I am missing something:
“Translation mode” off works perfectly (huge moves between frames don’t matter!), is fast (!), pretty easy to use (no selections and picking stars for alignment needed) and processes all images during the magnitude measurement of a specific star.
For me this means that Siril knows where in the individual images the stars are that I want to photometry (of course it knows!). But for photometry the image rotation should simply not be applied. Therefore Siril should still be able to identify the stars you want to photometry in the non-rotated image. I think there is still a problem right here (see pictures in the first post).
Of course all roads lead to Rome, but I think the GSA road is quite close to being the most comfortable one. :wink:

So you can do global with translation only. That don’t produce new sequence. But you can export result and work on it.

EDIT: There’s maybe a bug… wrong sign in the translation … At least on the 0.99 version. Need to check with 0.9.12
ping @vinvin

Hmmm in fact this is difficult to say because images have rotation. So global registration with translation only won’t work.

EDIT, again: I can confirm. No bug :D.

Here a better analysis.
The curve is nice :).

You did this analysis with OSA, right? I’ll try it tomorrow.

You see, I’m somewhat obsessed with the GSA method for the reasons mentioned in my last post.
GSA with “Translation only” could be used for photometry. This won’t work, if images have rotation (and images with 35mm lens have rotation). I think I got this.
GSA without “Translation only” computes translation and rotation angles for each image. This is easy and works perfect but is not ok for photometry.
Maybe I’m imagining things too simply: Why not define a layer of measurement circles (V, 1, 2, 3, 4, 5, 6 and perhaps even more) on the reference image and translate and rotate this layer according to the results of GSA (without “Translation Only”) and apply these rotated layers to the non-rotated images? Then, the non-rotated images are used for photometry (which is fine) and the measurement circles should match with the stars we want to measure.

I’m not sure to understand. Sorry.
But OSA is so easy to use. Produce no new images and almost never fails :).

In photometry we want to avoid to apply rotation in order to avoid interpolation that could modify raw signal.

Ok, it’s late in the evening :wink: Will have a look at OSA tomorrow.

My last words before I have to take a nap:
GSA without “Translation only”: layer of measurement circles (V, 1, 2, …) is fixed and the images are rotated in such a way that all stars match >> Works perfect, good for stacking, but bad for photometry, agreed!
My idea: Why not keep the images unrotated, but rotate (and translate) the layer of measurement circles (GSA without “Translation Only” makes all necessary calculations of translation and rotation already now!) >> Good for photometry since all images are not rotated.

That may be a good idea @nunki. For now the rotation parameters are not saved anywhere, they are just used to rotate images, after which we use the new sequence of rotated images. But we have planned to keep the rotation parameters for Bayer drizzle implementation, so maybe we’ll be able to do what you say as well once this is done (not before April).

NIce to see somebody doing photometry!

@lock042 : do you have a problem with your free-astro.org email address?

1 Like

Was not aware about that.

That sounds promising! Looking forward to the next releases :+1:
Maybe the other two things from my first post (more comparison stars and measurements of same stars on R, G, B without picking the same stars again) are also worth thinking about :wink:

One last question:
The magnitude differences of two stars slightly differ depending on the display mode the images are shown (autostretch, histogram,…). It’s not that much (third decimal place in my test), but is there a display mode you recommend for photometry?

Display mode should not change anything.

I thought so too, but it does.
In my series I measured Betelgeuse and gamma Ori and exported the magnitudes as csv, then in libreoffice I calculated the difference between the two values and the mean of all differences of the series.
I did this for “autostretch” and “histogram”. The means of autostretch and histogram differ slightly (the individual magnitudes are not equal either). I did the whole thing for R and G. In G the means differ from the third decimal place on, in R from the fourth.

It is really impossible since pixels used for computation are not the same than those displayed on screen.
So the difference comes from something else.

Nothing is impossible :wink: