Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add no StatsInfo option to importer #3580

Merged
merged 8 commits into from Mar 12, 2015

Conversation

chris-allan
Copy link
Member

This PR adds a --no_stats_info option to OMERO.importer to allow for the disabling of minima and maxima calculation when not present as part of the Bio-Formats reader metadata. This is of particular benefit where the data volume being imported is extremely high (10s of GB) and the person importing the data is aware of the tradeoffs that apply. Under such conditions calculating global minima and maxima can take hours. We have already applied a similar strategy to images of the digital pathology domain.

The significant bits populated as part of the import process are now being used to inform the default dynamic range of the rendering engine if such metadata is available. Furthermore, certain areas of the code that did not populate the bit width when creating a PixelsType have been fixed. At least one area where the pixels type name was being compared incorrectly has also been fixed.

Unit and integration tests cover the semantic implementation outlined here. Functional testing will have to be discussed.

/cc @emilroz

In cases where a vast amount of data is being imported minimum and
maximum (StatsInfo) calculation can be prohibitive.  This commit allows
for disabling this calculation and population if the Bio-Formats reader
does not already have the metadata available to it.
@jburel
Copy link
Member

jburel commented Mar 9, 2015

To import images: use
bin/omero import -- --no_stats_info fileName Thanks @chris-allan for tip

@jburel
Copy link
Member

jburel commented Mar 9, 2015

both insight and web work fine.
Possible to view the image.
Small adjustments required in clients e.g. min/max grey out if no statsinfo
not to be done in this PR

Removing breaking

@jburel jburel removed the breaking label Mar 9, 2015
@jburel jburel mentioned this pull request Mar 9, 2015
@jburel
Copy link
Member

jburel commented Mar 9, 2015

The only case with the --no-stats option, stats info will be created is when a pyramid is generated.
Discussed with @chris-allan,
This is expected and it comes at no cost since we need to go through all the pixels

@sbesson
Copy link
Member

sbesson commented Mar 10, 2015

Tested on a large SPIM dataset with --no_stats_info at import. Import got stuck before min/max calculation while parsing the pixel data to set the Pixels hash. I will try to work from this branch and optionally disable this unnecessary data reading step if the --no_stats_info option is passed.

@sbesson
Copy link
Member

sbesson commented Mar 12, 2015

Thanks @chris-allan. Merging this and I will open a follow-up PR for additional pixel checksum disabling.

sbesson added a commit that referenced this pull request Mar 12, 2015
@sbesson sbesson merged commit 34b0593 into ome:develop Mar 12, 2015
@sbesson
Copy link
Member

sbesson commented Mar 13, 2015

--no-rebase

@mtbc
Copy link
Member

mtbc commented Mar 27, 2015

Is there (or is it worth) a card somewhere for being able to cause calculation of this stuff in the background for already imported images?

@jburel
Copy link
Member

jburel commented Mar 27, 2015

There is no card, the only please at the moment we use the stats info is at the rendering engine level.
Not having the stats info, means that the full pixels range will be used. Then the user will adjust the settings.
Probably not worth a card now, we can review depending on feedback.

@jburel
Copy link
Member

jburel commented Mar 27, 2015

There is no card, the only place at the moment we use the stats info is at the rendering engine level.
Not having the stats info, means that the full pixels range will be used. Then the user will adjust the settings.
Probably not worth a card now, we can review depending on feedback.

@sbesson
Copy link
Member

sbesson commented Mar 27, 2015

@mtbc: this point was partially discussed in ome/omero-documentation#1152 while adding the limitation. I share @jburel's thoughts, we need to drive this only if there is a concrete well-defined need from a particular community.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants