Selon Jukka Rahkonen <[email protected]>: > Even Rouault <even.rouault <at> mines-paris.org> writes: > > > > > Selon Jukka Rahkonen <jukka.rahkonen <at> mmmtike.fi>: > > > > > Hi, > > > > > > I would like to know what happens if I convert an original RGBA tiff > image > > > into jpeg as > > > > > > gdal_translate -of jpeg rgba_in.tif jpeg_out.jpg > > > > > > I know that for getting a good result I can add "-b 1 -b 2 -b 3" but I am > > > curious to know what happens and how GDAL computes sort of a transparent > > > sepia coloured mask when run without selecting bands. > > > > It will result in a TIFF with separate bands (PLANARCONFIG_SEPARATE : > > > http://www.awaresystems.be/imaging/tiff/tifftags/planarconfiguration.html), > each > > of them JPEG compressed. So for a transparency mask with "instantenous" > changes > > between zones of fully transparence and fully opacity, you'll have JPEG > > artifacts. > > I'm wondering if the "sepia coloured mask" is not caused by a viewer that > will > > be confused by this TIFF configuration and would assume a CMYK color space > > instead of RGB. > > Hi Even, > > Sorry, I must have been unclear. The question was about writing out a real > JPEG file, not JPEG compressed TIFF
Ah my fault. I read too fast. > The command gdal_translate -of jpeg rgba_in.tif jpeg_out.jpg creates a jpeg > file with this gdalinfo > > C:\Jukka>gdalinfo jpeg_out.jpg [...] > SOURCE_COLOR_SPACE=CMYK My guess was right actually. In JPEG there's no way, AFAIK, to define RGBA. 4 bands JPEG are assumed to be in CMYK color space. _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
