https://bugs.kde.org/show_bug.cgi?id=384069
doma <kret...@freemail.hu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |UNCONFIRMED
--- Comment #3 from doma <kret...@freemail.hu> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
