melix
request: add option to crop with modulo lengths to support effective stacking
For proper stacking of images generated by JSol'ex, one needs to have each frame to have the same dimension. With current version, cropping is only limited to (n)x of diameter, with the final sizes usually are different because the sun diameter may change from one to another. I know one can restrict the final cropped size to be closest to a multiplied value of a constant in ImageMath scripts, but it would be great if this option is also available in the default mode as well.
That makes two of us (at least). I requested this in #390. But I think you stated the request better.
Let's think about how to do this properly. With the current options:
- no crop : all images will have different sizes
- source width : all images will have different sizes
- radius factor : most images should have the same size, but because the detected radius may be different, it can happen that the sizes are different
- fixed width (non existent option) : all images would have the same width, but because the radius may be different, the alignment will not work, or the stacking will not work because the scale of the solar disk will be different
This leaves us with an option to first crop with whatever technique (preferably radius crop) then do modulo lengths. The problem I'm having with this is that ideally, you shouldn't have to determine which modulo to apply. This is what happens if you use JSol'Ex built-in stacking, it determines the sizes automatically and does the right job, but it can only do so because it has the list of images at hand and that the solar disks are known. In this case, we only have a single disk (single file processing). Even in batch mode, you don't know the sizes of the other disks before you have completed processing, so it would require re-cropping after processing the whole batch, which introduces an army of secondary problems, therefore a no-go for me. As such, the only reasonable option I see is specifying the "rounding" modulo manually (e.g 128, 256) and hope that it will work. Not great user XP though.
Agree with your conclusion that a manually entered rounding modulo is the best compromise. Works for me.
On Thu, Aug 15, 2024, 3:08 AM Cédric Champeau @.***> wrote:
Let's think about how to do this properly. With the current options:
- no crop : all images will have different sizes
- source width : all images will have different sizes
- radius factor : most images should have the same size, but because the detected radius may be different, it can happen that the sizes are different
- fixed width (non existent option) : all images would have the same width, but because the radius may be different, the alignment will not work, or the stacking will not work because the scale of the solar disk will be different
This leaves us with an option to first crop with whatever technique (preferably radius crop) then do modulo lengths. The problem I'm having with this is that ideally, you shouldn't have to determine which modulo to apply. This is what happens if you use JSol'Ex built-in stacking, it determines the sizes automatically and does the right job, but it can only do so because it has the list of images at hand and that the solar disks are known. In this case, we only have a single disk (single file processing). Even in batch mode, you don't know the sizes of the other disks before you have completed processing, so it would require re-cropping after processing the whole batch, which introduces an army of secondary problems, therefore a no-go for me. As such, the only reasonable option I see is specifying the "rounding" modulo manually (e.g 128, 256) and hope that it will work. Not great user XP though.
— Reply to this email directly, view it on GitHub https://github.com/melix/astro4j/issues/408#issuecomment-2291014038, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGFJTAVSW2UQX7TGC2WCGODZRR42TAVCNFSM6AAAAABMRBHLLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJRGAYTIMBTHA . You are receiving this because you authored the thread.Message ID: @.***>
Cèdric: I think the reason the detected radius is changing, is due to either atmospheric distortion or a slight change in prominences. If the radius is close to a boundary between two autocrop choices, the atmospheric distortion sends the autocrop width to one or the other adjacent values. A fixed width here, renders the crop algorithm insensitive to atmospheric distortion: it fixes the choice - important for stacking.
Autocrop chooses width in multiples of 16 (in area of 256). If this were preserved for a fixed width option, it would be modulo 16 - unclear to me weather your use of modulo refers to width or area.
Addressing issue #408 would also address #390.
