LibTiff Mailing List

There is also a problem of multiple possibilites for subsampling of Cb
an Cr components
in libtfiff these are controlled by

TIFFSetField(tiff, TIFFTAG_YCBCRSUBSAMPLING, hor, ver);
http://www.awaresystems.be/imaging/tiff/tifftags/ycbcrsubsampling.html

byte order of components depends on this as well


On Sat, Dec 12, 2009 at 19:27, Antonio Scuri <scuri@tecgraf.puc-rio.br>
wrote:
>> So, you can store either RGB, YCbCr, or CMYK data in TIFF files.
>> However, due to the variable conversion algorithms used for converting
>> to/from CMYK or YCbCr, anything other than RGB is probably not likely
>> to work outside of whatever application creates them.  Is that a
>> correct statement?
>
>  No, I said only for CMYK. YCbCr has a very precise conversion for RGB.
>
>
>> Also, if a user employs the automatic conversion process to get from
>> YCbCr to RGB, doesn't the wide variety of possible conversion matrices
>> for this process make the automatic conversion somewhat inconsistent or
>> even incorrect in some cases?
>> Does LibTiff implement the most common
>> conversion matrix (if that's even clearly defined) for this automatic
>> process, or is there some guess at a conversion matrix based on the
>> data itself?
>
>  Both no, for the same reason.
>
>
>> It just seems to me that storing image data in anything other than RGB-
>> based formats is not a good idea for most general usages and should
>> only be employed if the images are used for internal program processing
>> only.  Otherwise, the matrix employed to generate the YCbCr or CMYK
>> format is not known to a reader of the file.
>
>  As Toby explained, CMYK is used for publishing workflows. And the
> conversion is complicated. No it is not commonly used.
>
>  On the other hand YCbCr is widely used. Mostly because you can separate
> luminance and chrominance information, and compress them with different
> approaches. Almost all JPEG files are stored in this way (I mean *.jpg).
>
>  So actually it depends on what your application does. Also depends on
> what file format/compression you choose.
>
> Best,
> Scuri
>
>
>
>
>
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/
>


-- 
Tomislav Muić
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/


AWARE [SYSTEMS]		Imaging expertise for the Delphi developer
		TIFF and LibTiff Mailing List Archive
	LibTiff Mailing List TIFF and LibTiff Mailing List Archive March 2010 Previous Thread Next Thread Previous by Thread Next by Thread Previous by Date Next by Date Contact The TIFF Mailing List Homepage This list is run by Frank Warmerdam Archive maintained by AWare Systems	2010.03.15 08:18 "Re: YCbCr", by Tomislav Muic There is also a problem of multiple possibilites for subsampling of Cb an Cr components in libtfiff these are controlled by TIFFSetField(tiff, TIFFTAG_YCBCRSUBSAMPLING, hor, ver); http://www.awaresystems.be/imaging/tiff/tifftags/ycbcrsubsampling.html byte order of components depends on this as well On Sat, Dec 12, 2009 at 19:27, Antonio Scuri <scuri@tecgraf.puc-rio.br> wrote: >> So, you can store either RGB, YCbCr, or CMYK data in TIFF files. >> However, due to the variable conversion algorithms used for converting >> to/from CMYK or YCbCr, anything other than RGB is probably not likely >> to work outside of whatever application creates them. Is that a >> correct statement? > > No, I said only for CMYK. YCbCr has a very precise conversion for RGB. > > >> Also, if a user employs the automatic conversion process to get from >> YCbCr to RGB, doesn't the wide variety of possible conversion matrices >> for this process make the automatic conversion somewhat inconsistent or >> even incorrect in some cases? >> Does LibTiff implement the most common >> conversion matrix (if that's even clearly defined) for this automatic >> process, or is there some guess at a conversion matrix based on the >> data itself? > > Both no, for the same reason. > > >> It just seems to me that storing image data in anything other than RGB- >> based formats is not a good idea for most general usages and should >> only be employed if the images are used for internal program processing >> only. Otherwise, the matrix employed to generate the YCbCr or CMYK >> format is not known to a reader of the file. > > As Toby explained, CMYK is used for publishing workflows. And the > conversion is complicated. No it is not commonly used. > > On the other hand YCbCr is widely used. Mostly because you can separate > luminance and chrominance information, and compress them with different > approaches. Almost all JPEG files are stored in this way (I mean *.jpg). > > So actually it depends on what your application does. Also depends on > what file format/compression you choose. > > Best, > Scuri > > > > > > _______________________________________________ > Tiff mailing list: Tiff@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/ > -- Tomislav Muić _______________________________________________ Tiff mailing list: Tiff@lists.maptools.org http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/

LibTiff Mailing List

2010.03.15 08:18 "Re: YCbCr", by Tomislav Muic