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

WaveorderReader ome-zarr contrast limits #52

Closed
ieivanov opened this issue Dec 28, 2021 · 3 comments
Closed

WaveorderReader ome-zarr contrast limits #52

ieivanov opened this issue Dec 28, 2021 · 3 comments
Assignees

Comments

@ieivanov
Copy link
Contributor

  • Contrast limits provided to init_array should be in format of either (end, max, min, start) or (start, end)
  • Document how contrast limits should be formatted. It would be more intuitive to format the len=4 tuple as (min, max, start, end)
  • Right now create_channel_dict assumed that the data is float32 and sets max to 65535. It would be good to match that to the data type such that, for example, the default value for uint8 data would be 256
@camFoltz camFoltz self-assigned this Jan 5, 2022
@camFoltz
Copy link
Contributor

camFoltz commented Jan 6, 2022

I think I like the user to define the (start, end) tuple and then the writer will automatically infer the min/max based on the datatype. Do you see a need to specify the min/max yourself? I suppose this could come into play when dealing with float data.

Perhaps another option would be to add an optional min/max tuple argument?

@ieivanov
Copy link
Contributor Author

ieivanov commented Jan 7, 2022

I sometimes deal with 12-bit data that is saved as uint16. In that case it may be hard to infer that the data is 12-bit just from the .tif stack. You're also right that this can get tricky when dealing with float32 data. I think formatting that tuple as either (start, end) or (start, end, min, max) should work. If the tuple is len=2 then we can infer min/max based on the data range

@camFoltz
Copy link
Contributor

camFoltz commented Jan 7, 2022

Cool I agree -- that's what I ended up implementing in #60

@camFoltz camFoltz closed this as completed Jan 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants