Closed smart-underworld closed 1 month ago
Did you get a warning in the logs? This can happen if distorsion correction requires pixels which are outside of your cropping window, typically if the line is not centered.
I did see the error in the log for v2.6.0. However, the same ser ran fine in v2.5.3, with the expected Doppler related images generated.
On Sat, Jul 6, 2024, 3:05 PM Cédric Champeau @.***> wrote:
Did you get a warning in the logs? This can happen if distorsion correction requires pixels which are outside of your cropping window, typically if the line is not centered.
— Reply to this email directly, view it on GitHub https://github.com/melix/astro4j/issues/344#issuecomment-2211985614, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGFJTAW6QB6UNXWFBCRKPXDZLBS37AVCNFSM6AAAAABKOYKTO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJRHE4DKNRRGQ . You are receiving this because you authored the thread.Message ID: @.***>
This is an intentional change, which I actually made following another bug report from you : https://github.com/melix/astro4j/issues/334
Before, this would lead to artifacts. So even if you could generate a Doppler image, it wasn't correct in the sense that some pixels had wrong values.
OK. I will expand the capture window. Thanks for this fun project.
Sure. However I'm puzzled because seeing the image you posted, a pixel shift of 1 should work. There may be a bug in the computation of the limits 🤔
I can share my ser file if needed. I do agree that my capture window should suffice for the doppler calculations.
FWIW, I considered my older bug report a user error. I should have just used the other side of the spectrum to generate the continuum image to avoid the banding issue. Thus prefer to use the older logic to get back the Doppler images with my existing crop window size.
Yes, sharing the file would help, thank you!
ser file can be found here:
https://drive.google.com/drive/folders/1bPu2zbTwpMz3wPl3JlbdscZ21U1SeoAG?usp=sharing
Thanks for the file. I understand what's going on here : basically the issue is that the solar limb detection failed, so the whole width is used, and as such, a positive offset is indeed forbidden. I'll check what I can do.
I just confirmed this, in batch processing 2.6.0 didn't produce the positive offsets, from the enumeration. I gave it 1;2;3;4; etc.
Have you tried the 2.6.1 dev version?
2.6.0 is the latest I tried, with the best results so far from 2.5.0. Installing it as we speak.
Any positive offsets returned the same image as for 0 offset. Therefore, Doppler images of Ha failed. and the following ImageMath script return a totally black image:
[outputs] ha_diff = img(0)-img(1)