Why are there 3 statically-compiled quantums?

[BlueCyro]

The title says it all - why are there 3 versions? Ideally if I've got a mixed workload (that is, both high and low depth images), logically I would think that making a decision about how much memory to use would be dependent on the type of image I'm encoding or decoding. But instead, it appears that the high-depth builds will statically use a set size of datatype regardless of if the image being decoded is high or low bit depth.

Why is this? I'm genuinely curious as to why it appears you must subscribe to decode an image using a statically-defined depth, rather than choosing how much depth you need at runtime. Perhaps I sound entitled, but I find this rather inconvenient for applications where you may need to occasionally encode or decode high bit-depth image types, but otherwise can work using less memory on lower-depth ones. Surely I must be missing something obvious here.

[dlemstra]

This is done because that is how the underlying library ImageMagick works. This is native code and has three different builds for the different depths. It might be possible to use this side by side but I have never tested that.

[BlueCyro]

Deciding at runtime what depth you actually need I feel would be very beneficial for mixed workloads. Specifically in the case where you may be processing lots of low-depth images, but need the capability to use more memory for processing higher-depth ones.

Being able to dynamically scale the amount of resources required I think would open this up from being a specialized tool to far more ubiquitous use-cases, much like other image handling libraries such as FreeImage.

Magick.NET seems really suitable for an underlying image processing library due to the vast amount of format support and capability it has, but the lack of resource scaling curtails that venture.