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

The overview uses the smallest available image size and not the best one #497

Open
andreasg123 opened this issue Aug 27, 2021 · 5 comments
Labels
bug Something isn't working

Comments

@andreasg123
Copy link
Contributor

Describe the bug

bioformats2raw produces very small images at the lowest level of the image pyramid. In one sample image (about 70,000 pixels in the larger dimension), the smallest image was 63x136. The overview happened to be twice that large in each dimension. However, it loaded the smallest available image, making the overview look pixelated. Making bioformats2raw produce fewer levels would require determining the image dimensions upfront to specify the number of resolutions, an undesirable option given the many different possible input formats.

Expected behavior

OverviewView._setHeightWidthScale pretty much computes the best zoom level. However, OverviewView.filterViewState uses instead -(this.loader.length - 1) as the zoom level.

Environment:

  • Release or git hash: 0.10.3
  • Browser: Chrome
@andreasg123 andreasg123 added the bug Something isn't working label Aug 27, 2021
@manzt
Copy link
Member

manzt commented Nov 4, 2021

What about exposing this behavior as a parameter, with the suggested change as default behavior? My guess is that most images will be generated with bioformats2raw, but some may not.

@ilan-gold
Copy link
Collaborator

@andreasg123 If you want to see this done, would you be willing to open a PR? It sounds like you understand the problem well (thank you very much for poring over my code). I think you would need to update the underlying layer as well to fetch the right zoom level.

@ilan-gold
Copy link
Collaborator

I could do it, but not for at least another week.

@ilan-gold
Copy link
Collaborator

As for @manzt's comment, I don't feel strongly. Exposing things can create more work in the future due to maintenance or prevent work from needing to be done for exposing the API.

@andreasg123
Copy link
Contributor Author

@ilan-gold, I'll see if I can find time to do this. I don't think that this needs to be a parameter because the behavior that I proposed matches what the detail view does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants