Hi,

I finally got someone running unstable to test this.  While it
doesn't segfault, I believe that's a fortuitous event -- the code
that calls TIFFSetField to set the number and types of
EXTRASAMPLES hasn't changed at all, and is still being
miscalled[1].

In any case, the following test using libimage-imlib2-perl shows
that the result isn't as intended:

perl -MImage::Imlib2 -e '$im=Image::Imlib2->new(200,200);
        $im->set_color(255,255,255,192);
        $im->fill_rectangle(0,0,200,200);
        $im->image_set_format("tiff");
        $im->save("tmp.tiff");'

Running tiffinfo on tmp.tiff says that the ExtraSamples field
contains one extra sample of type <unspecified>, rather than
associated alpha:

TIFF Directory at offset 0x238 (568)
   Image Width: 200 Image Length: 200
   Bits/Sample: 8
   Compression Scheme: Deflate
   Photometric Interpretation: RGB color
   Extra Samples: 1<unspecified>
[...]

And indeed tiffdump agrees that the extra sample types array
consists of one zeroed out short:

[...] ExtraSamples (338) SHORT (3) 1<0>

Furthermore, if you open the image with gimp, it will complain
about the unspecified extra samples type, and assumes an
unassociated alpha channel, showing the image as too dark[2].

Cheers,

Joonas


[1] TIFFSetField() is a varargs function that should be called
like so:

        TIFFSetField(
                thetiff,
                TIFFTAG_EXTRASAMPLES,
                number_of_extrasamples,
                pointer_to_extrasample_types_array):

The previous segfault in libimlib2-1.2.1 was happening inside
libtiff while it was accessing the extrasample types array, but
none was passed to it.

I believe it's currently most likely accessing some piece of
zeroed out memory via some pointer on the stack, that just
happens to be where the pointer_to_extrasample_types_array
argument should be, but I've not had a chance to check that.
(Zero, because that's the <unspecified> extra sample type shown
by tiffinfo/tiffdump.)

[2] Gimp assumes an unspecified extra sample type to mean
non-premultiplied colour components (unassociated alpha) and
shows the pixels all having value (192,192,192,192), instead of
(255,255,255,192.)  There's really no need to premultiply the
colours in imlib2's save() function at all, really, since TIFF
allows for unassociated alpha in the image using an extra sample
of type EXTRASAMPLE_UNASSALPHA.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to