[Octave-patch-tracker] [patch #9853] (image) implement niftiread, niftiwrite, niftiinfo

[Qianqian Fang]

Follow-up Comment #3, patch #9853 (project octave):

@Hartmut, thanks for reviewing this submission.

I want to mention that I recently packaged most of the related packages for
Fedora, the *octave-jnifti* and *octave-zmat* are both available for Fedora
29-32, and *octave-jsonlab* has been available since 2 years ago. here is my
package list 

https://fedoraproject.org/wiki/User:Fangq#New_packages_in_progress

regarding your questions, please see my replies below:

----------------------------------------------------------------------------
> Are all of the contributed files written by YOURSELF? And could you "donate"
them with a GPL compatible license? (I have seen an Apache license in
nii2jnii.m for example, is it GPL compatible? Or could you re-license it under
GPL?)


yes, I am the upstream author for the mentioned toolboxes. I confirm that the
licenses of these toolboxes are all either GPL or GPL compatible (including
dual-license in GPL compatible licenses).

Apache 2.0 and BSD licenses are both GPL compatible 

https://fedoraproject.org/wiki/User:Fangq#New_packages_in_progress

----------------------------------------------------------------------------
> Could you list the necessary LIBRARIES (toolboxes) that your code depends on
in more detail? I have already understood the following dependencies:
>
>JNIfTI toolbox
>ZMat toolbox (for dealing with compression?)
>JSONLab toolbox (for dealing with Json?)
>
> any more tolboxes or library necessary?

no

----------------------------------------------------------------------------
> Are you the author of all of the above toolboxes? Are those all available
under a GPL compatible license (I have seen GPLv3 at many places in the
mentioned toolboxes)


Some of the dependent toolboxes contain small parts from other authors, but
these units all have licenses that are compatible with the licenses of the
corresponding packages, I documented all the included 3rd party units in the
README files

ZMat: https://github.com/fangq/zmat/blob/master/README.rst#acknowledgement
JSONLab:
https://github.com/fangq/jsonlab/blob/master/README.rst#acknowledgement


----------------------------------------------------------------------------
> The octave image toolbox is currently "self contained" in the sense that it
does not require to install any formal dependencies beforehand. So all code
that your new functions need from the mentioned toolboxes would probably also
need to be included into the Octave image toolbox. This is the reason behind
the next question:
>
> Would we need to include ALL CODE of the above toolboxes?

it depends on to what extend you want to support nifti files - uncompressed or
compressed nifti. If just uncompressed nifti, the only dependency you need is
the jnifti toolbox; if you need to read/write nii.gz/hdr.gz/img.gz files,
which are more popular among users, you will either need to call gunzip to
uncompress the file on the disk, and then read using the jnifti toolbox; but
calling zmat is more convenient as it does not need involving reading/writing
additional files.

as I mentioned above, I started packaging these toolboxes for Fedora, and will
be working next for Debian/Ubuntu. I am happy to adjust the
content/dependencies of my packages to accommodate whatever that you would
like to be included in octave-image, and what you want to leave in separate
packages. I also do not think a small overlap in these toolboxes is a
problem.

----------------------------------------------------------------------------
> Or is some of the functionality already implemented in Octave and can be
used instead? (Octave can already deal with compressed files I think. Is this
functionality not good enough for your intended use?)

as mentioned above, you can call gzip/gunzip to compress/uncompress the files
before processing, but it is not as convenient as zmat and requires disk-write
permission to proceed.

----------------------------------------------------------------------------
> Are some functions of those toolboxes NOT used by your nitfi functions and
could therefore be omitted from the inclusion into the Octave image package?

if you want to keep the number of units as little as possible, you may remove
jnifticreate.m, loadjnifti.m, savejnifti.m, savejnii.m and savebnii.m. These
are for processing JSON-represented nifti (i.e. jnifti) data files. I need to
run a test and see if removing these will cause any issues.

----------------------------------------------------------------------------
> Another idea: In the case that (a) also those libraries are your own code
and (b) they can be licensed with GPL and (c) they add functionality regarding
compression and/or json functionality to Octave that isn't there yes, it might
be worth discussing with "core Octave" about including these parts of your
code there. But in this case those libraries should probably mimic Matlab
compatible behavior (e.g. Matlab's jsondecode.m ...). This might be more than
you intended to do.

I know someone is working on jsonencode/jsondecode using C based parsers. I
left some comments in the below thread

https://savannah.gnu.org/bugs/?53100

----------------------------------------------------------------------------
> In some toolboxes there seem to be pre-compiled functions (I have seen
zipmat.mex for exmaple). Are those files 
> also available as C source code (under GPL)? Are they coded in a way that
Octave can compile them on its own?

yes. also see my packages for Fedora - including the mex file (*octave-mex*),
and the library (*zmat, zmat-devel, zmat-static*). You may use it easily to
create an oct based unit.

----------------------------------------------------------------------------
> In general there is a coding style for "core Octave", regarding C-code and
m-code as well. It can be found here:
> https://wiki.octave.org/Octave_style_guide
> https://wiki.octave.org/C%2B%2B_style_guide


in the current version, my code was not specifically formatted for Octave,
because these toolboxes I created were shared for both MATLAB and Octave. I am
happy to reformat if this is required/necessary, but I generally do not prefer
to maintain two versions.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/patch/?9853>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/