Add support for high bit depth multichannel images

[yoursunny]

Fixes #1888 .

Changes proposed in this pull request:

• Add support for high bit depth multichannel images

[aclark4life]

Thanks!

[Yay295]

What's the metadata design for the pixel format and band layout

I proposed one back in #6547 if anyone wants to look at that again.

[aclark4life]

Thanks for the review @wiredfool ! I'm hopeful that between now and October or EOY at the latest we (@yoursunny @radarhere @Yay295 et al.) can develop this into something you'll approve for merging. Adding all four of us as reviewers to confirm acceptance when we get there, most importantly @hugovk and @radarhere will need to sign off on this as they are currently on the "front lines" of Pillow development and we don't want to release something that will make any of our lives harder. My current assumption is that an implementation that satisfies the requirements and does not introduce any or minimal technical debt is possible.

[wiredfool]

What's the metadata design for the pixel format and band layout

There's a brief description in Imaging.h.

Can you put together a markdown summary of what are the crux issues you see for this feature, and your plan/tradeoffs?

You've got a good start, but I'd like to see your understanding of the complexity of the problem and your plan of attack. I'm a little worried that there's a required complexity out there that's not part of the early code that will be a showstopper.

[aclark4life]

You've got a good start, but I'd like to see your understanding of the complexity of the problem and your plan of attack. I'm a little worried that there's a required complexity out there that's not part of the early code that will be a showstopper.

Well said and I'd also encourage other folks tracking this issue to provide such ideas too. The way this gets to production is:

• Implementation is solid and agreed upon and covers all known use cases
• All known use cases are tested prior to release with test data from GIS, VFX and other industries.
• A plan to support the implementation is made prior to release e.g.
  • "convert everything to MB over X number of releases … "

🚀 🚀 🚀

[aclark4life]

Can you put together a markdown summary of what are the crux issues you see for this feature, and your plan/tradeoffs?

@ericvsmith Can you help with this one? We have a description of the requirements and are in need of a better definition of the format requirements and detailed description of how we plan to support those formats. We know @yoursunny is using the existing data structures so maybe that makes the job of describing our implementation in slightly easier 🤔 Thank you for any advice or guidance.

[fdintino]

My hope is that whatever solution tackles #1888 would also support YCbCr(A), and perhaps chroma subsampling. I'm not sure that a single multi-band image mode is compatible with being able to store raw YUV images.

[ericvsmith]

@ericvsmith Can you help with this one? We have a description of the requirements and are in need of a better definition of the format requirements and detailed description of how we plan to support those formats. We know @yoursunny is using the existing data structures so maybe that makes the job of describing our implementation in slightly easier 🤔 Thank you for any advice or guidance.

Sorry, I just noticed this. I'm not going to be able to look at this for a few weeks, but will check when I return.

[aclark4life]

@ericvsmith Also note we now have #8330 to consider, thanks @wiredfool !

[wiredfool]

For clarity -- my PR is just about exposing the existing memory structure as an arrow array, not adding multibyte or replacing storage with arrow.