A couple of points: - As mentioned by others, NRRD doesn't have performance issues (except likely for very small arrays, due to the overhead of parsing). If you just want a raw dump of memory, you can get that, and if it's big it uses `Mmap.mmap` when it reads the data back in. So you can read terabyte-sized arrays. - in my opinion, NRRD does have a few deficiencies ( https://sourceforge.net/p/teem/bugs/14/), of which the most serious is probably the lack of a real test suite. (I'd guess this is probably the main reason it hasn't taken over the world when it comes to storing images.) But I don't think it would affect how you would use it for storing `Complex{Float32}`s or whatever. - the `images-next` branch is the current state-of-the-art in julia's support for NRRD: it's almost a complete rewrite from previous versions, as part of https://github.com/timholy/Images.jl/issues/542. Aside from being better-designed and having better support for the standard, it no longer does any reinterpretation of data unless the metadata are such that it is certain this is what should happen.
That said, I'm not evangelizing its use, just wanting to make sure you understand what NRRD is and isn't. Best, --Tim On Thu, Oct 13, 2016 at 8:05 AM, Páll Haraldsson <pall.haralds...@gmail.com> wrote: > > [Explaining more, and correcting typo..] > > On Sunday, October 9, 2016 at 12:04:35 AM UTC, Páll Haraldsson wrote: > >> FLIF is not a replacement for all uses (multidimensional, would be >> interesting to know if could to be extended to..), but seem to be the best >> option for non-lossy image compression: >> > > Of course, say three dimensional, could be trivially, concatenated FLIF > files/bytestreams of 2D slices. > > But I really meant, could there be a way to compress whole array/"image", > similar to how wavelet (and fft) can be generalized to more dimensions? >
