Add Rgb64FImage and Rgba64FImage

[oberien]

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

[fintelia]

Could you say a bit about what use cases you have for 64-bit floating point images?

[oberien]

I'm fiddling around with astrophotography stacking. I need to perform operations on tens on thousands of images. In that order float imprecision errors start to creep up. To reduce these losses, I'd like to work on f64 images.

[HeroicKatora]

Seems good to me, it doesn't complicate color representation too much and conversion where it was previously possible with f32 should work. LGTM.

[fintelia]

I looked at this a bit more closely. It is already possible to work with 64-bit ImageBuffers either by writing out the full type name or by defining Rgb64FImage and Rgba64FImage aliases yourself.

The main thing this PR adds is a PixelWithColorType implementation and ColorType/DynamicImage variants for dealing with f64 images. Those additions make me somewhat more nervous because they grow the API surface yet might be used rarely/never. (It isn't clear to me they'd even help with your image stacking task to dynamically switch color types at runtime since the types involved should be known statically at compile time)

[HeroicKatora]

The traits FromPrimitive and EncodableLayout aren't implemented on these types, yet. It could just be those for a start and not the ImageCanvas extension. This issue gives other precedent that the pure picture notion is too narrow and types beyond the defaults should be considered.

The concern about DynamicImage sounds valid, though. There's no guarantee that any of the operations we already define for it will compute in f64 themselves which could be confusing. That said, I'd treat these as a normal bug or even lower priority as GPU optimizations are surely worse for accuracy on textures than what we're doing. Being able to represent the values in the buffer is a necessary precursor to correctness here in any case and that at least allows them to be implemented externally. We've had DynamicImage as a non_exhaustive enumeration nd this sounds as good a time to make use of it as any.

[oberien]

Before creating this PR, I did in fact write my own type Rgb64FImage = ImageBuffer<Rgb<f64>, Vec<f64>>. However, some utility functions, helper functions and conversions aren't usable from a third party context due to the sealed traits SealedPixelWithColorType and EncodableLayout. That is why I though it was a good idea to add this directly to the image library.

In my particular use-case I was missing image conversion from RgbImage to Rgb64FImage (loading pngs) and vice versa (saving the result back as a png) and needed to manually implement these conversions.

Regarding adding DynamicImage::ImageRgb64F, in addition to the link regarding tiff files linked by @HeroicKatora, I plan on supporting FITS images in the future, which allow "unsigned 8-bit bytes, 16 and 32-bit signed integers, and 32 and 64-bit single or double precision floating point reals. FITS can also store 16 and 32-bit unsigned integers."

As FITS support is still quite a way in the future, I'd be fine with leaving out DynamicIage::ImageRgba?64F for now if that makes the PR easier to merge.

[fintelia]

Adding an FromPrimitive should unlock ImageBuffer::convert which seems worthwhile. The EncodableLayout is only useful if we also add a corresponding PixelWithColorType implementation (because both are required to unlock ImageBuffer::{save, save_with_format, write_to}).

I view ColorType/DynamicImage as trying to be a small set of color types that are well supported throughout the crate, including both pairwise conversions between all of them and reasonable handling by the all the encoders and decoders.

More unusual color types can be used by interacting with the format specific crates directly, like how the TIFF crate already supports 64-bit float images. If applicable, we can also have decoders/encoders transparently convert images in unsupported color types into ones we do support. (You could argue this is happening with JPEG when YCbCr colors get mapped to RGB.)

In the case of Pillow, I believe that this is the analogous listing of color types.