Re: Strange scaling of GIF images

[Jeremias Maerki <de...@jeremias-maerki.ch>]

First of all, let me say that I personally think that GIF shouldn't be
used anymore today. I'd convert the image to PNG and use that. :-)

On 29.03.2007 01:57:09 Daniel Noll wrote:
> Pascal Sancho wrote:
> > Hmm, I tried it on Photoshop, and I confirm that I loose black pixels while rendering "for the Web".
> > Strange. Someone else have an idea?
> 
> I already said there is no way to "loose" pixels. :-)

Right. The GIF itself seems to be ok.

> Photoshop and whatever FOP is using to load the GIF possibly have the 
> same issue.
> 
> The GIF file in question is like this:
> 
>    +-----------------------------+   -        |
>    |                             |   ^        v
>    |    +------------------+     |   |        -
>    |    |                  |     | image     data
>    |    |                  |     | height   height
>    |    +------------------+     |   |        -
>    |                             |   v        ^
>    +-----------------------------+   -        |
> 
>    |<------- image width ------->|
> 
>         |<-- data width -->|
> 
> This is possible since with the GIF format if the image pixels don't 
> take up the entire width of the image, you don't have to store them.  In 
> this situation the width and height of the image data is stored 
> separately to the image width and height, and there is an X and Y offset 
>   also, to say where the data is offset.

We defer the whole image loading to ImageIO in that case, so if ImageIO
doesn't already handle the image offset, the code in FOP certainly
doesn't. We'd have to write special code for GIF to handle the offset.
With ImageIO you can access those values through the GIF Image Metadata
Format which is described in the Javadocs if anyone wants to fix this.
http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/metadata/doc-files/gif_metadata.html

> Incidentally this feature is also used in GIF animations so that when 
> only a small part of the image changes, only that part of the image 
> needs to be stored.
> 
> Creating an image of this type isn't too difficult either... in GIMP:
>    * Create a new image with a transparent background.
>    * Create a new layer with width and height smaller than the image.
>    * Draw something on the layer.
>    * Save as GIF.
> 
> I suspect the loss of black is something different entirely, probably 
> related to the way GIFs do transparency.

No, with the way FOP currently handles images. Your GIF images has a
color table with 3 entries, two color being black. One of the blacks is
used for the transparency mask, the other for black painting. Now, FOP
currently converts the index bitmap into an (s)RGB image and later tries
to find out which color is used for transparency. In your case black is
used twice which is the real cause. In the PDF, the image object says
that black is its transparency color but the PDF viewer has no way
anymore to distinguish between black and transparent black. That's why
you lose pixels. That's again something that should be resolved with the
redesign of the image package because ImageIO properly returns the
indexed color model. It's just a matter of preserving that.

> Whatever's going on though, the toolkit seems to know how to load the 
> image correctly so maybe there is a way to force FOP to use that for 
> GIFs instead of ImageIO.

Currently doable only by hacking FOP source code. I will probably see to it
that the redesign includes more fine-grained control over which image
library is used.

Closing word: Don't use GIF. :-) And not just because of the patent
problem (yes, I know it's expired).

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Re: Strange scaling of GIF images

[Daniel Noll <da...@nuix.com>]

Jeremias Maerki wrote:
> We defer the whole image loading to ImageIO in that case, so if ImageIO
> doesn't already handle the image offset, the code in FOP certainly
> doesn't. We'd have to write special code for GIF to handle the offset.
> With ImageIO you can access those values through the GIF Image Metadata
> Format which is described in the Javadocs if anyone wants to fix this.
> http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/metadata/doc-files/gif_metadata.html

Actually, I already contributed a patch to fix this bit, a day or two ago.

The information is in fact stored in the standard metadata so it isn't 
GIF-specific and will work for future image formats which happen to have 
the same feature.  Under each image's "Dimension" (for a GIF there is 
one per frame of the animation but we only care about the first one) 
there is a "HorizontalPixelOffset" and "VerticalPixelOffset".  Under the 
stream metadata's "Dimension" there is a "HorizontalScreenSize" and 
"VerticalScreenSize" which stores the true size of the image.

All my patch does at present is to mangle the bitmap array, but it can 
probably be improved.  I'm sure there is a bug or two in there as I 
haven't exhaustively tested it yet. :-)

> No, with the way FOP currently handles images. Your GIF images has a
> color table with 3 entries, two color being black. One of the blacks is
> used for the transparency mask, the other for black painting. Now, FOP
> currently converts the index bitmap into an (s)RGB image and later tries
> to find out which color is used for transparency. In your case black is
> used twice which is the real cause. In the PDF, the image object says
> that black is its transparency color but the PDF viewer has no way
> anymore to distinguish between black and transparent black. That's why
> you lose pixels. That's again something that should be resolved with the
> redesign of the image package because ImageIO properly returns the
> indexed color model. It's just a matter of preserving that.

I was thinking another workaround might be to somehow change the first 
colour in the palette to something else so that the collision doesn't 
occur.  I'm just hoping this won't involve opening the GIF, writing over 
the palette and saving it again. :-)

> Closing word: Don't use GIF. :-) And not just because of the patent
> problem (yes, I know it's expired).

The GIF is linked to from an HTML file which we happen to want to 
convert to PDF via XSL-FO.  So unless we manually convert all GIF files 
to PNG and change all the links from the FO file, it ain't gonna happen. :-)

With all this I have to wonder, do translucent PNGs work?

Daniel

-- 
Daniel Noll

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia    Ph: +61 2 9280 0699
Web: http://nuix.com/                               Fax: +61 2 9212 6902

This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org