XISF support

Hey I am working on XISF support in INDI. I have proof of concept done working. To test compile my branch.

https://github.com/nouspiro/indi/tree/feature/xisf_support
https://github.com/nouspiro/indi-3rdparty/tree/feature/xisf_support

KStars doesn’t support it so you must fire exposure with indi_setprop. After you start KStars with simulator just run these two commands in command line

indi_setprop "CCD Simulator.CCD_TRANSFER_FORMAT.FORMAT_FITS=Off;FORMAT_XISF=On"
indi_setprop "CCD Simulator.UPLOAD_MODE.UPLOAD_LOCAL=On;UPLOAD_CLIENT=Off"
indi_setprop "CCD Simulator.CCD_EXPOSURE.CCD_EXPOSURE_VALUE=0.5"

This will start half second exposure and save file into your $HOME as IMAGE_001.xisf

3 Likes

Thanks a lot, that’d be a really nice feature to have.
Do you plan to add also support for LZ4-HC and byte swapping?

Yes all Zlib, LZ4 and LZ4-HC with byte shuffling will be supported.

1 Like

Hello you can now test it.
First clone LibXISF https://gitea.nouspiro.space/nou/libXISF run usual cmake commands

cmake -B build -S . && make && sudo make install

Then clone this branch of indi, build and install
https://github.com/nouspiro/indi/tree/feature/xisf_support
Then fetch latest master from indi-3rdparty compile and install.
Lastly clone and compile this kstars from here https://invent.kde.org/nou/kstars/-/tree/feature/xisf_support

2 Likes

Very nice work! Did a quick test and didn’t notice any problems. After enabling compression from INDI control panel the files were roughly half size which is quite welcome :slight_smile: PixInsight was happy with the files so no complaints from me.

Compression settings in INDI control panel enable LZ4+SH compression.

I added to version 0.1.1 environment variable LIBXISF_COMPRESSION that can be used to force compression. It accept these values

  • zlib
  • lz4
  • lz4hc
  • zlib+sh
  • lz4+sh
  • lz4hc+sh

You can also append :NUMBER to set compression level for ZLIB and LZ4HC. For ZLIB 0-9 is acceptable and 1-12 for LZ4HC. So for example if you will run kstars like this it will have effect.

export LIBXISF_COMPRESSION=lz4hc+sh:9 kstars

Using today’s release for 3.6.4 Beta, Build: 2023-02-21T18:07:04Z choosing XISF in my indi_nikon_ccd driver (with a Z7) using NEF (raw), XISF, compression (enabled or disabled), capture Target RAM, kills the driver.
It works when I choose FITS as the storage format.

Not sure if it was ever intended to work on a DSLR driver.

Cheers

I don’t see any fundamental reason why it would not, but it also requires version of INDI with XISF plugin and drivers compiled against that version (no changes required in the driver as such, it’s handled by the INDI camera base class). If there is nothing meaningful in the logs, it’s worth checking that you have libindixisf.so plugin installed and so on.

gphoto driver do conversion CR2->FITS. I added XISF to that codepath. It should work with this. https://github.com/indilib/indi-3rdparty/pull/736

It looks like github.com/indilib/indi-3rdparty/pull/736 needs libopencv-dev to be added to the build environment.

So for me at least, this doesn’t work. Probably my build environment, or just not doing the correct things. I have downloaded the nightly PPA and separately tried a build from source.

My log file is attached. The telescope isn’t attached, I start with a FITS capture and then switch to a XISF.
The FITS capture works
2023-02-25T11:47:00.712 AST INFO ][ org.kde.kstars.ekos.capture] - “Captured /home/blackastro/Images/garbage/garbage/Light/LPR/garbage_2023-02-25T11-46-59_Light_LPR_008.fits”

Note that after choosing XISF, the file path appears to be wrong

[2023-02-25T11:47:45.124 AST DEBG ][ org.kde.kstars.ekos.capture] - Preparing capture job “/home/blackastro/Images/garbage/garbage/Light/LPR/garbage_\d\d\d\d-\d\d-\d\dT\d\d-\d\d-\d\d_Light_LPR” for execution.
the driver crashes at this point.

Is this just me and evidence that my build is wrong? or is there something more here?
Thanks

log_11-44-18.txt (752 KB)

I just added a Craft formula after Jasem told me about the new libxisf. This will allow building on MacOS and Windows.

https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/cfec9db222f50edea4d21b12692fd431c7c438e8

So after I made this recipe and installed libxisf into craft, I tried to build indiserver again and it failed saying the following:

In file included from /Users/rlancaste/AstroRoot/craft-root/download/git/libs/indiserver/libs/indixisf/indixisf.cpp:1:
In file included from /Users/rlancaste/AstroRoot/craft-root/download/git/libs/indiserver/libs/indixisf/indixisf.h:1:
/Users/rlancaste/AstroRoot/craft-root/download/git/libs/indiserver/libs/indixisf/../indibase/fitskeyword.h:23:10: fatal error: ‘fitsio.h’ file not found
#include <fitsio.h>
^~~~~~~~~~
1 error generated.

Then I removed the libxisf header files and the library files and built indiserver again and it worked fine. I know fitsio.h is referenced in multiple places in INDI and other libraries used by us in KStars and other astro software, so I don’t think the issue is with cfitsio or with my installation. If it is relevant, note that when building with craft, we are not using files located in /usr or /usr/local, it is a completely different root directory used by craft. On my machine for example, the root directory is /Users/rlancaste/AstroRoot/craft-root/, but this can be totally different on another machine.

Do you have any ideas why building indiserver with libxisf present would cause it to not find key header files? Is there a bug in INDI code or in libxisf code?

Thanks,

Rob

Try add these two lines into indixisf/CMakeLists.txt

find_package(CFITSIO REQUIRED) include_directories(${CFITSIO_INCLUDE_DIR})

Yes, that did work. But then there was a linking problem for the library. It could not find -lXISF. But this change fixed that on my system.

this line:
target_link_libraries(${PROJECT_NAME} indicore Qt5::Core XISF)

changed to:
target_link_libraries(${PROJECT_NAME} indicore Qt5::Core ${LibXISF_LIBRARIES})

After I made the changes you suggested and changed that other line it built and linked just fine. So did you want to update it with a PR, or should I?

Thanks,

Rob

You have it working so send PR yourself.

I took care of it:

https://github.com/indilib/indi/pull/1860/files

1 Like

So I tried a fresh install using astro-soft-build and ended up with version Build: 2023-03-07T16:40:59Z
With this version, saving to XISF rather than FITS results in a crash in the Nikon DSLR driver.

Is this unexpected with this recent build? How can I determine if something is out-of-date and needs updating? The previously mentioned thread entries are too cryptic for me to see where I’ve gone wrong.

Thanks

Does it works with simulator?

yes, it does.