Unless I understood wrong (which is very possible) the 65536 bins were to cover all possible values a 16bit pixel can take. Though, in the actual graythresh function i will probably use 256 bins by default.
I did find the docs for adding custom formats (https://github.com/timholy/Images.jl/blob/master/doc/extendingIO.md) But perhaps making bio formats .jar file will be better in the long run for few reasons: 1) A lot more formats are covered so implementing that would allow coverage of more formats faster. 2) I understand your reasons for making all images in the Gray range, but i prefer having "real" pixel values. That way its easier to correlate test data with something like Fiji or Matlab. And I don't understand Julia float handling fully but there might be a gain in speed if using non-float values. 3) Bio formats already allows the reading of individual images based on XYZCT so that doesn't need to be rebuilt. Course, the above is the ideal thing to do. I'm still trying to figure out how to use the .jar file, so i might just end up adding the custom format first. Let's see... -Aneesh On Monday, November 10, 2014 6:55:08 PM UTC+8, Tim Holy wrote: > > 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 > >
