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
- 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.


On Thu, Oct 13, 2016 at 8:05 AM, Páll Haraldsson <pall.haralds...@gmail.com>

> [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?

Reply via email to