RGB support #215
Draft
RGB support #215
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Only simple downsapmling implemented, OpenCV types will throw an exception.
|
I think we (with my JAX hat) would find this useful! We have a lot of RGB image data, and having an easy mechanism for the channels to be stored in the same chunk would certainly speed up visualization. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds a
--keep-rgboption, which omitsChannelSeparatorfrom the reader stack and will return RGB planes if that's what is stored in the input data. The reader'sisInterleaved()is used in this case to determine the axis order;isInterleaved() == truemeans that the order will by*YXC. We may want to think about either forcing interleaved across the board if--keep-rgbis used, or adding a sub-option to do that.The case where there are multiple channels each consisting of an RGB plane is not supported with
--keep-rgb. Same for downsampling types that require OpenCV. We could probably add both, just keeping it simpler for now.DimensionOrderinMETADATA.ome.xmlis not altered, so that comes directly from the underlying reader. With--keep-rgband input RGB data, I'd expectSamplesPerPixelon eachChannelto be greater than 1.This is barely tested and has no unit tests yet. Just opening this as a draft now in case I run out of time to do more this week.
Discussed earlier today with @sbesson, cc @kkoz, @muhanadz
#180, glencoesoftware/isyntax2raw#29, and glencoesoftware/raw2ometiff#26 may be related.