Files written by niwrite are corrupted

[yingqiuz]

Hi

When I was using niwrite to save *nii.gz ir *.nii files, they seemed to be corrupted consistently.

The version infos are shown below:

(GMMFusion.jl) pkg> status NIfTI
      Status `/gpfs3/well/win-biobank/users/gbb787/GMMFusion.jl/Project.toml`
  [a3a9e032] NIfTI v0.5.6

julia> VERSION
v"1.6.0"

The command used to work fine, but since last week I always received this error when accessing the files newly written by niread, even if I just read a NIfTI file and saved it immediately (though in REPL it complained about nothing):

julia> data = niread("mask.nii.gz");

julia> niwrite("test.nii.gz", data)

The error I encountered when accessing it suing FSL is Details: Expected 24781212 bytes, got 6195303 bytes from test.nii.gz - could the file be damaged?

Any help would be much appreciated.

[Tokazama]

What kind of image was "mask.nii.gz"? Just ones and zeros, or boolean values?

[yingqiuz]

What kind of image was "mask.nii.gz"? Just ones and zeros, or boolean values?

Ones and zeros. But the files were corrupted whatever the datatype was.

[Tokazama]

But were the ones and zeros Int or Bool. This seems like a problem in counting memory size on file writing but we do something unique with Bool arrays to save memory so what type this is affects where the issue is coming from.

[ofgulban]

I have the same "file corrupted" error for INT16 images. Just reading and writing the nifti file results in this error (NIfTI v0.5.6). It seems that niread somehow changes the header data type to FLOAT32.

[pfuchs]

This error seems to come up with both Int16 as well as Bool volumes on my end. Int32 does not have this issue, and all Floats seem to be fine.

[Tokazama]

Apparently the last PR broke Int16, even though it was specifically aimed at supporting it. What would be really helpful is if we had self contained tests to ensure this sort of thing doesn't happen for specific bit types. If someone could make a PR addressing at least part of this I can make sure to review it so this actually starts getting fixed

[chapmanbe]

I was checking in to see if there has been any progress on the NIfTI writing problem. I wrote a simple script to merge two segmentation labels in NIfTI images generated by ITK-Snap, only to discover, alas, this writing problem.

Julia version: 1.8.5
NIfTI version: v0.5.9

using NIfTI

t1 = niread("test.nii.gz")
println("Successfully read in test image")
niwrite("test2.nii.gz", t1)
println("Successfully wrote out test image")
t2 = niread("test2.nii.gz")
println("Successfully read in image writen by NIfTI.jl")

Successfully read in test image
Successfully wrote out test image
ERROR: LoadError: EOFError: read end of file
Stacktrace:
 [1] unsafe_read(stream::TranscodingStreams.TranscodingStream{CodecZlib.GzipDecompressor, IOStream}, output::Ptr{UInt8}, nbytes::UInt64)
   @ TranscodingStreams ~/.julia/packages/TranscodingStreams/5yQuA/src/stream.jl:378
 [2] unsafe_read
   @ ./io.jl:759 [inlined]
 [3] read!
   @ ./io.jl:777 [inlined]
 [4] read_volume(io::TranscodingStreams.TranscodingStream{CodecZlib.GzipDecompressor, IOStream}, #unused#::Type{Float32}, dim::Tuple{Int64, Int64, Int64}, map::Bool)
   @ NIfTI ~/.julia/packages/NIfTI/BJohD/src/volume.jl:18
 [5] niread(file::String; mmap::Bool, mode::String)
   @ NIfTI ~/.julia/packages/NIfTI/BJohD/src/NIfTI.jl:0
 [6] niread(file::String)
   @ NIfTI ~/.julia/packages/NIfTI/BJohD/src/NIfTI.jl:266
 [7] top-level scope
   @ ~/Code/pushing_against_ignorance_naive/Imaging/test.jl:7
in expression starting at test.jl:7

[Tokazama]

I'm working on it this week.