Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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.
    Robert Haase
    @haesleinhuepf
    This is the only place in the code where BioFormats is used... I just introduced the bioformat dependency to make the Tiff-writing work
    Curtis Rueden
    @ctrueden
    What is your runtime environment? Main method in IDE? Fiji? Something else?
    Robert Haase
    @haesleinhuepf
    It happens in IntellliJ and on gradle test
    Curtis Rueden
    @ctrueden
    Bio-Formats uses a logging framework. See https://imagej.net/Logging
    Is there another dependency with a logback or log4j configuration file embedded in it?
    Robert Haase
    @haesleinhuepf
    There is no other dependency. If I comment out Bioformats in my build.gradle, the log4j dependency disappears from my dependency tree
    Curtis Rueden
    @ctrueden
    There could still be a config file somewhere. It's just a resource on the classpath.
    If you find a way to debug logback/log4j config, that would be a great addition to the Logging page.
    Robert Haase
    @haesleinhuepf
    how could be the log4j config file name?
    Curtis Rueden
    @ctrueden
    There are lots. I would mvn dependency:copy-dependencies && for f in target/dependency/*.jar; do jar tf "$ f" | grep log; done to see what shows up.
    $f argh mobile autocorrect.
    Robert Haase
    @haesleinhuepf
    While debugging, I just found out, that the log4j internal log level is null...
    Curtis Rueden
    @ctrueden
    I have noticed debug mode mysteriously turn on in other situations too and never made time to track down why. So keep us posted on any findings please!
    Robert Haase
    @haesleinhuepf
    Ok, I'll continue tracing and let you know! But thanks so far! :)
    Muad Abd El Hay
    @Cumol
    What does the conversion speed of bfconvert (form the tools) depend on? I have long time series (18k images) that need to be combined and converted to .tiff. Right now it is taking 45 minutes per dataset. Is something going wrong?
    Jan Eglinger
    @imagejan
    @Cumol this forum thread about slow tiff writing might be related
    Muad Abd El Hay
    @Cumol
    Thanks for the link @imagejan. Seems like an open issue. I wonder if it was introduced with the last update
    Niko Ehrenfeuchter
    @ehrenfeu
    @Cumol the conversion speed depends (at least in my experience) heavily on the I/O speed of the storage. So if your input and / or output files are e.g. on a network share, it will be orders of magnitude slower than on local disks for example...
    Muad Abd El Hay
    @Cumol

    @ehrenfeu Ah, that explains a lot. It is probably faster to convert locally and then move to a network share.

    I wonder thought why ImageJ seems to be doing just find with the task. Loading the images as virtual stack and then writing them as .tiff

    Niko Ehrenfeuchter
    @ehrenfeu
    Virtual stack is not loading the entire dataset upfront, but only during processing. If you plainly "save" as TIFF in ImageJ (as opposed to using the Bioformats exporter) it is saving as a normal TIFF (without all the benefits of OME-TIFF) which is a lot faster but at the cost of losing metadata.
    Muad Abd El Hay
    @Cumol
    In which situations do I need the metadata?
    Niko Ehrenfeuchter
    @ehrenfeu
    I would rather turn that question around - in what situations is it acceptable to discard the metadata?
    Muad Abd El Hay
    @Cumol

    The original metadata are in the raw files, so they can always be read. But for downstream manipulation/analysis (in my case converting to tiff, merging into one file, converting that into hdf5 and then using an analysis pipeline that has troubles dealing with TIFF files that include metadata).

    What is the added value to have the metadata in the .tiff or hdf5 file?

    Maybe I do not understand what kind of metadata is stored in a .ome.tiff file. Do you have a link that explains the importance of them?

    Niko Ehrenfeuchter
    @ehrenfeu
    Well, if your downstream processing involves multiple conversion steps (which sometimes can't be avoided, I know...), you'll most likely reduce the preserved Metadata anyway in one of them. As you are aware that it is important to keep your raw data, that seems okay to me. I would check if the conversion results at least preserve the spatial calibration (pixel size etc) to make sure that size measurements will be correct.
    About the details of the Metadata in OME-TIFF, maybe someone from the openmicroscopy staff would be able to provide a good link with explanations...?