Weird (at least to me) behavior with "image create photo -format "gif -index n"

[Dave]

I keep running into the weirdest things.

I made an animated gif with imagemagick; the original images were 456x527:

magick convert -dispose previous -delay 10 -resize x100 F*.png -loop
0 T.gif

Many things show the size of T.gif as 87x100. However, when I read a
frame with

image create photo F0 read T.gif -format "gif -index 0"

I get:

image width F0 => 114
image height F0 => 114

Irfanview & Photofiltre display a 87x114 image
XnViewMP shows a 114x114 image but tells me it's 87x100
Gimp shows 114x114 with the 87x100 image as a selection

Looking further into the gif, I found:

Logical Screen Descriptor:
Logical Screen Width: 114 pixels
Logical Screen Height: 114 pixels

I don't know why imagemagick is not just making the gif 87x100 -- maybe
there's some sort of restriction for animated gifs with transparency
although 114 is not a multiple of 8 which might be expected.

Anyway, would this be considered a bug with the 'photo' -index option?
It seems to me that I should get a 87x100 image rather than 114x114
since there's no way I know (in Tcl) how to extract the inner frame.

--
computerjock AT mail DOT com

[Dave]

On 4/6/2017 6:52 PM, Dave wrote:
>
> Looking further into the gif, I found:
>
> Logical Screen Descriptor:
> Logical Screen Width: 114 pixels
> Logical Screen Height: 114 pixels
>

Just to be clear, each frame in the GIF has:

Image Descriptor:
Image Left Position: 26 pixels
Image Top Position: 0 pixels
Image Width: 87 pixels
Image Height: 100 pixels

[Alexandre Ferrieux]

OK, at least the first 114 is explained (87+26+rounding): clearly the logical screen is the smallest rectangle enclosing both (0,0) and the image with its offset. Dunno about the second 114 though.

Note that Tk seems to be consistent with Gimp at least, which also shows you the whole logical screen. I wouldn't call this a bug, since it's the only way not to lose anything in case of negative offsets.

Regarding the extraction, what about the "copy" subcommand of the image command ? It takes -from RECT and -to RECT, so you can skip that annoying offset.

Anyway, if you think there's still something fishy in that image, please open a ticket and attach it.

-Alex

[Dave]

A followup to my problem

Having read the Wikipedia article which describes the GIF file format, I
can see how an Image Descriptor could be used to reduce the size of a
GIF file by eliminating all but that portion of a frame that changes.
This allows the Logical Screen Descriptor to define a larger canvas. So,
without reading an entire GIF file, one cannot know the true extent of
an image since each Image Descriptor could provide a different portion
of the whole.

Since Tcl probably does not do this, it must return an image with the
size of the Logical Screen Descriptor -- in my case 114x114 (although
where ImageMagick came up with 114 is a mystery).

I have found another ImageMagick option that fixes the issue for me:

magick convert -dispose previous -delay 10 -resize x100 \
+repage F*.png -loop 0 T.gif

The "+repage" eliminated the unused portion of the Logical Screen. The
output file T.gif is now 87x100 for the Logical Screen and all Image
Descriptors. Tcl now returns 87x100 images for the image frames.