[gdal-dev] What happens by default when writing RGBA into jpeg?

[Even Rouault]

Selon Jukka Rahkonen <jukka.rahkonen at mmmtike.fi>:

> 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.