[FFmpeg-devel] the proper way to handle a special colorspace?

[u-bo1b at 0w.se]

On Sun, Feb 10, 2013 at 07:34:42PM +0000, Paul B Mahol wrote:
> > The colorspace does not seem to be used by other codecs but why not
> > support it properly? It may happen to be useful (e.g. on slow hardware
> > which of course nobody cares nowadays about but you never know).
> >
> > Is it a wrong intention, or otherwise what and where should be changed?
> 
> Colorspaces in libswscale are known standard ones, and not codec
> specific playground.
> 
> Codec specific stuff should be part of codec itself.

Then I'd have to do some hard work to make it both correct and
comparable to libswscale in efficiency. This would mean both extra
effort and code duplication. Why?

Which changes would be needed in the library besides a suitable row in
ff_yuv2rgb_coeffs?

My impression is that everything is there (the format uses the standard
subsampling, just a slightly different matrix for the rgb<->yuv
coefficients).

Would anybody help me and explain how the different RGB<->YUV tables
are reflected in ff_yuv2rgb_coeffs[], i.e. how to produce a new row
given a 3x3 matrix for a "JPEG-like YUV" i.e. without the extra range
compression/expansion? It should not be hard for somebody who is familiar
with this code. This is at the same time an error-prone exercise for
someone who is not.

 From http://multimedia.cx/mirror/cinepak.txt :
 ...
Conversion from the RGB colour space to the Cinepak colour space is
achieved using the following simple matrix multiplication:

   | r |   | 1.0  0.0  2.0 | | y |
   | g | = | 1.0 -0.5 -1.0 | | u |
   | b |   | 1.0  2.0  0.0 | | v |

Taking the inverse of the 3x3 matrix gives us:

   | y |   |  0.2857  0.5714  0.1429 | | r |
   | u | = | -0.1429 -0.2857  0.4286 | | g |
   | v |   |  0.3571 -0.2857 -0.0714 | | b |
 ...

Regards,
Rl