Improper handling of minor RGB pixel formats in saving

[kimikage]

Perhaps some of the following are known problems, but are not shown in the documentation or (broken) tests.

using ColorTypes
using ColorTypes.FixedPointNumbers
using TiffImages

TiffImages.save("rgb_n0f8.tif", fill(RGB{N0f8}(1, 0.4, 0.0), 10, 200)) # ok

TiffImages.save("rgb_n0f16.tif", fill(RGB{N0f16}(1, 0.4, 0.0), 10, 200)) # ok

TiffImages.save("rgb_f32.tif", fill(RGB{Float32}(1, 0.4, 0.0), 10, 200)) # ok 

TiffImages.save("rgb24.tif", fill(RGB24(1, 0.4, 0.0), 10, 200)) # broken

TiffImages.save("argb32.tif", fill(ARGB32(1, 0.4, 0.0, 0.6), 10, 200)) # blueish

TiffImages.save("bgr_n0f8.tif", fill(BGR{N0f8}(1, 0.4, 0.0), 10, 200)) # blueish

TiffImages.save("rgb_q7f8.tif", fill(RGB{Q7f8}(1, 0.4, 0.0), 10, 200)) # broken

struct AlwaysOrange <: AbstractRGB{N0f8} end
ColorTypes.red(::AlwaysOrange) = 1N0f8
ColorTypes.green(::AlwaysOrange) = 0.4N0f8
ColorTypes.blue(::AlwaysOrange) = 0N0f8

TiffImages.save("orange.tif", fill(AlwaysOrange(), 10, 200)) # broken

The AlwaysOrange example is an extreme case, but lazy formats are somewhat of a practical problem. I am working on supporting the RGBE format used in HDR images. RGBE itself is not officially supported by TIFF, but it would be better to store RGBE32{T} as RGB{T}. https://kimikage.github.io/HDRColorTypes.jl/dev/#RGBE32-and-XYZE32

Of course, I don't think it is necessary to support every format. In general, for color types where the specific storage format is unknown, it might be better to convert to a known color type. At least, it is better to show an error or warning before generating a broken file.