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