[gdal-dev] GTiff / gdal_translate / CMYK - problem
Maksim Sestic
max at geoinova.com
Mon Sep 1 05:24:59 EDT 2008
Hi all,
Huh, getting back to this issue since I need more-or-less elegant solution
to RGB->CMYK conversion. BTW, I'm using managed GDAL wrappers (csharp).
Here's the steps I went through, although need some assistance...
Converting RGB GTiff named "INPUT.tif" to CMYK GTiff named "OUTPUT.tif":
1) Use GTiff driver to create 4-band OUTPUT.tif, setting "PHOTOMETRIC=CMYK"
option
2) Copy all 3 bands from INPUT.tif, marking each band as C, M and K on
OUTPUT. Copy source metadata as well.
3) Also copy 1st band from INPUT.tif as 4th band (K = black) on OUTPUT,
filling it uniformly to any color
4) Go through each OUTPUT.tif band (C, M and Y) and get CMYK alpha values
using:
(...here goes GDALReadDirect part that reads band data into Bitmap...)
Dim attr as New ImageAttributes
attr.SetOutputChannelColorProfile("ProfileName.icc",ColorAdjustType.Bitmap)
attr.SetOutputChannel(ColorChannelFlagsC,ColorAdjustType.Bitmap)
(...then use Graphics object to apply resulting alpha channel (C, M or Y)
onto underlying band (R, G or B)...)
5) Using GDALWriteDirect write CMY bands back into OUTPUT.tif
What puzzles me here is how do I get K channel values, and whether
attr.SetOutputChannel(ColorChannelFlagsK,ColorAdjustType.Bitmap) will return
valid K alpha values for underlying RGB? Don't forget step 3) which provides
"empty" K band on output.
P.S.
Regarding the CMYK formula (please see short PHP source from my previous
message), I simply have no idea of how to turn CMYK (double) values into
valid RGB (byte) values to be able to actually write them into Bitmap
object. I'm doing RGB -> CMYK -> RGB then and wondering if that's correct
approach after all.
Regards,
Maksim Sestic
-----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 13:10
To: gdal-dev at lists.osgeo.org
Subject: RE: [gdal-dev] GTiff / gdal_translate / CMYK - problem
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-tp740987p
751427.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2888 (20080220) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
More information about the gdal-dev
mailing list