-
Notifications
You must be signed in to change notification settings - Fork 43
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 tile source _dtype attribute #1144
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be nice to have; curious what's motivating this?
When we show controls for picking the minimum and maximum values for a band, it would be nice to be intelligent about what values are allowed. uint8 data should be limited to [0,255]; uint16 to [0,65535], float should suggest from [0,1]. We can glean this information from the histogram data, but that is expensive to compute. |
Ah, makes sense! One request, can we put this in the metadata? |
Co-authored-by: Bane Sullivan <bane.sullivan@kitware.com>
Yes. That is one of the goals. |
Not sure how this is implemented; is the _dtype computed during the initial file import, or is this done lazily so it's computed the first time the tileInfo is requested, and then cached? Depending on performance, may also want to have a maintenance function that could pre-compute this at a folder / item level to prevent the user having to wait for this the first time an image is loaded. |
large_image/tilesource/base.py
Outdated
@@ -1638,6 +1661,9 @@ def getMetadata(self): | |||
'magnification': mag['magnification'], | |||
'mm_x': mag['mm_x'], | |||
'mm_y': mag['mm_y'], | |||
# Use private attribute; public property | |||
# incurs calcuation cost if _dtype is still None | |||
'dtype': self._dtype, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should measure just what the time impact is on our test set (that is, on all the files in the externaldata and test/test_files locations) and decide if the performance hit is significant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For local files, I suspect the performance hit will be marginal. I'm concerned about the performance hit for remote files with GDAL-based sources when going through the virtual filesystem mechanisms -- and especially so if the image isn't cloud optimized as then getMetadata()
could require downloading the entire image
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've started a timing test result sheet here: https://docs.google.com/spreadsheets/d/1gY-VMdph4RxI5dsw1i0y5SSaZ8oaAJ0lZZ_Fi97gd9g/edit?usp=sharing (kitware access only)
The dummy tile source doesn't have a _classkey or report level information. Work anyway.
The CI is still failing because the DummyTileSource doesn't have a |
No description provided.