Please list filenames of images with corrupt EXIF data

[LaurentBonnaud]

Hi,

when I run sigal on my image gallery, I see the following error message:

Collecting albums //usr/lib/python3/dist-packages/PIL/TiffImagePlugin.py:788: UserWarning: Corrupt EXIF data.  Expecting to read 12 bytes but only got 8.
  warnings.warn(str(msg))
Collecting albums, done.

I would like to inspect/fix the affected images, but unfortunately sigal does not display their filenames.

[saimn]

Hi,
The warning comes from Pillow, but if you run sigal in verbose mode (-v) it would print the filenames.

[LaurentBonnaud]

Unfortunately, it does not:

$ sigal build --verbose
INFO: Reading settings ...
INFO:       Source : /var/www/html/photos-export-sigal/pictures
INFO:  Destination : /var/www/html/photos-export-sigal/_build
INFO:        Theme : photoswipe
INFO: Using 2 cores
/usr/lib/python3/dist-packages/PIL/TiffImagePlugin.py:788: UserWarning: Corrupt EXIF data.  Expecting to read 12 bytes but only got 8.
  warnings.warn(str(msg))
INFO: Skip empty album: <Album>(path='2010-2011', title='2010-2011')
[...]

[saimn]

Hmm, maybe in debug mode then: sigal build -d -n 1

[LaurentBonnaud]

Thanks for the suggestions!

Unfortunately debug mode still does not display filenames:

$ sigal build -d -n 1
INFO - Reading settings ...
DEBUG - Settings file: sigal.conf.py
DEBUG - Rewrite source : pictures -> /var/www/html/photos-export-sigal/pictures
DEBUG - Rewrite destination : _build -> /var/www/html/photos-export-sigal/_build
DEBUG - Settings:
[...]
INFO -       Source : /var/www/html/photos-export-sigal/pictures
INFO -  Destination : /var/www/html/photos-export-sigal/_build
INFO -        Theme : photoswipe
DEBUG - Plugin paths: []
DEBUG - Registered plugin sigal.plugins.extended_caching
INFO - Using 1 cores
DEBUG - Loaded cache with 74795 entries
/usr/lib/python3/dist-packages/PIL/TiffImagePlugin.py:788: UserWarning: Corrupt EXIF data.  Expecting to read 12 bytes but only got 8.
  warnings.warn(str(msg))
INFO - Skip empty album: <Album>(path='2010-2011', title='2010-2011')

[saimn]

Annoying! We already catch some warnings from Pillow, so I guess we could just convert all warnings to logging messages and add the file name.

sigal/sigal/image.py

Lines 65 to 81 in 964c27f

	def _read_image(file_path):
	# The image is already opened
	if isinstance(file_path, PILImage.Image):
	return file_path
	with warnings.catch_warnings(record=True) as caught_warnings:
	im = PILImage.open(file_path)
	for warning in caught_warnings:
	if warning.category == PILImage.DecompressionBombWarning:
	logger = logging.getLogger(__name__)
	logger.info('PILImage reported a possible DecompressionBomb'
	' for file {}'.format(file_path))
	else:
	warnings.showwarning(warning.message, warning.category,
	warning.filename, warning.lineno)
	return im

[saimn]

@LaurentBonnaud - Just pushed a commit to convert all pillow warnings to logging message with the filename. If you can give a try, would be great!

[LaurentBonnaud]

Thanks for the patch!
I am currently on holiday and will test this as soon as I am back...

[LaurentBonnaud]

I upgraded sigal to version 2.1.1, but unfortunately I am still getting the PIL warning without a filename (the output did not change).

[saimn]

Hum, maybe it happens only when reading EXIF ... could you with the exif-warnings branch ? (or applying the patch locally, https://github.com/saimn/sigal/tree/exif-warnings ; the commit is fbdac96)

[LaurentBonnaud]

Thanks a lot for this new patch!

The warning is now caught, but there is still no filename:

Reading settings ...
Source : /var/www/html/photos-export-sigal/pictures
Destination : /var/www/html/photos-export-sigal/_build
Theme : photoswipe
Using 2 cores
PILImage reported a warning for file <PIL.MpoImagePlugin.MpoImageFile image mode=RGB size=4896x2752 at 0x7FEFE52F5790>
<class 'UserWarning'>: Corrupt EXIF data.  Expecting to read 12 bytes but only got 8.

[saimn]

Indeed, fixed in 5f0929c and this is now in master.
Thanks for the help to improve those warnings!

[LaurentBonnaud]

Indeed, fixed in 5f0929c and this is now in master.

I tested this new version and I could locate the affected file :>.

Thanks for the help to improve those warnings!

Thanks for the fix!