# [gdal-dev] GTiff / gdal_translate / CMYK - problem

Maksim Sestic max at geoinova.com
Fri Aug 22 07:09:58 EDT 2008

```Finally, found some PHP code that makes sense :-)

Parameters:
\$rgb    -   an array of color information where
\$rgb[0] == red value
\$rgb[1] == green value
\$rgb[2] == blue value
Returns:
array containing cmyk color information:
\$array[0] == cyan value
\$array[1] == magenta value
\$array[2] == yellow value
\$array[3] == black value
*/
function RGB_to_CMYK(\$rgb)
{
\$cyan = 1 - (\$rgb[0] / 255);
\$magenta = 1 - (\$rgb[1] / 255);
\$yellow = 1 - (\$rgb[2] / 255);

\$min = min(\$cyan, \$magenta, \$yellow);

if (\$min == 1)
return array(0,0,0,1);

\$K = \$min;
\$black = 1 - \$K;

return array
(
(\$cyan - \$K) / \$black,
(\$magenta- \$K) / \$black,
(\$yellow - \$K) / \$black,
\$K
);
}

Regards,
Maksim Sestic

Craig Miller-2 wrote:
>
> I'm no expert on color conversions, but I am reading it as 1 = 100%.  So,
> if
> you have an RGB image with values ranging from 0 - 255, then convert it to
> a
> percent first then subtract it from R.
>
> For example, if you have RGB values of 200, 100, 255:
>
> r = 200/255 = .7843
> g = 100/255 = .3921
> b = 255/255 = 1.0
>
> Then CMY = (1-.7843, 1-.3921, 1-1.0) or (C=0.2157, M=0.6079, Y=0.0)
>
> Craig
>
>
> -----Original Message-----
> From: gdal-dev-bounces at lists.osgeo.org
> [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
> Sent: Friday, August 22, 2008 12:40 AM
> To: gdal-dev at lists.osgeo.org
> Subject: RE: [Gdal-dev] GTiff / gdal_translate / CMYK - problem
>
> Hi Even,
>
> Thanks for the info, but I need it other way round - RGB to CMYK
> conversion.
> As Frank said, it's possible to create a CMYK result using gdal_translate
> giving it an extra band as a parameter (i.e. -b 1 -b 2 -b 3 -b 1), but the
> end result is of no use since that extra band (along with R, G and B)
> takes
> some color mangling I'm not very familiar with. And there's not much to
>
> http://semmix.pl/color/extrans/etr10.htm
>
> Transformation RGB, CMY, CMYK
> Formal transformation of the components RGB into the components CMY or
> inversely is as follows:
>
> we have color RGB=(r,g,b) then color CMY=(1-r,1-g,1-b) we have color
> CMY=(c,m,y) then color RGB=(1-c,1-m,1-y).
>
> Transformation of CMY into CMYK is presented as algorithm:
> k=min(c,m,y), CMYK=(c-k,m-k,y-k,k)
>
> This explanation seems sane enough, but then: "we have color RGB=(r,g,b)
> then color CMY=(1-r,1-g,1-b)" is giving me a headache with "1-r" etc.
> part.
> What do they mean by "1-r"? :-)
>
> Furthermore, RGB to CMYK is supported by .NET 3.5 only, and giving it a
> shot
> via GDAL managed wrappers is also viable solution (thanks Tamas for
> LoadBitmapDirect and SaveBitmapDirect C# examples). I'm working with .NET
> 2.0 and can't use this approach, but here's the code anyways (author
> unknown):
>
> using System;
> using System.IO;
> using System.Windows.Forms;
> using System.Windows.Media;
> using System.Windows.Media.Imaging;
> ...
>
> Stream imageStream = new FileStream(@"C:\temp\mike4.jpg", FileMode.Open,
> BitmapSource myBitmapSource = BitmapFrame.Create(imageStream);
>
> FormatConvertedBitmap newFormatedBitmapSource = new
> FormatConvertedBitmap();
>
> newFormatedBitmapSource.BeginInit();
> newFormatedBitmapSource.Source = myBitmapSource;
> newFormatedBitmapSource.DestinationFormat = PixelFormats.Cmyk32;
> newFormatedBitmapSource.EndInit();
>
> BitmapEncoder encoder = new TiffBitmapEncoder();
> Stream cmykStream = new FileStream(@"C:\temp\mike4_CMYK.tif",
> FileMode.Create, FileAccess.Write, FileShare.Write);
> encoder.Save(cmykStream);
> cmykStream.Close();
>
>
> Again, it would be great if someone could explain how to do it via GDAL
> wrappers running on .NET 2.0 (I'm using GDAL build from FWTools).
>
> Regards,
> Maksim Sestic
>
>
> -----Original Message-----
> From: Even Rouault [mailto:even.rouault at mines-paris.org]
> Sent: Thursday, August 21, 2008 20:44
> To: gdal-dev at lists.osgeo.org
> Cc: Maksim Sestic
> Subject: Re: [Gdal-dev] GTiff / gdal_translate / CMYK - problem
>
> Maksim,
>
> I've just done a few changes in the GeoTIFF driver to enable basic CMYK
> support.
>
> See the log message of http://trac.osgeo.org/gdal/changeset/15178.
> And for examples : http://trac.osgeo.org/gdal/changeset/15179.
>
> Regards,
> Even
>
> Le Wednesday 20 August 2008 11:46:06 Maksim Sestic, vous avez écrit :
>> Hi all,
>>
>> I'm having troubles with gdal_translate while creating uncompressed
>> 3-band GTiff with CMYK photometric representation. Well, at least CMYK
>> representation recognized by Photoshop, which is
>> PhotometricInterpretation=5. If I use recommended gdal_translate -co
>> 'PHOTOMETRIC=CMYK' switch I keep getting "grayscale" (!) result,
>> again, that's what Photoshop says (PhotometricInterpretation=1).
>>
>> What other -co parameters should I set to make it work? I'm using
>> gdal_translate from FWTools 2.2.3
>>
>>
>> Here's the gdalinfo reports:
>>
>> 1) For RGB raster parsed with gdal_translate -co 'PHOTOMETRIC=CMYK'
>>  switch:
>>
>> Size is 945, 945
>> Coordinate System is `'
>>   AREA_OR_POINT=Area
>>   TIFFTAG_SOFTWARE=MyApp
>>   TIFFTAG_DATETIME=20.08.2008 02:51:37
>>   TIFFTAG_XRESOLUTION=240
>>   TIFFTAG_YRESOLUTION=240
>>   TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata:
>>   INTERLEAVE=PIXEL
>> Corner Coordinates:
>> Upper Left  (    0.0,    0.0)
>> Lower Left  (    0.0,  945.0)
>> Upper Right (  945.0,    0.0)
>> Lower Right (  945.0,  945.0)
>> Center      (  472.5,  472.5)
>> Band 1 Block=945x2 Type=Byte, ColorInterp=Gray Band 2 Block=945x2
>> Type=Byte, ColorInterp=Undefined Band 3 Block=945x2 Type=Byte,
>> ColorInterp=Undefined
>>
>> Side note: I also tried using -co 'PHOTOMETRIC=YCBCR' and
>> 'PHOTOMETRIC=CIELAB'switches but then gdal_translate crashes.
>>
>>
>> 2) Photoshopped tiff with CMYK mode set (that's what I need to get):
>>
>> Driver: GTiff/GeoTIFF
>> Files: 080417_75008_000000017_CMYK.tif Size is 945, 945 Coordinate
>> System is `'
>>   TIFFTAG_DATETIME=2008:08:20 02:21:08
>>   TIFFTAG_XRESOLUTION=240
>>   TIFFTAG_YRESOLUTION=240
>>   TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata:
>>   INTERLEAVE=PIXEL
>> Corner Coordinates:
>> Upper Left  (    0.0,    0.0)
>> Lower Left  (    0.0,  945.0)
>> Upper Right (  945.0,    0.0)
>> Lower Right (  945.0,  945.0)
>> Center      (  472.5,  472.5)
>> Band 1 Block=945x2 Type=Byte, ColorInterp=Undefined Band 2 Block=945x2
>> Type=Byte, ColorInterp=Undefined Band 3 Block=945x2 Type=Byte,
>> ColorInterp=Undefined Band 4 Block=945x2 Type=Byte,
>> ColorInterp=Undefined
>>
>> Also, there's another Photoshop's TIFF tag, "NativeDigest", which I
>>don't  really get (it's not recognized by gdalinfo) - here's the xmp
> output:
>> <tiff:NativeDigest
>>
>>284,
>>530,531,282,283,296,301,318,319,529,532,306,270,271,272,305,315,33432;4
>>6BB97 3B26CC7DED3A1C59F8F9AC7EC5</tiff:NativeDigest>
>>
>>
>> Regards,
>> Maksim Sestic
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature
> database 2888 (20080220) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature
> database 2888 (20080220) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.6.6/1625 - Release Date: 8/21/2008
> 6:04 AM
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>

--
View this message in context: http://n2.nabble.com/Re%3A-GTiff---gdal_translate---CMYK---problem-tp740987p751427.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.

```