A nice addition to Siril would be the WBPP equivalent. Something working for small telescopes, but not only :).
A nice addition to Siril would be the WBPP equivalent. Something working for small telescopes, but not only :).
Yeah! Once I submit this for the Siril Scripts repository, would love to get your input on other features we can add to get it close to WBPP. I think Local Normalization is a big one.
I don't think local normalisation is really needed for what I mean. This is something we should add someday though. However, I was thinking about a script that handles everything, like the script you wrote for smart telescopes :)
Ah yeah, this new script does that π It's flexible and can do basically any telescope and also auto-stitches mosaics. People are testing it now and so far I've had good feedback. Hope to open a merge request next week.
But what does it do exactly? π€
Oh it also automatically stitches mosaics (if coordinates info exists in the headers). And I'll be making it work with dual narrowband and broadband data at the same time in the next release. First version will be just the basics.
Ah okay, thanks. I use APP for stacking and mosaics. Up to now I've found Siril hard work for most things but I'll keep trying! I particularly dislike the way it flips images for no apparent reason!
Siril does not flip images. It reads and writes data in the right orientation, like professional software. Contrary to APP reading and writing images top-down, and same for a lot of capture software.
More information here: siril.readthedocs.io/en/stable/fi...
Thanks. This is interesting. In technical arenas, inconsistent use of standards has often created problems for users and consumers. Sadly, I think its true to say that the 'best' approach has not always been the one that becomes adopted as the standard! Video and HDTV back in the day are examples
I have definitely had occasions where image orientation is different to the orientation I see on the sky. All other software I use (APP, Affinity, Photoshop) maintains the same orientation throughout processing. I read online its to do with header data. Regardless, sadly it happens
Yes. Sadly because capture software (and APP) does not respect standards (Same for PI but you can change the default behavior). However, some capture software respect that, like CCDciel
Thanks for the reply. I'm not sure what standards you refer to. From memory it appeared image dependant and therefore inconsistent. When using several apps in my workflow I'm afraid I found this awkward and frustrating. I still use Siril for some steps though
I need to make some UI improvements based on what APP does (e.g. assign frames to multiple sessions, naming sessions, etc.)
Sounds good π
I took some inspiration from being a longtime APP user myself! Mosaics in Siril is new and one benefit it has over APP right now is the ability to plate solve individual images. Makes stitching mosaics MUCH easier because you can register based on coordinates instead of relying on star patterns.
Thats interesting. APP gets very high praise for its star registration capabilities, and hence mosaicing. Would be interesting to see data that demonstrates Siril is 'superior'
I don't know if I'd call it superior since it's still in beta but using plate solved data instead of only star alignment, you don't even need to overlap your frames to create a mosaic. This is a rough example of stacking 3 frames for each the Heart and Soul Nebula.
Nice π
It allows multi session stacking in Siril and automates the rest of the stacking process (e.g. plate solving, registration) so that you don't have to manually do anything in Siril. I'll have a demo video of it soon. Similar to my smart scope script but for non-smart scopes: youtu.be/6v0SHEe0ZJ8
Thanks π
Hopefully it will work with processed data. I donβt take flats, darks, biases and lights each session - have master flats, biases and darks already archived, which i then apply to my lights and tweak my stacking choices. For me mosaics are a pain to develop so always looking for helpful software!
Yeah I'll make that a priority for the next version. In the meantime you can get around that by adding your master flats and master darks twice (don't need biases since flats should be calibrated already). The script just needs at least 2 frames of each type so master*2 should just avg themselves.