Closed scaramallion closed 4 years ago
This would make both Pillow and GDCM unnecessary, provided we add a handler in pydicom
, correct? This would solve a lot of problems...
It would, but I'm struggling to understand what the implications of the GPL v3 license on the -libjpeg
plugin means if we add the handler in pydicom
itself. The internet is full of contradictory opinions.
I think to be extra careful I may need to change it so that the plugins register themselves with pylibjpeg
(via a register_plugin()
function or something like this), rather than the other way around. That way its fine to distribute both pylibjpeg
and anything that uses pylibjpeg.add_handler()
or pylibjpeg.decode()
without worrying about the GPL (unless of course they 'convey' pylibjpeg
together with the -libjpeg
plugin).
In the meantime we could just add pylibjpeg
to the documentation on pixel data handlers.
Also, it would probably create problems too, since we'd no longer be able to say the cause lies elsewhere!
Yeah, I hadn't seen that it is GPL. This means that we cannot replace the other ones... as far as I know, many of the pydicom users are in a commercial environment and cannot use GPL-licensed software. In this case the decoupling as you have done is probably the best idea.
I hope it goes without saying, but let's say it anyway - this is really great work!
I agree with the 'replacing gdcm' comments - both an opportunity and a potential source of problems. I so wish I could contribute something to this project, but realistically, I don't see having any significant time...
I haven't thought through the licensing issues, but the onus is on users to figure out how licensing applies to each package they install and use, although providing them the plugin options as you've outlined can give them options. And perhaps a warning in pydicom documentation would be a good idea, to remind people it is up to them to adhere to licenses for any handlers they use.
-openjpeg
plugin