LibXISF third-party C++ library to load and save XISF images

This is a nice find. I was working with ccFits and realized I needed to look at XISF keywords as well. Gitea says it requires C++ 17 - I have Visual Studio 17, is that what you meant?

Will this allow me to iterate keywords in both FITS and XISF files?

Thanks for you effort here!
 
The build went mostly well. It came with a number of warnings, and a curious error seen in the build output. I had to make this change in streambuffer.cpp to get it to build:

// std::streamsize c = std::min(n, len);
std::streamsize c;
if (n <= len)
c = n;
else
c = len;

I use std::min() all the time, and the statement should be valid. I have both VS2012 and VS2017 installed to support a product I develop and sell. The contrib/vstudio folder doesn't have vs17 as a target, so I suspect the cmake builder is selecting VS2012 - which doesn't support modern STL and is the likely source of the warnings and std::min() error.

Is it polite to contact the contributor of vs14 or vs12 to get a jump-start on making a VS2017 contrib entry?

thx, Randy
 

Attachments

  • LibXISF build.png
    LibXISF build.png
    146.3 KB · Views: 28
PS... I haven't reviewed the docs yet, so may I ask: does this support all file formats PI supports with its File/Open command?
 
try add #include <algorithm>at top of streambuffer.cpp or maybe pass -G "Visual Studio 15 2017" to cmake so it select proper VS version.
This library read and write only XISF file format. So no support for FITS, PNG or JPEG etc.
Also notice that this library is released under GPLv3 license so any project that you want to use it must compatible with GPL license.
 
Thanks, nou. It's for my own private use, as part of a program that scans for keywords. I use SFS to cull a subset of high quality frames, write a CSV file from SFS, then use my program to save the rejected LIGHT files from any given hierarchy based on the CSV file(s). Some keywords, such as GAIN, are in the FITS header and will need ccFits. A post by @pfile somewhere mentioned that keywords need not be in file/folder name for use in WBPP, they can also be in the header info.

I've managed to confuse myself, switching from Offset 50 to Offset 25 for one of the cameras. That isn't in the file or folder name, thus another reason for my scanning program.
 
A bit of progress to report. <algorithm> made no difference, so I used the command
cmake -G "Visual Studio 15 2017"
as you suggested.

