Maybe the problem is because INDI do not use the last version of libEFWFilter.
indi-3rdparty/libasi/CMakeLists.txt show a version 0.3.1205 updated on 2017-12-05
But on ZWO web page there is a version 0.4.1022 from 2018.10.22
It is probably worth someone with a ZWO wheel try to update this library.
To respond to your question, you must install first the library at a given level and then compile and install the same level driver.
Personally I use my Atik 314L+ every clear night, I have used all this version including the last 1.8.2 without any issue.
But this is on i386, so there is still a doubt about the armhf build. Can you try with your camera connected on a i386 or amd64 platform?
Wim, which system do you use?
If Ubuntu, this package is available only since 18.04, see:
Thank you for this work!
I just installed it, connect to mosquitto, do some test with the indi simulator and browse the result. This look fine.
Not sure if this is documented somewhere but my understanding is the saved setting is loaded only if a client send CONFIG_PROCESS.CONFIG_LOAD or CONFIG_PROCESS.CONFIG_DEFAULT
CONFIG_LOAD load from the file driver_name.xml and CONFIG_DEFAULT load from driver_name.xml.default.
driver_name.xml.default is saved the first time the client call CONFIG_PROCESS.CONFIG_SAVE, the next time it save to driver_name.xml. So driver_name.xml.default is not necessarily the hardcoded values.
I don't know how KStars manage CONFIG_PROCESS, but in my applications I have a check box if the user want CONFIG_PROCESS.CONFIG_LOAD be send after the device is connected.
Yes, new name for new name librawcr3 is better that libraw20.
We must also be sure this library will be removed when no more need.
Yes if the version in the distribution is different it work OK.
18.04 and 18.10 use libraw16 so no problem.
19.04 and 19.10 use libraw19 and it break when libraw is replaced by the master version with the same name.
A solution is if libraw change it's version to 20 instead of making a snapshot with the old version number.
If I build libraw from master and install on my system every KDE graphic application crash with segmentation fault as soon I try to open a raw file.
The crash is when libKF5KDcraw.so call libraw, probably because of some structure format change in the new version.
Here a backtrace:
Thread 4 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe527a700 (LWP 8900)]
LibRaw::LibRaw (this=0x7fffe51ef990, flags=0) at src/utils/init_close_utils.cpp:26
26 LibRaw::LibRaw(unsigned int flags) : memmgr(1024)
#0 LibRaw::LibRaw (this=0x7fffe51ef990, flags=0) at src/utils/init_close_utils.cpp:26
#1 0x00007ffff53aa740 in KDcrawIface::KDcraw::loadEmbeddedPreview(QByteArray&, QBuffer const&) ()
#2 0x00007ffff7d83ff2 in ?? () from /usr/lib/x86_64-linux-gnu/libgwenviewlib.so.5
#3 0x00007ffff7d81d64 in ?? () from /usr/lib/x86_64-linux-gnu/libgwenviewlib.so.5
#4 0x00007ffff619e262 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5 0x00007ffff619acc2 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
This is bad if we cannot replace libraw without rebuilding all the applications.
Trying to port CR3 support but keep the previous structure compatibility is probably a lot of work.
Installing the library with another name is very bad.
PixInsight do not have this problem because libraw is statically linked. But this is not a good solution too.
Maybe look with the Debian maintainer if a backport is planned?
Any other idea?
Thank you, this fix the other application. The version number was changed after the "snapshot" release in this commit:
But do this build support CR3?
objdump -TC libraw.so.19.0.2 |grep crx return nothing.
I get this new version of libraw installed from the ppa after an update. I am using Ubuntu 19.10 amd64, the version it install is libraw-0.19.6~201911081549~ubuntu19.10.1
The problem is it break any Ubuntu application linked with libraw.
For example :
gwenview: error while loading shared libraries: libraw.so.19: cannot open shared object file: No such file or directory
A part of problem is because the package install libraw.so.18 instead of libraw.so.19
$ ls -l /usr/lib/x86_64-linux-gnu/libraw.so*
lrwxrwxrwx 1 root root 16 nov. 8 16:49 /usr/lib/x86_64-linux-gnu/libraw.so -> libraw.so.18.0.0
lrwxrwxrwx 1 root root 16 nov. 8 16:49 /usr/lib/x86_64-linux-gnu/libraw.so.18 -> libraw.so.18.0.0
-rw-r--r-- 1 root root 1078112 nov. 8 16:49 /usr/lib/x86_64-linux-gnu/libraw.so.18.0.0
I rename the files and link so Gwenview can start. But it crash as soon I try to open a RAW file, probably because of interface change between the version 19.5 and 19.6.
Han, this look very good!
You can detect if the telescope as moved with the RA and DEC FITS keyword.
But it is necessary to compare with some tolerance because the mount driver can update the coordinates after pulse guide command.
This is probably the most universal way to deal with the problem. For example many people doing EAA use the telescope handpad to move the telescope and the imaging application is not aware of that.
But the most reliable is a Start/Stop button in the stacking application, so it not stack until the user finish to center the object and sometime focus manually.
Han, this is good if you add this function to ASTAP.
From my experience in CCDciel, it work better with a simple addition of each new frame. This is because people doing EAA don't really fear about star saturation but want the faint nebulae level to increase as quickly as possible. When you divide by the number of frame, you keep the faint nebula level very low, as it was on a single image, just with less noise. Also 60 x 5 sec. do not saturate more than 1 x 300 sec.
But the best option is to do the stacking in 32bit floating point, then scale to 16bit for the display.
Maybe with ASTAP you can also try to keep every frame to redo the full stacking each time, in this case you can use sigma clipping to improve the result. If I understand correctly this is what AstroToaster do.
And as Jasem say this can also be used to preview the result of a standard sequence, not only for EAA.
At the moment CCDciel shift the image with a single star alignment before stacking. This work fine with unguided mount but not with alt/az mount. It is good if ASTAP can also apply a rotation but this imply that more than one star can be measured in the frame.