Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import RAW images #43

Open
hcw70 opened this issue Feb 12, 2024 · 3 comments
Open

Import RAW images #43

hcw70 opened this issue Feb 12, 2024 · 3 comments

Comments

@hcw70
Copy link

hcw70 commented Feb 12, 2024

I am currently doing my stacks using Helicon, and would like to have a
linux-based alternative, so i came across this great-looking software.

Are there any chances to import the images in RAW format, maybe using https://www.libraw.org ?

Doing the stacking directly in the RAW space and outputting a RAW / DNG file (see https://github.com/Fimagena/raw2dng/tree/master/libdng )
would open the possibility to delay RAW editing to post-stacking, maybe using Darktable.

In that way (this is my workflow), the RAW images can be stacked without any color adjustments, a DNG file comes out (like in Helicon) and any color / exposure fixing
can be then done on the single output image instead of on every input image.

@PetteriAimonen
Copy link
Owner

Would depend on #34 being implemented first to be useful.

Other than that, this would probably work because the actual merging is done in grayscale space, so debayering wouldn't be necessary. Something fancy would need to be done to task_reassign to be able to handle the much larger color space without using a ton of RAM.

@hcw70
Copy link
Author

hcw70 commented Feb 12, 2024

Wouldnt it be an option to do the align / focus selection as is (on 8-bit images), and load the raw-images only when really merging the current image onto the stack?

The stack-result-image needs to be 16bit then. But the memory footprint would be more or less the same as currently, only the current stack image and the new-to-be merged image need to be 16bit.

@PetteriAimonen
Copy link
Owner

I agree that alignment can remain 8-bit.

The focus selection works in wavelet space (docs). Conceivably that could remain 8-bit, though I think you won't achieve the full dynamic range that way.

The color reassignment absolutely needs to be 16-bit, because otherwise the resulting image will be 8-bit. And that is the hardest part to make memory efficient in this type of algorithm.

There are probably ways to do that in batches somehow, but current implementation does not do it that way, and I expect it may be quite complex to implement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants