surreal problems import-ing in GIF format

[alexxx]

Hi everybody:
if I use import with formats as jpg, tif, etc, I have no problems at all, e.g.:

Code: Select all

import -quality 100 -silent -descend filename.tif

if instead I import the image as gif (damn, I have to do it to use it in a python prog I'm writing...) I get always a 1680x1050 image (my monitor resolution!), even if I select a small region.

Is this a known bug?

I want to add - and this is becoming stranger and stranger - that even a good image, taken by import say in jpg format, when converted:

Code: Select all

convert filename.jpg filename.gif

becomes a 1680x1050 gif file!!!

Yet, using convert to put in the gif format other images, which were not obtained by import, perfectly preserves their size.

???

alessandro

[anthony]

Can you post teh command line you use for the GIF with the region option?

[alexxx]

Can you post teh command line you use for the GIF with the region option?

exactly what I wrote above, but for gif:

Code: Select all

import -quality 100 -silent -descend filename.gif

(the descend option - I found somewhere - could be useful for a more exact grab, but it doesnt help at all)

That line produces, even grabbin a small rectangle, a 1680x1050 image.
I didnt mention it before: the image is transparent everywhere, except for the grabbed part which is correctly reproduced in the position where I've drawn the rectangle with the mouse.

Any ideas?

alessandro

[anthony]

It seems to work for me, no problem. I grab a rectangle and that is what I get.

Tell me about the display you are grabbing from. Is it using alpha transparency? 3D acceleration? Video Overlay? Virtual Computer Display?

If you import the whole display do you see the section your are trying to grab?

These things may not be covered by a X windows grab as they are later 'tack ons' and overlays to the original X window display handling.

[alexxx]

It seems to work for me, no problem. I grab a rectangle and that is what I get.

Tell me about the display you are grabbing from. Is it using alpha transparency? 3D acceleration? Video Overlay? Virtual Computer Display?

If you import the whole display do you see the section your are trying to grab?

These things may not be covered by a X windows grab as they are later 'tack ons' and overlays to the original X window display handling.

Thank you for your help Anthony...
I am a bit at a disadvantage here, since I'm not such an expert in X configuration... my system is setup - as I see under KDE's sys settings and system-config-display - at 1680x1050, thousands of colors.
Video card is a plain ATI ES1000, radeon driver. I am pretty sure I dont have any 3D support at all with such a cheap card... so it is for alpha transparency, Video Overlay and Virtual Computer Display: I would not even know where to go to set them up!

re:If you import the whole display do you see the section your are trying to grab?,
I'm not sure I understand you. I selected the whole screen, and it correctly acquired it, filling with it the 1680x1050 image.

alessandro

[alexxx]

maybe I simply don't understand some basics here...

I uploaded a small gif I got from import, as discussed above, at http://www.inrim.it/~magni/f.gif

But if I convert it to tif (convert f.gif f.tif) I get the image I want! ( http://www.inrim.it/~magni/f.tif )

Then again, re-converting it to gif ( convert f.tif f2.gif, because, remember, I unfortunately need it as a gif!) I - surprise - end up with a white box: http://www.inrim.it/~magni/f2.gif

I dont understand anything anymore...


alessandro

[Jason S]

ImageMagick is trying to be clever, and keep track of an image position within a logical screen. There's probably a way to tell it not to do that -- maybe someone else can help.

Also...

Your f2.gif is not a valid GIF file. The GIF89a spec says:

Each image must fit within the boundaries of the Logical Screen

f2.gif's logical screen is 65x93. It contains one image, whose size is 65x93, and whose position is (60,872), which is way beyond the boundaries of the logical screen. I'd say it's a bug that IM is willing to create an invalid GIF image.

Also...

Your f.tif file includes XPosition and YPosition tags, which must be what IM bases f2.gif's image position on. However, the ResolutionUnit tag in f.tif is "unspecified", which effectively makes the Position tags meaningless. I guess that IM treats them as if they were in inches, which is the default unit for TIFF files, but I don't think it's supposed to do that. The default of "inches" should only be used if the ResolutionUnit tag is not present, not if it's present but indicates "unspecified". So I think that's another bug.

[Jason S]

Apparently, "+repage" is the way to fix this.

Code: Select all

convert f.gif +repage f3.gif

I'm having second thoughts about calling the ResolutionUnit issue a bug. While it doesn't seem quite right, there's no obvious solution, and it might be the most reasonable behavior.

[alexxx]

Apparently, "+repage" is the way to fix this.

Code: Select all

convert f.gif +repage f3.gif

Works perfectly, thanks to all of you!

I'm having second thoughts about calling the ResolutionUnit issue a bug. While it doesn't seem quite right, there's no obvious solution, and it might be the most reasonable behavior.

So you don't think I should file it as a bug?

alessandro

[Jason S]

So you don't think I should file it as a bug?

It's not a bug. I was wrong about it defaulting to inches. Provided the XResolution and YResolution tags are present, the position can always be translated to pixels, regardless of whether the units are specified.