[pixeldata] Apply VOI LUT when rendering images

[abustany]

Fixes: #232

Tested on couple of images locally, this seems to do the job.

There are couple of items I'd like to address before considering this one ready:

• add couple of unit tests
• get your feedback @Enet4 on whether the data structures like VoiLut are in the right place...
• maybe fix the naming, somehow "VOI LUT" can refer to lot of similar but different things 😬 This seems to be an issue with the standard already, but any feedback on how to make names clearer is welcome
• do we want to make the API public already? Else we could gate the new structs behind pub(crate) for now

[abustany]

woops didn't realize I had broken the gdcm feature, will fix

[feliwir]

I think this will conflict with #598 i just created earlier today

[Enet4]

This does look substantial, thank you for working on this!

• add couple of unit tests

That would be greatly appreciated. I wonder if some of the DICOM test files available feature VOI LUT sequences. I also happen to have a test enhanced CT scan which I think features a VOI LUT sequence, but I need to check.

• get your feedback @Enet4 on whether the data structures like VoiLut are in the right place...
  maybe fix the naming, somehow "VOI LUT" can refer to lot of similar but different things 😬 This seems to be an issue with the standard already, but any feedback on how to make names clearer is welcome

From the quick glance I found nothing egregiously wrong, but I will make a better review when I am able.

• do we want to make the API public already? Else we could gate the new structs behind pub(crate) for now

In this case there is already some value in the library picking up VOI LUT sequences when the object uses that instead of window levels, so we can start with crate-level visibility and expose it later.

[Enet4]

I think this will conflict with #598 i just created earlier today

If it helps create some coordination, we can decide an order of contribution merges so that we know which one should be rebased.

[abustany]

I think this will conflict with #598 i just created earlier today

yup, very likely :-D but I'm happy for you to merge first, I checked your PR and the conflict resolving shouldn't be too hard to do.

[Enet4]

Thank you again for working on this. I will only leave a few comments inline. Overall this seems to be heading in the right direction. Please let me know when the pull request is ready for a more thorough test.

[abustany]

Thanks for the comments! I'll try to take a look next week. I unfortunately haven't found the time yet to finalize the tests - but that's still on my todo 😬

[Enet4]

Hello again! Feel free to let me know if you need assistance reviving this pull request, or if you would like someone else to take over.

[abustany]

Hello! Sorry about not picking that up - it’s the typical situation where we’ve been using this in production without issues for a while, so the urgency of properly wrapping up the PR went down… And free time has somehow been scarce. Anyway, I’m totally happy with someone else taking over this PR, this is public code really :) If that helps upstreaming the code faster, then everybody wins. Else I still have it on my backlog.

[Enet4]

I took the liberty of rebasing and applying my recommendations, but then I found something curious. Would appreciate your insight.

[abustany]

I took the liberty of rebasing and applying my recommendations

that's perfect, thanks a lot!