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.

Sign up for GitHub

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

Jump to bottom

First set of NGFF optimizations #83

Merged
merged 11 commits into from
Jun 10, 2021
Merged

First set of NGFF optimizations #83

merged 11 commits into from
Jun 10, 2021

Conversation

chris-allan
Copy link
Member

Optimizations for the NGFF image and thumbnail rendering workflows consisting of:

  • Tracing of the PixelBuffer and resolution description retrieval code paths
  • Optimizing away a large number of Zarr array openings from the resolution description code path

@chris-allan chris-allan requested a review from kkoz June 8, 2021 16:10
@chris-allan
Copy link
Member Author

Currently a work in progress. There will likely be a few more to come.

kkoz
kkoz reviewed Jun 9, 2021
View reviewed changes
Copy link
Member

@kkoz kkoz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really have any objection to the getBytes changes, but I'm not sure they will prevent any copying from taking place. I think once we call array.read(...) the data is put in memory and then is just passed around.

src/main/java/com/glencoesoftware/omero/ms/image/region/ZarrPixelBuffer.java
int sizeX = pixels.getSizeX();
int sizeY = pixels.getSizeY();
for (int i = 0; i < resolutionLevels; i++) {
double scale = Math.pow(2, i);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the resolution levels always successive powers of 2 from each other?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, at least as far as we use them. It's not explicitly defined but should be in the future:

@chris-allan
Copy link
Member Author

Depending on the exact implementation I was concerned about ByteBuffer#array(). In our use currently I don't think it's a problem and where I'd definitely like to go with all of this is to use preallocated arrays and ZarrArray.read(Object, int[], int[] where we are passing in a preallocated array but that's probably for 002. ;)

@chris-allan chris-allan merged commit 344a4dd into glencoesoftware:master Jun 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kkoz kkoz kkoz left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@chris-allan @kkoz