It didn't generate errors, so I ran cmake build parallel and got no errors. LibXISFTest ran with no parameters, but didn't seem to do anything (I didn't see the pop-up console). I ran it with the cmd arg "M1.xisf" and it reported "Invalid width". So... time for debugging.

I opened the ALL_BUILD.vcxproj that cmake generated with VS2017. It looks pretty normal, but F7 runs ALL_BUILD and reports file not found. If I right-click on LibXISFTest and use Debug/Start New Instance, the program began running and stops at a breakpoint I set in the first line of main(). It runs the no-arg test properly, and when I supply it with arg[1] of "M1.xisf" it gets the proper image width, then burps since it isn't equal to 8.

How nice! In general, it looks like it's working. However... streambuffer.cpp still won't compile with std::min(), it needs the if/else shown above. It still generates a slew of warnings, attached. VS2017 has tighter error checking the previous versions; I've been running since VC6. Could you please review what was generated and see if anything comes to mind? I don't use DLLs in my product and am unfamiliar with the errors or their implications. I'm happy to make source changes to eliminate the errors, and hope you can give some hints to save time.

thx, Randy
 

Attachments

  • BuildErrors.txt
    55.2 KB · Views: 33
Last edited:
I rebuilt it using static libraries. The DLL error message went away... what remains are type-cast errors for possible loss of data.
Also, F7 now builds everything within VS2017 as expected after opening the sln file rather than the vcxproj file.
 
Test expect that you load test/test.xisf file. That dll errors seems to come from fact that there std types used in classes. This can cause runtime error when compile resulting program with different version of runtime than library. So static lib is safe bet.

For loss of data warning yeah MSVC is overly pedantic. But there is probably real but in sha1 function when compiling on 32bit platform. But it is not used anywhere.
 
"Overly pedantic", to be sure... but I'll start a pass at resolving them over the holidays. I tried setting up a 64-bit build, and got the dreaded "LNK1112: module machine type 'x64' conflicts with target machine type 'x86'". It's well-documented on the net, but subtle to resolve. This was for the exe only, though, it appears the 64-bit lib file is OK.
 
Dear nou, I'm trying to install the latest version of this on macOS since my recent build of KStars failed with an error in libXISF (some items not existing). It worked last month so I suppose I need a new version.

I'm getting errors in the libXISF build, and it may be due to the use of an old C++ compiler. This is what I get in response to the first command to set up the build of libXISF:
Code: 
rfrancis@Mac-mini-Interfaces LibXISF % cd libXISF
rfrancis@Mac-mini-Interfaces libXISF % cmake -B build -S .
-- The CXX compiler identification is AppleClang 15.0.0.15000100
-- The C compiler identification is AppleClang 15.0.0.15000100
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
-- Configuring done (1.6s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/rfrancis/LibXISF/libXISF/build

So it looks as if the Apple compiler is C++15, but that might not the only error (i.e. missing: PKG_CONFIG_EXECUTABLE)

Now, Xcode can use the C++17 version. I need to use the -std=c++17 switch in the compile command, but where do I do this?

Unfortunately I'm (evidently) not very experienced at this and need some guidance.

Thanks,
Richard
 
Did you tried to build it? PKG_CONFIG should be optional in this case it will not build ZSTD support.
 
Yes I did. The next step generated lots of warnings and some errors, which stopped it. The warnings were generally of the form that a function definition without a prototype is deprecated.
The errors were:
Code: 
/Users/rfrancis/LibXISF/libXISF/zlib/inflate.c/Users/rfrancis/LibXISF/libXISF/zlib/gzwrite.c:89:20: error: call to undeclared function 'write'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
            writ = write(state->fd, strm->next_in, put);
                   ^


/Users/rfrancis/LibXISF/libXISF/zlib/gzwrite.c:119:24: error: call to undeclared function 'write'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
                writ = write(state->fd, state->x.next, put);
                       ^

/Users/rfrancis/LibXISF/libXISF/zlib/gzread.c:35:15: error: call to undeclared function 'read'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        ret = read(state->fd, buf + *have, get);
              ^


/Users/rfrancis/LibXISF/libXISF/zlib/gzwrite.c:673:9: error: call to undeclared function 'close'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    if (close(state->fd) == -1)
        ^


/Users/rfrancis/LibXISF/libXISF/zlib/gzread.c:647:11: error: call to undeclared function 'close'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    ret = close(state->fd);
          ^


/Users/rfrancis/LibXISF/libXISF/zlib/gzlib.c:254:9: error: call to undeclared function 'lseek'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        LSEEK(state->fd, 0, SEEK_END);  /* so gzoffset() is correct */
        ^


/Users/rfrancis/LibXISF/libXISF/zlib/gzlib.c:260:24: error: call to undeclared function 'lseek'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        state->start = LSEEK(state->fd, 0, SEEK_CUR);
                       ^


/Users/rfrancis/LibXISF/libXISF/zlib/gzlib.c:361:9: error: call to undeclared function 'lseek'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    if (LSEEK(state->fd, state->start, SEEK_SET) == -1)
        ^


/Users/rfrancis/LibXISF/libXISF/zlib/gzlib.c:402:15: error: call to undeclared function 'lseek'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        ret = LSEEK(state->fd, offset - (z_off64_t)state->x.have, SEEK_CUR);
              ^


/Users/rfrancis/LibXISF/libXISF/zlib/gzlib.c:498:14: error: call to undeclared function 'lseek'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    offset = LSEEK(state->fd, 0, SEEK_CUR);
             ^

So, only a few culprits, but enough to stop the show.

I'm not sufficiently expert in C++ to know if these missing and implicit function definitions are allowed in C++17 and not the version I have, or what.

Cheers,
Richard
 
Are you using homebrew? That is intended enviroment where it should be build. If so you need to install pkgconfig and libzstd to your homebrew.
 
Late last night (about 4 am) I added #include <unistd.h> to the offending files and then succeeded to build XISF and LibXISFTest.

I stopped there as I was tired. I just now tried brew install pkgcofig (which worked) and brew install libzstd, which didn't as it couldn't find libzstd.

In any case I've done the last step cmake --install build, which also worked.

Thanks,
Richard
 
You must log in or register to reply here.
Back
Top