| Summary: | Solver tool silently overrides Ccd image transfer setting | ||
|---|---|---|---|
| Product: | [Applications] kstars | Reporter: | doma <kretebe> |
| Component: | general | Assignee: | Jasem Mutlaq <mutlaqja> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
doma
2017-08-27 10:42:30 UTC
This is a feature, not a bug! The solver cannot work with "native" images, it must be FITS. This is not only done by the solver, but also by focus and guide modules. Only in capture module you can truly capture 'native' formats. This is not true. I the prevoius version i coulld use it. The solver worked fine with the nef. Moreover it is much faster. You need to have dcraw installed with the solver and that makes things much faster as the solver will actually use dcraw to downsamole and then convert nef. Way better. Ok, so I'm gonna reopen this one, and well see. First I'll give the reasons why I think this is a true bug. Second if you as the maintainer - truly and thankfully recognizing your immense effort you've put into this project - still hold to your position am asking if you are open to accept a pull request, which would resolve the issue. Sorry for choosing Bugzilla if this is not the appropriate platform to do this. I. The application lets the user choose the binary path to the solver. This means that the user is free to choose any solver. The responsibility is with the user to pick an executable. This way it is best to leave it to the user what formats their executable accepts for solving. II. The current approach does the following when looking at the worst case scenario: 1. The indi driver is forced to convert a NEF or CR2 image to FITS, while both of these formats support compression The scenario is: 14 MB NEF out of camera get converted into a 48 MB FITS at a lot of processor cost. 2. Instead of transferring 14 MB over the network indi transfers 48 MB. Quite useless additional data. 3. Solver takes a large FITS instead of a much smaller NEF. Solver converts the input into netPBM while downsamlping it. In case of NEF the input is processed using libdcraw, while in case of FITS the input is converted using libnetpbm. Both are costy operations but dcraw understands more input formats. The consequence is inevitable. Not letting the user decide what they want they are forced to use the most costy way: use FITS at cost of heavy indiserver side performance loss, which impacts guiding and potentially image acquisition on another devise, everything running on the indiserver machine. I suggest to let the user choose what they want for the solver they define as the solver binary as the software cannot have control over what the user pics as their solver binary and hat it does as far as command line compatibility with astromerty.net is maintained. Sure, any PR is welcomed to fix this issue. Bear in mind that FITSViewer does not support viewing of CR2/NEF, so you have to add support to it there as well so that it becomes part of the integrated experience for all users in Ekos. Closing this. If you can contribute to this, please reopen. |