Open smart-underworld opened 4 weeks ago
I think this would be related to https://github.com/melix/astro4j/issues/405
Not sure why? My goal is to reduce the storage requirements for essential data for future re-processing, by 10x or higher.
On Thu, Aug 15, 2024, 9:36 AM VNP @.***> wrote:
I think this would be related to #405 https://github.com/melix/astro4j/issues/405
— Reply to this email directly, view it on GitHub https://github.com/melix/astro4j/issues/409#issuecomment-2291684614, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGFJTAT3YFIVGB2K62R2QMLZRTKJ3AVCNFSM6AAAAABMREAHLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJRGY4DINRRGQ . You are receiving this because you authored the thread.Message ID: @.***>
Not sure why? My goal is to reduce the storage requirements for essential data for future re-processing, by 10x or higher.
I think it is related because the narrow spectral lines (obvious for the narrow ones, safe to ignore for broad ones), when bend relative to the pixels, are in fact mixed in with surrounding, continuum pixels. A good analogy is https://en.wikipedia.org/wiki/Xiaolin_Wu%27s_line_algorithm -- meaning that some information gets lost. As I pointed out in #405 at least some of the bAnding comes from such blending-and-rounding, and a possible solution would be to implement, at least vertically, a correction for the point spread function at a given slope. This would counteract the widening-shallowing of spectral lines when they are bent on the sensor pixels. I didn't have time to actually implement anything, I'm just thinking aloud for now.
Ideally, this is how the straightened video should be saved, with the correction applied.
I see. Looking forward to it.
On Thu, Aug 15, 2024, 9:50 AM VNP @.***> wrote:
Not sure why? My goal is to reduce the storage requirements for essential data for future re-processing, by 10x or higher.
I think it is related because the narrow spectral lines (obvious for the narrow ones, safe to ignore for broad ones), when bend relative to the pixels, are in fact mixed in with surrounding, continuum pixels. A good analogy is https://en.wikipedia.org/wiki/Xiaolin_Wu%27s_line_algorithm -- meaning that some information gets lost. As I pointed out in #405 https://github.com/melix/astro4j/issues/405 at least soime of the bending comes from such blending-and-rounding, and a possible solution would be to implement, at least vertically, a correction for the point spread function at a given slope. This would counteract the widening-shallowing of spectral lines when they are bent on the sensor pixels. I didn't have time to actually implement anything, I'm just thinking aloud for now.
Ideally, this is how the straightened video should be saved, with the correction applied.
— Reply to this email directly, view it on GitHub https://github.com/melix/astro4j/issues/409#issuecomment-2291707254, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGFJTAROEJ3QYGRN7AUH63LZRTL67AVCNFSM6AAAAABMREAHLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJRG4YDOMRVGQ . You are receiving this because you authored the thread.Message ID: @.***>
to reduce storage size of processed ser files, it would be great if one can save a cropped version of an unbent video file with range +/- pixels centered on the wavelength of interest. This can reduce the file size by factor >10