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