All good plans. (I'm not sure about using 65536 bins for 16-bit images, 
though, because that would be more bins than there are pixels in some images. 
Still, it's not all that much memory, really, so maybe that would be OK.)

It would be great to add native support. Presumably you've found the docs on 
adding support for new formats.

For formats that encode large datasets in a single block (like NRRD), you can 
work with GB-sized datasets on a laptop because you can use mmap (I do it 
routinely). But the love of TIFF does demand an alternative solution. 
Presumably we should add a lower-level routine that returns a structure that 
facilitates later access, e.g.,
    imds = imdataset("my_image_file")
    img = imds["z", 14, "t", 7]
or somesuch.

--Tim

On Sunday, November 09, 2014 07:38:27 PM Aneesh Sathe wrote:
> Tim,
> i would like the imhist to be idiot proof. (i've been teaching matlab and
> nothing puts new people off more than things not being idiot proof).
> things like using 256 bins by default.... returning a plot  if no outputs
> are specified (basically make it like matlab's imthresh() )
> 
> Btw, on matlab using bioformats is actually the slowest part of my
> algorithm, so unless it can be faster in julia native support might be
> nicer. Bioformats also fails in that it reads the whole sequence at once...
> so running things on laptops with even GB-level datasets is impossible. I
> wrote my own version of bfopen to only open the required XYZCT for
> specified series, but that only solves the memory usage.
> 
> the source format for my image was .mvd2 (perkin elmer spinning disk).
> 
> i know about JavaCall.jl just havent had the time to play with it...
> 
> i was thinking it might be fun to attempt native support for a few formats.
> I can also generate test data in a few vendor formats for a few
> microscopes.
> perhaps even make it a julia-box based project. ;)
> 
> On Monday, November 10, 2014 4:49:22 AM UTC+8, Tim Holy wrote:
> > On Sunday, November 09, 2014 11:39:53 AM Aneesh Sathe wrote:
> > > Yes, Images does read it okay but only if i cut out the substack. If i
> > > don't, then it interprets the three channels as a time dimension, which
> > > isnt a pain at the moment but will be if i start using it for work.
> > 
> > Hmm, that sounds like an annotation problem.
> > 
> > > I realized that both the convert and the g[:] would slow me down but the
> > > hist function just wouldn't work without that kind of dance. Also,
> > > graythresh (http://www.mathworks.com/help/images/ref/graythresh.html)
> > 
> > uses
> > 
> > > reshape to make it all one image which might also add to speed.
> > > 
> > > The pull request is well and good but personally i would rather have a
> > > dedicated image histogram function like
> > > imhist: http://www.mathworks.com/help/images/ref/imhist.html
> > > which would give histograms based on input images. To me that's the only
> > > way to make life easier. ....maybe i'll write one :)
> > 
> > imhist is necessary in matlab largely because hist works columnwise; in a
> > sense, Julia's `hist` is like imhist. Is there some specific functionality
> > you're interested in? There's no reason Images can't provide a custom
> > version
> > of `hist`.
> > 
> > > Something about Images: do you think it possible to use the bio formats'
> > > .jar file to import images from a microscope format to Images?
> > > Opening a microscope format image file in the relevant software and then
> > > exporting it as tiff takes too long and i'd rather be able to access the
> > > images directly.
> > 
> > Yes, expansion of Images' I/O capabilities would be great. I've wondered
> > about
> > Bio-Formats myself, but not had a direct need, nor do I know Java (but see
> > JavaCall.jl, if you haven't already).
> > 
> > The other way to go, of course, is Julia native support. Our support for
> > NRRD
> > is a reasonable model of this approach. However, the reason we use
> > ImageMagick
> > is because the reality is that there are a lot of formats out there; Bio-
> > Formats would fill a similar need for vendor-specific file formats. Out of
> > curiousity, what's the original format you're using?
> > 
> > --Tim

Reply via email to