I was noticing that a GIF was being displayed with padding in FireFox 5 and IE 8. When I viewed the image size via FireBug, I noticed that it was a few pixels larger than expected.
我注意到在FireFox 5和IE 8中使用填充显示了GIF。当我通过FireBug查看图像大小时,我注意到它比预期的大几个像素。
Expected height: 160px vs. actual height: 171px
预期高度:160px与实际高度:171px
When I opened the GIF in an image editor, the editor displayed the correct dimensions, however when I ran ImageMagick identify I received the following information:
当我在图像编辑器中打开GIF时,编辑器显示了正确的尺寸,但是当我运行ImageMagick时,我收到了以下信息:
newGif.gif GIF 200x160 200x171+0+5 PseudoClass 256c 30kb
If I modified the geometry to 200x160+0+0 the image displayed as I expected it to in FireFox. FireFox and IE 8 seemed to be referencing the Image's page geometry rather than dimensions! Is my analysis correct and if so is this true for all image types or just GIF's?
如果我将几何图形修改为200x160 + 0 + 0,则图像显示为我在FireFox中预期的图像。 FireFox和IE 8似乎引用了Image的页面几何而不是尺寸!我的分析是否正确,如果是这样,对所有图像类型或GIF都是如此?
Updated, I have included an image for your viewing pleasure! This image displays as 200 x 171 for me in FF, but is actually 200 x 160 when you download and view in a graphics program.
更新后,我已经为您的观看乐趣添加了一张图片!这个图像在FF中显示为200 x 171,但在图形程序中下载和查看时实际上是200 x 160。
3 个解决方案
#1
7
Header of this GIF file does not correspond to it's body. 
此GIF文件的标题与其正文不对应。
Image dimensions are stored in 6th to 9th bytes and from the screen shot you can see that dimensions in the header are 00C8 x 00AB which is 200x171 but it's actual size is 200x160
图像尺寸存储在第6到第9个字节中,从屏幕截图中可以看到标题中的尺寸为00C8 x 00AB,即200x171,但实际尺寸为200x160
So this image is not valid. There are no standardized behavior for parsing invalid gifs and that's why there is this inconsistency.
所以这个图像无效。解析无效的GIF没有标准化的行为,这就是为什么会出现这种不一致的原因。
Most probably firefox preallocates place for images before they are fully downloaded, when an image is fully downloaded it is put into the center of preallocated space. and because preallocated space is 200x171 but the actual image is 200x160 you will see a border.
很可能firefox在完全下载之前为图像预分配图像,当图像被完全下载时,它被放入预分配空间的中心。并且由于预分配空间为200x171,但实际图像为200x160,您将看到边框。
EDIT: After going through GIF format reference it appears that GIF does allow this. So the image is valid. So here's what's actually going on here: GIF format consists from several blocks. There is a header block and one or more(if the image is animated) image blocks (there could be other blocks as well, but they are not connected with the issue). Header block holds some information about the image, including it's width and height. However each image block has it's own width and height as well. So what happens with the image in question that it has the main image size as 200x171 but the single frame with the size 200x160. So most editing programs and libraries which doesn't support animated gifs will extract the first frame and display it with the size 200x160 the browsers and editors which do support animation should display it with the full size of 200x171.
编辑:经过GIF格式参考后,看起来GIF确实允许这样做。所以图像是有效的。所以这里是实际发生的事情:GIF格式由几个块组成。有一个标题块和一个或多个(如果图像是动画的)图像块(也可能有其他块,但它们没有连接问题)。标题块包含有关图像的一些信息,包括它的宽度和高度。但是每个图像块也有自己的宽度和高度。那么对于所讨论的图像,它的主图像大小为200x171,而单帧大小为200x160,会发生什么。所以大多数不支持GIF动画的编辑程序和库都会提取第一帧并以200x160的大小显示它,支持动画的浏览器和编辑器应该以200x171的全尺寸显示它。
PS Every image block has image top and image left position. It seems that by allowing frames to be smaller than canvas, and allowing to move frame's position on the canvas, GIF's developers tried to shave couple of bytes of the animated gif files. I wonder if any of the modern graphic editors take advantage of that... probably not... :)
PS每个图像块都有图像顶部和图像左侧位置。似乎通过允许帧比画布小,并允许在画布上移动帧的位置,GIF的开发人员试图削减动画gif文件的几个字节。我想知道是否有任何现代图形编辑器利用它......可能不是...... :)
- GIF format byte order
GIF格式字节顺序
#2
0
I suspect that the GIF is an animated format, so it could contain several images located on different positions of the geometry frame. Therefore, the browser should reserve place for a whole thing.
我怀疑GIF是一种动画格式,因此它可能包含几个位于几何框架不同位置的图像。因此,浏览器应该为整个事物预留位置。
#3
0
If you save the picture, and right click->properties, it'll state that it is 200x160, also of note when you preview the picture in windows black bars are added to the image, which is strange. If you open it in ms paint (just for demonstration purposes) you'll notice that the image is padded with black bars, and when you look at the file->properties it says the image is now 200x171.
如果您保存图片,并右键单击 - >属性,它将声明它是200x160,当您在窗口中预览图片时也会注意到黑色条被添加到图像中,这很奇怪。如果你用ms画画打开它(仅用于演示目的),你会注意到图像用黑条填充,当你查看文件 - >属性时,它表示图像现在是200x171。
The most likely scenario is that the file header says it's 200x160 (which windows/browsers etc looks at to tell you the image size quickly), while the actual image block is 200x171. The black bars don't show up in browsers as they are likely transparent, but as ms paint and windows preview don't support transparency, the black bars show in them. Further the correct size is found in mspaint because the header data is thrown out, and the properties show you properties of their data structure now holding the image block to image editing, similarly if you load the image into mspaint, modify the image to remove the black bars, save, and then put that picture into your browser then the padding will disappear.
最可能的情况是文件标题表示它是200x160(窗口/浏览器等看起来快速告诉您图像大小),而实际图像块是200x171。黑条不会显示在浏览器中,因为它们可能是透明的,但由于ms画图和窗口预览不支持透明度,黑条显示在其中。此外,在mspaint中找到正确的大小,因为标题数据被抛出,并且属性显示其数据结构的属性,现在将图像块保存到图像编辑,类似地,如果您将图像加载到mspaint中,修改图像以删除黑条,保存,然后将该图片放入浏览器,然后填充将消失。
Most of the time, when loading the image of an image file, only horizontal resolution of the image is required, and the image block is just read for the horizontal resolution for every vertical row of the image, when you read the end of the image block, you're at the end of the image, so heeding the vertical resolution isn't mandatory to load the image from it. This is why the image appears normal, and doesn't crop off the bottom edge.
大多数情况下,在加载图像文件的图像时,只需要图像的水平分辨率,并且当您读取图像的末尾时,只读取图像的每个垂直行的水平分辨率的图像块阻止,你在图像的末尾,因此不需要注意垂直分辨率从中加载图像。这就是图像看起来正常,并且不会从底部边缘裁剪的原因。
As for why this image isn't padded in other browsers. I can only assume that this padding images with boarders is a standard of sorts that they have come to expect in image files, and when confronted with an image block larger than the file header specifies, they crop it toward the centre of the image block to the best of their ability
至于为什么这个图像没有在其他浏览器中填充。我只能假设这个带有边界的填充图像是他们在图像文件中所期望的各种标准,并且当遇到大于文件头指定的图像块时,它们将其朝向图像块的中心裁剪为他们最好的能力
#1
7
Header of this GIF file does not correspond to it's body.
此GIF文件的标题与其正文不对应。
Image dimensions are stored in 6th to 9th bytes and from the screen shot you can see that dimensions in the header are 00C8 x 00AB which is 200x171 but it's actual size is 200x160
图像尺寸存储在第6到第9个字节中,从屏幕截图中可以看到标题中的尺寸为00C8 x 00AB,即200x171,但实际尺寸为200x160
So this image is not valid. There are no standardized behavior for parsing invalid gifs and that's why there is this inconsistency.
所以这个图像无效。解析无效的GIF没有标准化的行为,这就是为什么会出现这种不一致的原因。
Most probably firefox preallocates place for images before they are fully downloaded, when an image is fully downloaded it is put into the center of preallocated space. and because preallocated space is 200x171 but the actual image is 200x160 you will see a border.
很可能firefox在完全下载之前为图像预分配图像,当图像被完全下载时,它被放入预分配空间的中心。并且由于预分配空间为200x171,但实际图像为200x160,您将看到边框。
EDIT: After going through GIF format reference it appears that GIF does allow this. So the image is valid. So here's what's actually going on here: GIF format consists from several blocks. There is a header block and one or more(if the image is animated) image blocks (there could be other blocks as well, but they are not connected with the issue). Header block holds some information about the image, including it's width and height. However each image block has it's own width and height as well. So what happens with the image in question that it has the main image size as 200x171 but the single frame with the size 200x160. So most editing programs and libraries which doesn't support animated gifs will extract the first frame and display it with the size 200x160 the browsers and editors which do support animation should display it with the full size of 200x171.
编辑:经过GIF格式参考后,看起来GIF确实允许这样做。所以图像是有效的。所以这里是实际发生的事情:GIF格式由几个块组成。有一个标题块和一个或多个(如果图像是动画的)图像块(也可能有其他块,但它们没有连接问题)。标题块包含有关图像的一些信息,包括它的宽度和高度。但是每个图像块也有自己的宽度和高度。那么对于所讨论的图像,它的主图像大小为200x171,而单帧大小为200x160,会发生什么。所以大多数不支持GIF动画的编辑程序和库都会提取第一帧并以200x160的大小显示它,支持动画的浏览器和编辑器应该以200x171的全尺寸显示它。
PS Every image block has image top and image left position. It seems that by allowing frames to be smaller than canvas, and allowing to move frame's position on the canvas, GIF's developers tried to shave couple of bytes of the animated gif files. I wonder if any of the modern graphic editors take advantage of that... probably not... :)
PS每个图像块都有图像顶部和图像左侧位置。似乎通过允许帧比画布小,并允许在画布上移动帧的位置,GIF的开发人员试图削减动画gif文件的几个字节。我想知道是否有任何现代图形编辑器利用它......可能不是...... :)
- GIF format byte order
GIF格式字节顺序
#2
0
I suspect that the GIF is an animated format, so it could contain several images located on different positions of the geometry frame. Therefore, the browser should reserve place for a whole thing.
我怀疑GIF是一种动画格式,因此它可能包含几个位于几何框架不同位置的图像。因此,浏览器应该为整个事物预留位置。
#3
0
If you save the picture, and right click->properties, it'll state that it is 200x160, also of note when you preview the picture in windows black bars are added to the image, which is strange. If you open it in ms paint (just for demonstration purposes) you'll notice that the image is padded with black bars, and when you look at the file->properties it says the image is now 200x171.
如果您保存图片,并右键单击 - >属性,它将声明它是200x160,当您在窗口中预览图片时也会注意到黑色条被添加到图像中,这很奇怪。如果你用ms画画打开它(仅用于演示目的),你会注意到图像用黑条填充,当你查看文件 - >属性时,它表示图像现在是200x171。
The most likely scenario is that the file header says it's 200x160 (which windows/browsers etc looks at to tell you the image size quickly), while the actual image block is 200x171. The black bars don't show up in browsers as they are likely transparent, but as ms paint and windows preview don't support transparency, the black bars show in them. Further the correct size is found in mspaint because the header data is thrown out, and the properties show you properties of their data structure now holding the image block to image editing, similarly if you load the image into mspaint, modify the image to remove the black bars, save, and then put that picture into your browser then the padding will disappear.
最可能的情况是文件标题表示它是200x160(窗口/浏览器等看起来快速告诉您图像大小),而实际图像块是200x171。黑条不会显示在浏览器中,因为它们可能是透明的,但由于ms画图和窗口预览不支持透明度,黑条显示在其中。此外,在mspaint中找到正确的大小,因为标题数据被抛出,并且属性显示其数据结构的属性,现在将图像块保存到图像编辑,类似地,如果您将图像加载到mspaint中,修改图像以删除黑条,保存,然后将该图片放入浏览器,然后填充将消失。
Most of the time, when loading the image of an image file, only horizontal resolution of the image is required, and the image block is just read for the horizontal resolution for every vertical row of the image, when you read the end of the image block, you're at the end of the image, so heeding the vertical resolution isn't mandatory to load the image from it. This is why the image appears normal, and doesn't crop off the bottom edge.
大多数情况下,在加载图像文件的图像时,只需要图像的水平分辨率,并且当您读取图像的末尾时,只读取图像的每个垂直行的水平分辨率的图像块阻止,你在图像的末尾,因此不需要注意垂直分辨率从中加载图像。这就是图像看起来正常,并且不会从底部边缘裁剪的原因。
As for why this image isn't padded in other browsers. I can only assume that this padding images with boarders is a standard of sorts that they have come to expect in image files, and when confronted with an image block larger than the file header specifies, they crop it toward the centre of the image block to the best of their ability
至于为什么这个图像没有在其他浏览器中填充。我只能假设这个带有边界的填充图像是他们在图像文件中所期望的各种标准,并且当遇到大于文件头指定的图像块时,它们将其朝向图像块的中心裁剪为他们最好的能力