[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