I was fooling around with this problem a little bit tonight, and noticed
that mean(in_img) is not type stable (or at least inference produces a
Union type for this operation). E.g. in Aneesh's notebook, I ran
@code_typed mean(in_img)
and the result ended with
end::Union(Gray{Float32},Gray{Float64})
On Sunday, November 9, 2014 2:49:22 PM UTC-6, 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
>
>
