This fix is only committed to master for now. I'm no exif expert on this matter, so someone else might want to take a look over this and merge as wanted in case this will break something.
In exif_process_IFD_in_JPEG() we loop over the tag entries and try to process the IFD tag, this is fine and all, however in case one fail to process correctly, the entire routine is aborted, which means that other possible data, such as the thumbnail data as reported in #72735 may not be read, despite it is there, perfectly valid.
Also, big props to whoever added EXIF_DEBUG, this rocks!
for (de=0;de<NumDirEntries;de++) {
if (!exif_process_IFD_TAG(ImageInfo, dir_start + 2 + 12 * de,
offset_base, IFDlength, displacement, section_index, 1, exif_get_tag_table(section_index))) {
- return FALSE;
+ continue;
}
}
/*
if ((itemlen - 2) < 6) {
return FALSE;
}
-
exif_process_SOFn(Data, marker, &sof_info);
ImageInfo->Width = sof_info.width;
ImageInfo->Height = sof_info.height;
--- /dev/null
+--TEST--
+Bug #72735 (Samsung picture thumb not read (zero size))
+--SKIPIF--
+<?php if (!extension_loaded('exif')) print 'skip exif extension not available';?>
+--FILE--
+<?php
+foreach (['nokia.jpg', 'samsung.jpg'] as $picture) {
+ $len = strlen(exif_thumbnail(__DIR__ . '/' . $picture));
+
+ if ($len === 0) {
+ echo $picture . ': error, no thumbnail length', PHP_EOL;
+
+ continue;
+ }
+
+ echo $picture . ': int(' . $len . ')', PHP_EOL;
+}
+?>
+--EXPECTF--
+nokia.jpg: int(%d)
+samsung.jpg: int(%d)