Problems with creating 10bit version of YCbCr

[vchuravy]

A few of the types are only defined as

  YIQ{T<:FloatingPoint} <: Color{T,3
  YCbCr{T<:FloatingPoint} <: Color{T,3}

Would it be appropriate to change these type bounds to Fractional instead?

The idea is coming from #9 to define:

typealias YCbCr10 YCbCr{Ufixed10}
typealias Gray10 Gray{Ufixed10}

I can create a PR for doing this, but I don't know for which formats this would be appropriate and how to fix the tests.

julia> Pkg.test("ColorTypes")
INFO: Testing ColorTypes
ERROR: LoadError: test failed: ColorTypes.YCbCr{T<:AbstractFloat} == ColorTypes.YCbCr{T<:Union{AbstractFloat,FixedPointNumbers.FixedPoint}}
 in expression: color_type(A) == C
 in default_handler at ./test.jl:30
 in do_test at ./test.jl:53
 [inlined code] from /home/wallnuss/.julia/v0.4/ColorTypes/test/runtests.jl:109
 in anonymous at ./no file:0
while loading /home/wallnuss/.julia/v0.4/ColorTypes/test/runtests.jl, in expression starting on line 106

[timholy]

For anything where the "gamut" (the allowed space of values) fit in the proposed element type, it would definitely be good to broaden the bounds. I didn't take the time to figure out the proper gamut for all the color types; I did look into XYZ, and a few colors can generate XYZ values bigger than 1, so I left it FloatingPoint.

[timholy]

In general ColorTypes hasn't been exporting typealiases thus far, since they are easy to recreate in packages. But we could change that.

[vchuravy]

I think we don't need a lot of different typealiases, what we might need though is something along the way of AbstractYCrCb to allow compact storage formats.

[vchuravy]

So I think adding Fractional makes only sense for YIQ and YCbCr the other have different ranges for their components

[vchuravy]

Other problems I am currently running into is that the correct_gamut and cnvt function in Colors are expecting 8bit values.

[timholy]

Clearly that will have to fixed. Feel free to try whatever fix works for your more general case.

[vchuravy]

Is there currently any encoding of the range of a colour? Currently it seems that those values are hard-coded for conversion.

[timholy]

Yeah, the YIQ and YCbCr types are not "first class," they are just tacked on because I didn't want to completely ditch old methods like rgb2ntsc methods in Images. But I doubt anyone is using them for anything. Feel free to make whatever changes are necessary.

[vchuravy]

Y'CrCb to RGB is a mess: http://www.fourcc.org/fccyvrgb.php

I would propose to only implement conversion for 8, 10 and 12 bit Y'CrCb as defined in [1] and [2]

[1] https://en.wikipedia.org/wiki/Rec._709 [2] https://en.wikipedia.org/wiki/Rec._2020

[timholy]

This might get easier when switching to FixedPoint because then magic numbers like 16 and 128 will presumably assume a more universal FixedPoint values like T(0.0625) and T(0.5), where T <: Fixed.

[timholy]

(After all, that's what those numbers really mean. Integer intensities definitely stink.)

In other words, I give my approval to change YCbCr so that rather than effectively being 8-bit like it is now, we use "normalized" YCbCr. I think that will make your life much easier.

[vchuravy]

For further reference here are the actual parameters from the standards.

https://www.itu.int/rec/R-REC-BT.709-6-201506-I https://www.itu.int/rec/R-REC-BT.2020-1-201406-I

[kimikage]

xref: https://github.com/JuliaGraphics/Colors.jl/issues/453