Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## [Ltilib-devel] On the YUV color space (spaces) and their LTI-Lib classes.

 [Ltilib-devel] On the YUV color space (spaces) and their LTI-Lib classes. From: Pablo Alvarado Moya - 2007-01-05 19:42:55 ```Hello Everybody, in my improvements for the FireWire functor I encounter some problems with = the=20 split and merge functors for the YUV color space. The repository has now=20 several changes that I have to explain to avoid problems to those, who use= =20 this class. The term "YUV" is applied to several color spaces, which causes some=20 confusion. Now, the LTI-Lib uses the definitions provided in Poynton's Col= or=20 =46AQ (http://www.poynton.com/PDFs/ColorFAQ.pdf). Usually, when we want to decode the stream obtained by digital cameras, the= =20 color space YCbCr is employed, even if it is called "YUV" (YUV4:2:2 or=20 similar). This color space does not use the full 8bit range, because the=20 excursion of the values are from 16 to 235 for Y, and from 16 to 240 for th= e=20 other channels. If the data stream of your camera do use the whole range=20 from 0 to 255 then it is highly probable that it is using the YPbPr color=20 space. The "real" YUV is quite similar to the YPbPr color space but is mea= nt=20 for values between of Y in [0,1] and U in [-0.436,0.436] and Y in=20 [-0.615,0.615]. If the values are scaled to be used in 8-bit variables, th= en=20 the linear mapping and offsets necessary provide us with the YPbPr scalings= =20 again. So, if you were using the lti::splitImageToYUV or lti::mergeYUVToImage then= =20 you need to change your software to the correct functor, which would be =20 lti::splitImageToYCbCr or lti::mergeYCbCrToImage. You may also want to che= ck=20 if you camera decoding software uses the correct color space and=20 corresponding functors. By the way, the functors were improved in speed and accuracy: the float=20 version permit an errorless RGB->Yuv->RGB conversion, while the ubyte=20 implementations provide the smallest posible error considering that this=20 precision makes it impossible to perfectly reconstruct all 2^24 RGB colors. Regards, Pablo =2D-=20 Dr. Pablo Alvarado E-Mail: palvarado@... Escuela de Ingenier=EDa Electr=F3nica Tel.: (+506) 550 2106 Instituto Tecnol=F3gico de Costa Rica Fax.: (+506) 591 6629 Apartado Postal 159-7050 Cartago Costa Rica ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ```

 [Ltilib-devel] On the YUV color space (spaces) and their LTI-Lib classes. From: Pablo Alvarado Moya - 2007-01-05 19:42:55 ```Hello Everybody, in my improvements for the FireWire functor I encounter some problems with = the=20 split and merge functors for the YUV color space. The repository has now=20 several changes that I have to explain to avoid problems to those, who use= =20 this class. The term "YUV" is applied to several color spaces, which causes some=20 confusion. Now, the LTI-Lib uses the definitions provided in Poynton's Col= or=20 =46AQ (http://www.poynton.com/PDFs/ColorFAQ.pdf). Usually, when we want to decode the stream obtained by digital cameras, the= =20 color space YCbCr is employed, even if it is called "YUV" (YUV4:2:2 or=20 similar). This color space does not use the full 8bit range, because the=20 excursion of the values are from 16 to 235 for Y, and from 16 to 240 for th= e=20 other channels. If the data stream of your camera do use the whole range=20 from 0 to 255 then it is highly probable that it is using the YPbPr color=20 space. The "real" YUV is quite similar to the YPbPr color space but is mea= nt=20 for values between of Y in [0,1] and U in [-0.436,0.436] and Y in=20 [-0.615,0.615]. If the values are scaled to be used in 8-bit variables, th= en=20 the linear mapping and offsets necessary provide us with the YPbPr scalings= =20 again. So, if you were using the lti::splitImageToYUV or lti::mergeYUVToImage then= =20 you need to change your software to the correct functor, which would be =20 lti::splitImageToYCbCr or lti::mergeYCbCrToImage. You may also want to che= ck=20 if you camera decoding software uses the correct color space and=20 corresponding functors. By the way, the functors were improved in speed and accuracy: the float=20 version permit an errorless RGB->Yuv->RGB conversion, while the ubyte=20 implementations provide the smallest posible error considering that this=20 precision makes it impossible to perfectly reconstruct all 2^24 RGB colors. Regards, Pablo =2D-=20 Dr. Pablo Alvarado E-Mail: palvarado@... Escuela de Ingenier=EDa Electr=F3nica Tel.: (+506) 550 2106 Instituto Tecnol=F3gico de Costa Rica Fax.: (+506) 591 6629 Apartado Postal 159-7050 Cartago Costa Rica ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ```