[ome-devel] CLI render - and a philosophic question re: rendering settings
Damir Sudar
dsudar at lbl.gov
Thu Aug 17 21:08:40 BST 2017
Hi Ian,
Thanks, yes that is typically my first value as well. With a few types
of fluorescent signals this doesn't produce good results (e.g. FISH
labeling or other very sparse punctate labeling) so I'm trying to come
up with something that has some intelligence built-in. Currently working
on a way using Josh's example code to get the min and max intensity
values for a large set of images from screens/plates but I'm now
thinking I'll need the actual histograms to provide an input to that
"intelligence".
Cheers,
- Damir
On 8/16/2017 2:07, Munro, Ian wrote:
> I’m afraid I haven’t been following the whole discussion but, in case
> it helps…
> We’ve found that scaling the displayed intensity to something like
> the 99th percentile of actual maximum intensity
> does a reasonable job of producing an “acceptable” image without user
> intevention.
>
> Best Wishes
>
> Ian
>
>
>> On 16 Aug 2017, at 07:47, Damir Sudar <dsudar at lbl.gov
>> <mailto:dsudar at lbl.gov>> wrote:
>>
>> Hi Josh,
>>
>> > Something like https://github.com/ome/scripts/pull/103
>> <https://github.com/ome/scripts/pull/103> (also unmerged)
>>
>> Yes, that's a great starting point, thanks!. That's actually an
>> interesting discussion in there.
>>
>> Cheers,
>> - Damir
>>
>> On Tue, Aug 15, 2017 at 8:16 AM, Josh Moore<josh at glencoesoftware.com
>> <mailto:josh at glencoesoftware.com>>wrote:
>>
>> Hi Damir,
>>
>> On Fri, Aug 11, 2017 at 6:15 PM, Damir Sudar <dsudar at lbl.gov
>> <mailto:dsudar at lbl.gov>> wrote:
>> > Hi Josh,
>> >
>> > On 8/11/2017 8:32, Josh Moore wrote:
>> ...
>> >>> Now the philosophical question: as in IDR, we have a very
>> large image
>> >>> dataset that we are quantitatively analyzing and also want to
>> show
>> >>> visually.
>> >>> This is part of a large project to asses the effects of a set of
>> >>> perturbing
>> >>> agents (perturbagens) on a panel cell lines, where in our
>> case a large
>> >>> panel
>> >>> of different microenvironment components and drugs are used
>> as the
>> >>> perturbagens. During import into OMERO each image gets its
>> rendering
>> >>> settings from the min/max values in the image itself so all
>> images have
>> >>> different settings and the unsuspecting viewer may see all
>> kinds of
>> >>> interesting intensity effects that are mostly fake while real
>> effects may
>> >>> be
>> >>> masked. So I'm looking for a general way to set the rendering
>> settings
>> >>> across the entire experiment to something that allows
>> comparing images
>> >>> but
>> >>> doesn't generate loads of black and over-exposed-looking
>> images. I was
>> >>> thinking that you guys encountered this same issue with many
>> of the IDR
>> >>> datasets so was hoping for some wise thoughts.
>> >>
>> >> We definitely do but per study, and typically we can only
>> define that
>> >> after visual inspection since they are external datasets. You're
>> >> looking to set something *before import*?
>> >
>> >
>> > No, after import makes more sense since one doesn't really know
>> what the
>> > expected min and max values and desired range setting are going
>> to be, just
>> > as you said. We have been playing with ideas such as:
>> > - we could look at the min and max values per channel across a
>> "set" of
>> > wells/plates (tbd what a "set" means) and set the rendering
>> settings to be
>> > at 2% - 98% (or something) of those values. I'd need to write a
>> script to
>> > extract such min/max values for a "set" of plates and then we
>> could test
>> > what those percent values should be for a pleasing result.
>>
>> Something likehttps://github.com/ome/scripts/pull/103
>> <https://github.com/ome/scripts/pull/103>(also unmerged)
>>
>>
>> > - question to answer then is: what is a "set" and we're back to
>> different
>> > rendering settings when you do want to compare images across
>> "sets".
>> > - one option is to let an external query/visualization tool set the
>> > rendering settings. The OMERO webgateway allows you to query
>> the min/max
>> > (via a JSON query) and set the rendering settings via the UR.
>> So that would
>> > rely on an external visualization software do the "right" thing.
>> > Just to give you an idea of the data we're dealing with, check
>> out our
>> > AWS-hosted public server at:
>> >https://omero.lincsclarion.org/webclient/userdata/?experimenter=52
>> <https://omero.lincsclarion.org/webclient/userdata/?experimenter=52>
>> > The front-end portal with query/visualization tools is still
>> being built.
>>
>> Looking forward to it!
>>
>>
>> >>> Anyway, this is why I'm so interested in the render.py
>> utility and thus
>> >>> my hope it will make it to production-level soon.
>> >>
>> >> I don't have a timeline for you on the production status of
>> render.py,
>> >> but what we *would* like to do for 5.4 is make it separately
>> >> installable, so that you can upgrade just render.py as we releases
>> >> fixes without needing to update all of OMERO.
>> >
>> >
>> > That sounds like a great approach.
>>
>> We'll keep you posted.
>>
>>
>> >> P.S. from your Jul 12th email while I was on vacation:
>> >>
>> >>> Meanwhile, I had kludged together a regular OMERO script
>> >>> (HCS_Render_Settings.py) that does a number of the things
>> that the render.py
>> >>> plugin does but much much less elegantly and very slowly.
>> I'll use that for
>> >>> now. That script is on:https://github.com/dsudar/OMEROscripts
>> <https://github.com/dsudar/OMEROscripts>
>> >>
>> >> There's no inherent reason a script should be slower that the
>> CLI. Do
>> >> you have specifics?
>> >
>> >
>> > I think it's mostly that my script is not at all efficiently
>> implemented
>> > where it does repeated calls to objects to first get metadata
>> (such as value
>> > ranges) and then again to set values and probably causes
>> multiple thumbnail
>> > creation calls.
>>
>> Understood. ~J
>>
>>
>>
>> > Cheers,
>> > - Damir
>> >
>> >>> On 7/10/2017 6:45, Josh Moore wrote:
>> >>>>
>> >>>>
>> >>>>> Next I tried a few of the basic commands of the render plugin:
>> >>>>> 1 ---
>> >>>>
>> >>>> ...
>> >>>>>
>> >>>>> File
>> >>>>>
>> "/home/omero_user/OMERO.server/lib/python/omero/plugins/render.py",
>> >>>>> line 117, in init_from_channel
>> >>>>> self.min = channel.getWindowMin()
>> >>>>
>> >>>> ...
>> >>>>>
>> >>>>> omero.UnloadedEntityException: Object unloaded:object #0
>> >>>>
>> >>>> Vanilla 5.2 is not loading the necessary metadata for the
>> plugin to
>> >>>> work. Unfortunately, solving this isn't as simple as copying
>> a new
>> >>>> file into your installation. In fact, I haven't yet found a
>> smoking
>> >>>> gun between the versions.
>> >>>>
>> >>>>
>> >>>>> 2---
>> >>>>> AttributeError: 'ImageI' object has no attribute '_closeRE'
>> >>>>> ---
>> >>>>
>> >>>> Here again, changes from 5.3 are not available in your
>> version, though
>> >>>> at least these I know where they come from.
>> >>>>
>> >>>>
>> >>>>> Rather than trying more of this, I thought to check with
>> you first
>> >>>>> whether
>> >>>>> I'm missing something fundamental.
>> >>>>
>> >>>> 5.3 :) (or the upcoming 5.4)
>> >>>>
>> >>>> Fundamentally, the plugin is not production quality and has
>> only been
>> >>>> used in isolated situations. We certainly intend to get it
>> into the
>> >>>> testing pipeline for 5.4 but that's not likely to uncover
>> what's going
>> >>>> on with 5.2. If you or anyone on your side wants to continue
>> digging,
>> >>>> we're happy to evaluate your changes, but there's a question
>> of how
>> >>>> far you want to go in modifying your local installation.
>> >>>>
>> >>>> Cheers,
>> >>>> ~Josh.
>> >>>>
>> >>>>
>> >>>>
>> >>>>> Thanks,
>> >>>>> - Damir
>> >>>>>
>> >>>>> On 6/2/2017 2:35, Simon Li wrote:
>> >>>>>
>> >>>>> The render plugin (not tested on 5.3):
>> >>>>>
>> >>>>>
>> >>>>>https://github.com/openmicroscopy/openmicroscopy/blob/metadata53/components/tools/OmeroPy/src/omero/plugins/render.py
>> <https://github.com/openmicroscopy/openmicroscopy/blob/metadata53/components/tools/OmeroPy/src/omero/plugins/render.py>
>> >>>>> Try dropping this into OMERO.server/lib/python/omero/plugins/
>> >>>>>
>> >>>>> Example YAML render settings file:
>> >>>>>
>> >>>>>
>> >>>>>https://github.com/IDR/idr-metadata/blob/master/idr0015-UNKNOWN-taraoceans/screenA/idr0015-screenA-renderdef.yml
>> <https://github.com/IDR/idr-metadata/blob/master/idr0015-UNKNOWN-taraoceans/screenA/idr0015-screenA-renderdef.yml>
>> >>>>>
>> >>>>> omero render edit --help
>> >>>>> omero render edit --copy Plate:1 renderdef.yml
>> >>>>> omero render copy Image:SrcID Plate:TargetID
>> >
>> >
>> > --
>> > Damir Sudar - Affiliate Scientist
>> > Lawrence Berkeley Natl Laboratory / MBIB
>> > One Cyclotron Road, MS 977, Berkeley, CA 94720, USA
>> > T:510/486-5346 <tel:510%2F486-5346>- F:510/486-5586
>> <tel:510%2F486-5586>- E:DSudar at lbl.gov <mailto:DSudar at lbl.gov>
>> >http://biosciences.lbl.gov/profiles/damir-sudar-2/
>> <http://biosciences.lbl.gov/profiles/damir-sudar-2/>
>> >
>> > Visiting Scientist, Oregon Health & Science University
>> >
>>
>>
>>
>>
>> --
>> Damir Sudar - Affiliate Staff Scientist
>> Lawrence Berkeley National Laboratory
>> One Cyclotron Road, MS 977, Berkeley, CA 94720, USA
>> T: 510/486-5346 - F: 510/486-5586 - E:DSudar at lbl.gov
>> <mailto:DSudar at lbl.gov>
>>
>> Visiting Scientist, Oregon Health and Science University
>> _______________________________________________
>> ome-devel mailing list
>> ome-devel at lists.openmicroscopy.org.uk
>> <mailto:ome-devel at lists.openmicroscopy.org.uk>
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>
>
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
--
Damir Sudar - Affiliate Scientist
Lawrence Berkeley Natl Laboratory / MBIB
One Cyclotron Road, MS 977, Berkeley, CA 94720, USA
T: 510/486-5346 - F: 510/486-5586 - E: DSudar at lbl.gov
http://biosciences.lbl.gov/profiles/damir-sudar-2/
Visiting Scientist, Oregon Health & Science University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20170817/91e9ad3d/attachment.html>
More information about the ome-devel
mailing list