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 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?
Was not aware about that.
That sounds promising! Looking forward to the next releases
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
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
Oh, the bug could exist, but not because of it
Pretty sure the difference comes from Siril, to be honest.
I did the calculation yesterday for G, today for R and always got this small deviation. The individual magnitudes (exported via csv) should be also the same for âautostretchâ and âhistogramâ and all other display modes, right? Here, I also get a deviation of the means of these individual magnitudes right from the csv-file.
Here the result of 3 times same computation with different display modes. Of course, values are strictly identical.
EDIT: of course, if you make a selection slightly different between your test that could change the result by a tiny amount.
Well, I used the series you downloaded and used OSA with Betelgeuse. Then picked Betelgeuse and used âPSF for the sequenceâ. The same for gamma Ori. I think thatâs the standard procedure for obtaining lightcurves.
Are there any settings that can be wrong?
Thanks, for your images. You used a B&W image. I have R, G, B layers.
Ok, I did OSA and measurements with âautostretchâ, then started Siril again and switched to âhistogramâ for OSA and measurements. Thatâs where selections could change a bit, right?
You changed the selection?
Here on your betelgeuse images.
Plot with autostretch and in linear mode. Again, no diff.
Plot_as.csv (983 Bytes)
Plot_as.csv (983 Bytes)
I did an selection around the star and used âPick a starâ and then âPSF for the sequenceâ.
Yes, this initial selection probably changes for âautostretchâ and âhistogramâ as I close Siril and open it again. I thought itâs just important, that this selection covers the star Iâm interested in and exact size and position donât matter.
Yes ok, so if selection changes, value changes. But by a little, this is in error stick of course. So donât worry about that.