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

2008-08-20 Thread Maksim Sestic

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_00017_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;46BB973B26CC7DED3A1C59F8F9AC7EC5/tiff:NativeDigest


Regards,
Maksim Sestic
-- 
View this message in context: 
http://www.nabble.com/GTiff---gdal_translate---CMYK---problem-tp19066003p19066003.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] ogr2gui - project development

2008-08-20 Thread Daniel Morissette

Frank, and all,

What would you think of adding a OGR related projects / resources to 
the OGR website that could link to projects like this ogr2gui and 
perhaps translated docs (e.g. 
http://softlibre.gloobe.org/doku.php/gdal_ogr/start) and any external 
resources that may be of interest to GDAL/OGR users?


Daniel

Mathieu Lahaye wrote:

Hi,

My company developed a graphical user interface (GUI) for ogr2ogr. We 
created an open source project called ogr2gui.


We intend to make this application available to GIS users who aren’t 
comfortable with the ogr2ogr syntax or looking for a fast, easy and free 
geospatial data translator.


 


You can download the source code or the installer at: inventis.ca/ogr2gui

Note that this is only RC 0.1 and only few data formats are supported. 
We’ll add some more as soon as possible…


 

We’re currently looking for some people who’d like to get involved in 
this utility program development.


We’d also like to get some feedback about the project…do you think it’s 
useful? should it looks different? functions we should add or remove, etc.


 


All comments or suggestions are welcome!

 


Thanks,

 


**Mathieu Lahaye**

[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]

www.inventis.ca http://www.inventis.ca

 





___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Daniel Morissette
http://www.mapgears.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


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

2008-08-20 Thread Frank Warmerdam

Maksim Sestic wrote:

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.


Maksim,

I would note that CMYK photometric interpretation requires 4 bands.
Furthermore, GDAL does *not* manage the conversion to CMYK color space.
You would need to do that ahead of time by some means.

I've never tried to create CMYK files so I don't have any further advice.

Best regards,


--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


[gdal-dev] SoC Final Report: GDAL TMS driver

2008-08-20 Thread Frank Warmerdam


Folks,

I received the following report from Václav on the GDAL TMS driver status:


Since the final deadline has approached, I am sending you the result of 
my futile attempt to implement the TMS driver.


The reading part sort of works. The driver always assumes Origin is in 
the bottom left corner of the map. There is no support for profiles and 
projections. It will read the raster data from disk.


I could not get the writing right. During testing, gdal_translate 
regularily calls methods on dataset that has already been deleted, don't 
know why. The driver will write the xml resource file, create the 
directory structure and fill it with empty tiles. Writing after this 
point doesn't work, the cached tiles won't be written and for the life 
of me I don't know why. Also the IRasterIO implementation is probably 
bogus too, since gdal_translate calls IWriteBlock only on the 
TopRasterBand instead of on all overviews as it should. There are no 
output settings, tiles are hardcoded to PNG, 256x256 pixels.



I have uploaded the source he supplied into /spike/tms in the GDAL 
subversion and added some notes on how to build and test it at:


 http://trac.osgeo.org/gdal/wiki/SoCTMSDriver

The project period is over, and it isn't clear whether Václav will be 
doing any more work on the driver.  I'm available to consult and help 
with anyone wanting to carry this effort forward.  For the time being 
the project artifacts are captured in the wiki and subversion and should 
not be lost.


Best regards,
FrankW
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev