[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 :-)
(source: http://forums.digitalpoint.com/showthread.php?t=475864)
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
> read
> about it, here's what I found (citations ahead):
>
> 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,
> FileAccess.Read, FileShare.Read);
> BitmapSource myBitmapSource = BitmapFrame.Create(imageStream);
>
> FormatConvertedBitmap newFormatedBitmapSource = new
> FormatConvertedBitmap();
>
> newFormatedBitmapSource.BeginInit();
> newFormatedBitmapSource.Source = myBitmapSource;
> newFormatedBitmapSource.DestinationFormat = PixelFormats.Cmyk32;
> newFormatedBitmapSource.EndInit();
>
> BitmapEncoder encoder = new TiffBitmapEncoder();
> encoder.Frames.Add(BitmapFrame.Create(newFormatedBitmapSource));
> 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 `'
>> Metadata:
>> 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 `'
>> Metadata:
>> TIFFTAG_SOFTWARE=Adobe Photoshop CS3 Windows
>> 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
>>
>>xmlns:tiff="http://ns.adobe.com/tiff/1.0/">256,257,258,259,262,274,277,
>>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.
More information about the gdal-dev
mailing list