Python程序中PIL Image "image file is truncated"问题分析与解决

逃离我推掉我的手 2021-11-27 07:16 613阅读 0赞

## 解决方案 ##

第一种、删除截断图片  
第二种、添加两行代码，如下

from PIL import ImageFile
    ImageFile.LOAD_TRUNCATED_IMAGES = True

## 错误原因 ##

首先看一下错误信息，大致意思是图像文件是损坏的，无法读取，后面37个bytes无法处理

> OSError: image file is truncated (37 bytes not processed)

第一次运行程序时没有发生这样的错误，后面觉得图像文件的命名很杂乱，于是就写了一个重命名程序，对文件夹里的数据进行重新命名，程序如下所示

import os
    path = './data/train/Image/'
    # 获取该目录下所有文件，存入列表中
    f = os.listdir(path)
    n = 0
    for i in f:
        # 设置旧文件名（就是路径+文件名）
        oldname = path + f[n]
        # 设置新文件名
        newname = path + 'Image_' + str(n + 1) + '.JPG'
        # 用os模块中的rename方法对文件改名
        os.rename(oldname, newname)
        print(oldname, '======>', newname)
        n += 1

这样文件夹中的图像命名就会变成“Image\_序列”的格式，改完名后，再运行之前的程序，就报错了，思考了一下，因为我用的笔记本是Mac，Mac中每个文件夹里都有一个隐藏文件，保存着改文件夹里所有文件的位置排列等信息，会不会在改名时把这个文件也改成了JPG文件，所以写了一个程序来测试一下

import os
    path = './data/'
    # 获取该目录下所有文件，存入列表中
    f = os.listdir(path)
    for i in f:
    	print(i)

输出结果中并没有想要的’ .DS\_store’ 文件，看来这个想法是错误的，不是Mac的锅。  
思考再三，用了一个蠢蠢的办法，把数据集里的图片一个个用keras.preprocessing.image.load\_img()打开，如果出错，则把输出图片路径，经过尝试后，终于抓到一个罪魁祸首了，长成这个样子  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODUyNjc2_size_16_color_FFFFFF_t_70]  
在本机上，图片中花了的部分其实是一片灰色，这里可能是由于markdown的图片的格式问题，总之这张图片就是导致出错的原因。我把这张图片从数据集中删除后，再运行程序就不会出错了。

## 这就解决了？ ##

程序通了，按道理这是应该解决了的，可是心中总是有一些疑惑，为什么会出这种错误呢？正好微微有点闲空，就尽可能的深入一点去探一探吧，首先就是查看错误发生的代码处，代码文件是 [ImageFile.py][] ，位于python的site-package文件夹内，下面是报错部分代码

try:
      # FIXME: This is a hack to handle TIFF's JpegTables tag.
      prefix = self.tile_prefix
    except AttributeError:
      prefix = b""
    
    for decoder_name, extents, offset, args in self.tile:
      decoder = Image._getdecoder(self.mode, decoder_name,
                                  args, self.decoderconfig)
      seek(offset)
      decoder.setimage(self.im, extents)
      if decoder.pulls_fd:
          decoder.setfd(self.fp)
          status, err_code = decoder.decode(b"")
      else:
          b = prefix
          while True:
              try:
                  s = read(self.decodermaxblock)
              except (IndexError, struct.error):  # truncated png/gif
                  if LOAD_TRUNCATED_IMAGES:
                      break
                  else:
                      raise IOError("image file is truncated")
    
              if not s:  # truncated jpeg
                  self.tile = []
    
                  # JpegDecode needs to clean things up here either way
                  # If we don't destroy the decompressor,
                  # we have a memory leak.
                  decoder.cleanup()
    
                  if LOAD_TRUNCATED_IMAGES:
                      break
                  else:
                      raise IOError("image file is truncated "
                                    "(%d bytes not processed)" % len(b))

可以看到问题就由于最后四行代码

if s is truncated jpeg:
    	if LOAD_TRUNCATED_IMAGES == True:  # 缺省值是False
    		break
    	else:
    		raise IOError("image file is truncated " "(%d bytes not processed)" % len(b))

所以，如果不想花时间把数据集中的破损图片找出来后删除掉，只需要设置LOAD\_TRUNCATED\_IMAGES = True，在程序开头只需要加上两行代码就行了

from PIL import ImageFile
    ImageFile.LOAD_TRUNCATED_IMAGES = True

这样在遇到截断的JPEG时，程序就会跳过去，读取另一张图片了。

## 继续探索 ##

被截断的图片跟原图有什么区别呢，读入程序里也只是一行行数字而已，就算是灰色的部分或者是花掉的部分，也是一串串数字才是，为什么就会被识别出来呢？  
这就跟JPEG的编码相关了，网络上有许多相关介绍，这里就不一一叙述了，不过倒是有两点引起了我的注意

> SOI，Start of Image，图像开始 标记代码 ： 2字节 固定值0xFFD8  
> EOI，End of Image，图像结束  
> 标记代码 ： 2字节 固定值0xFFD9

意思就是，JPEG图像的二进制流是由 FF D8 开头，由 FF D9 结尾。验证一下，用UltraEdit打开两张正常图片，得到的结果是  
![在这里插入图片描述][20190724150213605.png]  
![在这里插入图片描述][20190724150231335.png]  
另外一张正常图片也是相同的开头和结尾，这里就不展示了。  
那么来看一看截断图的字节流是什么样子的  
![在这里插入图片描述][20190724150243242.png]  
![在这里插入图片描述][20190724150249358.png]  
看来truncated image的原因找到了，这张图片的编码结尾不是按照EOI的规则来的(FF D9结尾)，所以导致程序读图时无法识别这张图片。  
尝试了一下在后面填上了 " FF D9 "，在放回数据集中，运行程序，也没有出错

## truncated image ##

这样看来，出错的原因是图片的编码格式不是JPEG的格式，所以程序无法识别，EOI标识是结尾标识，所以丢失了EOI标识就表示图像后面部分的数据丢失，看起来就像被截断了一样，这也许就是用truncated的原因吧 (因为我一直在想为什么不用broken)

## 再试一次 ##

由上面可以看到就算没有EOI标识，文件后缀名依旧是jpg，所以猜想是SOI决定了文件的格式，为了验证这一想法，用UltraEdit打开一张图片，然后从后往前删除一些字节数据，得到的结果是

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODUyNjc2_size_16_color_FFFFFF_t_70 1]  
再把第一行数据删除，得到的结果是

Windows照片查看器无法打开此图片，因为文件可能已损坏、损毁或过大

猜想验证了

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODUyNjc2_size_16_color_FFFFFF_t_70]: /images/20211126/629475b234fc4b3480bbfe4299dc50fb.png
[ImageFile.py]: http://ImageFile.py
[20190724150213605.png]: /images/20211126/1c4f74b2b2264008b8268eadefb87f27.png
[20190724150231335.png]: /images/20211126/f4e7e1cf16264bf1a5b0c64a2dab8c3c.png
[20190724150243242.png]: /images/20211126/50dabc7b896a41718d6282668b86aa3b.png
[20190724150249358.png]: /images/20211126/ca6fedf7f3bf42ee80e7562132de17e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODUyNjc2_size_16_color_FFFFFF_t_70 1]: /images/20211126/1f2590824398443698873ec56bc31873.png