[ome-devel] CLI render - and a philosophic question re: rendering settings

[Josh Moore]

On Thu, Aug 10, 2017 at 11:49 PM, Damir Sudar <dsudar at lbl.gov> wrote:
> Hi Josh and whoever is interested,

Happy Friday, all.


> I'm finally gearing up to upgrade to 5.3.3 for all its great new
> capabilities and was trying some stuff on my 5.3.3 test server. One of those
> was the render.py script that, per below, wasn't really usable in vanilla
> 5.2.x. Unfortunately I get the exact same exceptions with 5.3.3

i.e. you're getting the "getWindowMin" error when running `info` and
"no attribute '_closeRE" on `copy`?


> so I guess I should wait for 5.4?

I don't know of any of these issues having been fixed in 5.4, so not
particularly.


Or is the situation with 5.3 more solvable?

Perhaps, but I don't think so.


> 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*?


> 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.


> One thought to be able to display the larger dynamic range needed for the
> above (and which is not really possible with the current linear scaling
> between min and max values), is the idea of supporting non-linear colormaps
> for the rendering. I saw some mentions of a CodomainMap in the
> RenderingEngine docs. Would that be a future way to support non-linear scale
> transforms such as gamma curves and such?

I'll leave that for Dr. Burel on his return.


> Cheers,
> - Damir

~Josh

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

There's no inherent reason a script should be slower that the CLI. Do
you have specifics?


> 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
>>> 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
>>>
>>> omero render edit --help
>>> omero render edit --copy Plate:1 renderdef.yml
>>> omero render copy Image:SrcID Plate:TargetID