[Gdal-dev] GTiff / gdal_translate / CMYK - problem

Fri Aug 22 06:09:31 EDT 2008

Hi Craig,

Good tip, I'll give it a shot and see what comes out.

BTW, GTiff driver won't let you create CMY-only dataset (3 bands: C, M and
Y). 

I also sumbled onto this piece of code (if anyone's interested in
implementing it in GDAL) for both CMYK->RGB and RBG->CMYK conversions, based
on Adobe and Artifex algorithms:
http://svn.ghostscript.com/ghostscript/tags/gs-ghostpdl-1.50/src/gxdcconv.c

It seems that Adobe (Photoshop) keeps color "presets" in NATIVEDIGEST tiff
tag, but that's just an assumption.

Regards,
Maksim Sestic

-----Original Message-----
From: Craig Miller [mailto:craig.miller at spatialminds.com] 
Sent: Friday, August 22, 2008 11:22
To: 'Maksim Sestic'; gdal-dev at lists.osgeo.org
Subject: RE: [Gdal-dev] GTiff / gdal_translate / CMYK - problem

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

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2888 (20080220) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com