Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Curtis Rueden
    @ctrueden
    You need to ask the reader for the bits per pixel, type, etc., unfortunately. But it is doable.
    wongmac
    @wongmac
    does the make2DDataArray function given by the DataTools class allow me to retrieve the RGB values somehow? (what data type is stored inside of the array) and how can I retrieve the rgb or hsi values from the byte array returned by open bytes? (Sorry for the noob questions, I'm extremely new to this, and have never worked with complex image types)
    Curtis Rueden
    @ctrueden
    It's been a long time since I have looked at that code, but my guess is it will come back as packed RGBA ints. Or else three separate byte channels. You can check via instanceof.
    Maybe someone else can clarify further; sleepy time for me.
    David Gault
    @dgault
    Hi, just following up on the suggestions that Curtis had made, if you are using the make2DDataArray function then you will receive back a 2d array. The function requires the following parameters: makeDataArray2D(byte[] b, int bpp, boolean fp, boolean little, int height)
    bpp is the bytes per pixel, fp is a boolean representing if the data is floating point or not. The return type of values in the array received back is based on these 2 values
    If the bytes per pixel == 1 then your return array will be a byte[][]
    If the bytes per pixel == 2 then your return array will be a short[][]
    If the bytes per pixel == 4 and floating point then your return array will be a double[][]
    If the bytes per pixel == 4 and not floating point then your return array will be a int[][]
    If the bytes per pixel == 8 and floating point then your return array will be a float[][]
    If the bytes per pixel == 8 and not floating point then your return array will be a long[][]
    You can read these values from the reader using the following :
    boolean floatingPoint = (pixelType == FormatTools.FLOAT || pixelType == FormatTools.DOUBLE);
    int bytesPerPixel = FormatTools.getBytesPerPixel(pixelType);
    David Gault
    @dgault
    If your data is split in separate RGB channels (which can be read with int channels = r.getSizeC();) then you will still receive back a single 2d array. The array however will be of size [channels * width] [height]
    A simple example of this might be:
    SVSReader r = new SVSReader();
    r.setId("/path/to/myfile.svs");
    
    int pixelType = r.getPixelType();
    boolean floatingPoint = (pixelType == FormatTools.FLOAT || pixelType == FormatTools.DOUBLE);
    int bytesPerPixel = FormatTools.getBytesPerPixel(pixelType);
    boolean litteEndian = r.isLittleEndian();
    
    for (int s=0; s<r.getSeriesCount(); s++) {
      r.setSeries(s);
      int width = r.getSizeX();
      int height = r.getSizeY();
      int z = r.getSizeZ();
      int timePoints = r.getSizeT();
      int channels = r.getSizeC();
      for (int i=0; i<r.getImageCount(); i++) {
        byte[] plane = r.openBytes(i);
        Object pixelData = DataTools.makeDataArray2D(plane, bytesPerPixel, floatingPoint, litteEndian, height);
        byte[][] pixels = (byte[][]) pixelData;
        for (int c =0; c < channels; c++) {
          for (int x =0; x < width; x++) {
            for (int y =0; y < height; y++) {
              System.out.println("Pixel Value at channel:" + c +" coordinates x: " + x + " y: " + y + " is: " + pixels[(c*x)+x][y]);
            }
          }
        }
      }
    }
    r.close();
    Note in the example above I am casting to byte[][] but the type of your array may differ based on the bytes per pixel etc as mentioned above
    Curtis Rueden
    @ctrueden
    @dgault The other potential complication, which I believe @wongmac might be hitting, is the case where getSizeC > getEffectiveC. This will be the case for RGB data for example, unless ChannelSeparator is used. It is maybe the case that makeDataArray2D does not actually support this situation.
    @wongmac The quick solution is to use ChannelSeparator.
    (Caveat emptor: this is all from memory so note that my knowledge may now be out of date or wrong.)
    David Gault
    @dgault
    In which case the ChannelSeperator can be used as a Reader Wrapper to automatically handle the splitting of the channels. To use the ChannelSeperator you can simply wrap your reader with it and then use it as you would the original reader
    reader = new ChannelSeparator(reader);
    Christian Dietz
    @dietzc
    hi @/all. Quick question: shouldn't the public static methods in DataTools https://github.com/openmicroscopy/bioformats/blob/develop/components/formats-common/src/loci/common/DataTools.java be synchronized? because for example https://github.com/openmicroscopy/bioformats/blob/develop/components/formats-gpl/src/loci/formats/in/ZeissCZIReader.java#L2499 accesses these DataTools for parsing the String. However, if you have multiple CZIReaders open in multiple threads, this causes race conditions as DecimalFormat.parse(...) and all other NumberFormat things in java are not thread-safe.
    Curtis Rueden
    @ctrueden
    I would suggest making the nf field into a ThreadLocal. Should be more performant than synchronizing, yeah?
    Christian Dietz
    @dietzc
    yep
    Christian Dietz
    @dietzc
    I think the problem comes with openmicroscopy/bioformats@87730bd
    Sébastien Besson
    @sbesson
    @dietzc: many thanks for catching up these issues, could you raise it either as a Bio-Formats issue, a forum thread or an email to ome-devel?
    Christian Dietz
    @dietzc
    It seems I've chosen the worst channel to communicate this issue :-P I'll open an issue
    is openmicroscopy/bioformats#2551 enough?
    Sébastien Besson
    @sbesson
    great thanks
    Christian Dietz
    @dietzc
    thanks for taking care! Any idea when this will be fixed (minor bug-fix release probably?). Our regression tests are a bit sad at the moment ;-)
    Sébastien Besson
    @sbesson
    we'll have a look tomorrow, ideally in the upcoming bug-fix release due in 2 weeks
    Christian Dietz
    @dietzc
    alright. thanks!
    Curtis Rueden
    @ctrueden
    Has anyone seen a regression in the Bio-Formats ImageJ plugin which causes images not to be disposed after the frame is closed? I am investigating this forum post and trying to determine whether Bio-Formats is the culprit.
    I will do some tests now, but if anyone here already knows that BF has a bug like this, that would save me time.
    Curtis Rueden
    @ctrueden
    The problem only happens with Oracle Java (7 or 8), not Apple Java (6). It happens with any version of Bio-Formats (tested with 5.1.0, 5.1.11, 5.2.0). It happens with old versions of ImageJ (Life-Line from 2014) as well as new ones (latest Fiji distro).
    So at first glance, it seems like yet another Oracle Java bug on OS X. However, the bug only manifests with images opened by Bio-Formats, not opened by ImageJ 1.x core (tested File > Open on single file, as well as File > Import > Image Sequence).
    I will follow up on the forum thread now. If anyone here has insight, please chime in there.
    Sébastien Besson
    @sbesson
    @ctrueden thanks for the heads up, we are definitely watching the Image forum and will use the thread if we have relevant information
    Curtis Rueden
    @ctrueden
    @sbesson et. al: FYI, it seems like macOS Sierra fixes the above memory leak. I tried to comment on the Trello card but could not figure out how to do so.
    Tangentially: has the OME team seen Codetree? It gives you Kanban but built on top of GitHub issues. And lets you aggregate multiple repos into single projects. Might be an ideal fit for OME, and would allow the team to move dev discussion back into the public sphere, instead of walled behind Trello.
    Curtis Rueden
    @ctrueden
    The LOCI Bio-Formats page links to the old OME FAQ sections, all of which are now status "private". When you visit those links as anonymous user, it redirects to a login page. Is there some new FAQ page I should update these links to point at? I didn't see anything immediately in the current site's menus.
    For now I just removed all those links. Seems a shame though.
    H Flynn
    @hflynn
    @ctrueden The FAQ pages were legacy from when the documentation was much sparser. They were removed nearly 2 years ago to reduce the maintenance burden - all the relevant info is in the documentation now.
    Curtis Rueden
    @ctrueden
    FYI, the BoneJ2 developer @rimadoma has ported the BoneJ support for Scanco ISQ to SCIFIO (scifio/scifio#337). However, this poses a question about licensing of PFF reader implementations in SCIFIO. Just wanted to draw your attention to the discussion: https://github.com/scifio/scifio/pull/337#issuecomment-274087843
    Robert Haase
    @haesleinhuepf
    Hey guys, I'm using BioFormats to save TIF files and it works like a charm! However, there are hundreds of messages coming out to the command line like "21:29:32.546 [main] DEBUG loci.formats.tiff.TiffSaver - Writing tile/strip 35/100 size: 227 offset: 770691". Is there a way to turn this logging of (something like LOGGER.setDebug(off)))? Thanks!
    Curtis Rueden
    @ctrueden
    @haesleinhuepf How are you saving them? CLI tool? Something else?
    Robert Haase
    @haesleinhuepf
    Curtis Rueden
    @ctrueden
    The best way to disable those log messages is, in my experience, to figure out how they got turned on in the first place. And NOT to make some hardcoded API call.