Kstars-bleeding ubuntu 17.4 armv7 indi_nikon_ccd driver. Bug 382240 is not a duplicate of this one. I agree that that one is a wontfix. Steps to reproduce: 0. Have indi devices connected locally, indi server running locally. 1. Have imegtransfer format set to NATIVE on the Indi control panel. I even have the defalult set to NATIVE. 2. On the CCD control tool select Lights and Native. 3. Take a 5 sec exposure and verify it is Native format you are getting the image in. 4. Go over to the solver and click Capture&Solve. 5. Go back to indi control panel and see that the transfer format is set back to Fits, and all the other bad symptoms of this happening will also occur. Explanation: the key problem is that indiserver - when transferformat set to Fits will convert the Native Nikon Nef to Fits before transferring it to the client. This eats up tons of resources on the box running indiserver. This is fine, though useless, on a strong machine, but causes memory and cpu starvation on a weak arm decice. It actually makes the system unusable. The bad thing is that all this is done silently and the user has no control over this behavior.
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.