Improper handling of minor RGB pixel formats in saving #162
Description
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.