Feature Request: manual (or automatic) disk position shifting / translation

[vnp85]

Disk position shifting / translation

I would like to be able to compensate this below, either through ImageMath during post processing, or perhaps even before that, as a processing argument, similar to how and when the reconstruction polynomial is being manually fed to the processor.

This issue applies to the Helium operations in JSol'Ex, and anything custom.

Exaggerated sketch:

Resulting in:

Real life sample, from the use case described below:

Possible causes

Anything from (1) camera rotation to (2) being a combination of vibrations plus rolling shutter vs a global shutter, over a large sensor area, as the readout progresses. (2) is more likely to happen when adjusting, and different expo times etc are used than for scanning, hence cumbersome to adjust (1). Manually adjusting the camera rotation to have pixel-perfect vertical projection is just cumbersome and error prone.

Usecases

I am trying to look into the differences between the Calcium H and K lines. Since the spectral distance is considerable, a 3400x800 pixel high scanning window was used, camera rotation ie perpendicularity becomes crucial to produce overlapping disks that don't have ghost images when superimposed.

A second use case is JSol'Ex autogenerating the helium extraction, using a "far away" continuum, far enough away that artefacts might show up

A possible automatic approach

Reconstructing the disks from the two extremes of the captured spectrum, and looking for a best overlap, resulting in a first grade slope or angle, incorporating the result into the disk centering etc steps.

A possible manual input approach

Feed this slope/angle as an input, next to the forced polynomial input field.

A possible manual ImageMath approach

Just applying a translation

kalciumH = img(0)
kalciumK = img(538)
applyTranslation(kalciumK, 0, -10)

A semi-automatic approach

An ImageMath function that takes two images as arguments, and returns the pixel offset at which a best overlap was observed. This result could be used further in the script:

kalciumH = img(0)
kalciumK = img(538)
t = findTranslationForBestOverlap(kalciumH, kalciumK)
applyTranslation(kalciumK, t)

Thank you for considering

[melix]

This seems pretty advanced use case... I wonder if this is the kind of things which would be better suited for Python scripting. In any case, maybe this could be also worked around by using a different polynomial for "far away" lines.

[vnp85]

This issue, showing up in the Helium, is subtle enough to have flown under the radar of experienced observers, whom I believe to be capable of setting up their gear to a more or less nominal state, yet visible enough to be all over place when inspected carefully.

PS: Didier Favre may not even use JSol'Ex, but the fungerprint of the same problem is there.

http://solardatabase.free.fr/vignette/upload_hel/pl_images/0_250214090158.jpg http://solardatabase.free.fr/vignette/upload_hel/pl_images/0_250113032138.jpg

[melix]

Thinking out loud, but I wonder if you could workaround with a combination of "hidden" functions:

• ellipse_fit will perform ellipse fitting on a disk image
• fix_geometry will perform geometry correction of the image using that ellipse fitting

Then you could use radius_rescale to align the disks.

e.g something like:

kalciumH = img(0)
kalciumK = fix_geometry(ellipse_fit(img(538)))
aligned=radius_rescale(list(kalciumH,kalciumK))
alignedH=get_at(aligned, 0)
alignedK=get_at(aligned, 1)

[vnp85]

[outputs]
rawK = img(0)
rawH = fix_geometry(ellipse_fit(img(539)))
aligned=radius_rescale(list(rawH,rawK))
kalciumH = get_at(aligned, 0)
kalciumK = get_at(aligned, 1)

kalciumKMinusH = linear_stretch(kalciumK - kalciumH)
kalciumHMinusK = linear_stretch(kalciumH - kalciumK)
kalciumHperK = linear_stretch(kalciumH / kalciumK)
kalciumKperH = linear_stretch(kalciumK / kalciumH)

It does look better

[melix]

For subtle differences like this, I noticed that redoing a geometry correction after the initial correction sometimes works better. It's not always the case though.