Testing locally with tiffinfo reports: TIFFFetchNormalTag: Warning, Incorrect value for "RichTIFFIPTC"; tag ignored.

Running it through identify -verbose, takes 27seconds (ridiculously long to retrieve metadata). and ends with
identify: Incorrect value for "RichTIFFIPTC"; tag ignored. TIFFFetchNormalTag' @ warning/tiff.c/TIFFWarnings/950.`

It seems that imagemagick has some problems with the way IPTC is stored in this image and there are more people reporting similar issues here:
https://legacy.imagemagick.org/discourse-server/viewtopic.php?t=28126

Apparently that was a bug in Adobe Lightroom and some software can now handle that bug, but possibly not yet the version of lib tiff inside the imagemagick that we use ?

What I can see in logstash is that this is pretty common. I'm just not sure if it is common only on cases where the identify is also busting out of the fire jail, or if it this retrievemetadata logic wrapping it is somehow seeing the warning as an error.

@TheDJ thank you for your research. I am looking into it.
I just found that the mentioned file can be thumbnailed only if the name doesn't have any round brackets. I was able to reproduce it locally.
I successfully got an image for localhost:8800/thumbor/unsafe/800x/67-0372-C_Tran_Van_Huong_left_and_Mai_Tho_Truyen.tif
but
It failed for localhost:8800/thumbor/unsafe/800x/67-0372-C_Tran_Van_Huong_(left)_and_Mai_Tho_Truyen.tif
67-0372-C_Tran_Van_Huong_(left)_and_Mai_Tho_Truyen.tif is the original name of the mentioned file in the description of the ticket. The only difference is that the word left is enclosed in round brackets in the original filename.
Python 3.7 says that the file is not found.

Ah, the warning goes to stderr and UnboxedCommand has logic that makes output on stderr log these lines...

UnboxedExecutor:430

if ( $stderr !== '' && $command->getLogStderr() ) {
			$this->logger->error( "Error running {command}: {error}", [
				'command' => $cmd,
				'error' => $stderr,
				'exitcode' => $retval,
				'exception' => new ShellboxError( 'Shell error' ),
			] );
		}

So this might not be directly related...

In T311004#8453837, @Vlad.shapik wrote:

I just found that the mentioned file can be thumbnailed only if the name doesn't have any round brackets. I was able to reproduce it locally.

I have uploaded a TIF file to commons.wikimedia.beta.wmflabs.org with round brackets in the filename -> https://commons.wikimedia.beta.wmflabs.org/wiki/File:67-0372-C_Bann_Van_Hddds_(left)_and_Lai_Tio_Truffn.tif. And everything is ok. I believe my suspicion of round brackets in the filename is wrong.

Finally found the error in logstash

logger_name: thumbor
message: TypeError: argument 1 must be string or buffer, not None
url: /wikipedia/commons/thumb/0/00/67-0372-C_Tran_Van_Huong_%28left%29_and_Mai_Tho_Truyen.tif/lossy-page1-120px-67-0372-C_Tran_Van_Huong_%28left%29_and_Mai_Tho_Truyen.tif.jpg

File "/usr/lib/python2.7/dist-packages/thumbor/handlers/__init__.py", line 140, in get_image
  self.context.request.image_url
File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1015, in run
  value = future.result()
File "/usr/lib/python2.7/dist-packages/tornado/concurrent.py", line 237, in result
  raise_exc_info(self._exc_info)
File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1024, in run
  yielded = self.gen.send(value)
File "/usr/lib/python2.7/dist-packages/thumbor/handlers/__init__.py", line 609, in _fetch
  self.context.request.engine.load(fetch_result.buffer, extension)
File "/usr/lib/python2.7/dist-packages/wikimedia_thumbor/engine/proxy/proxy.py", line 119, in load
  self.lcl[enginename].load(buffer, extension)
File "/usr/lib/python2.7/dist-packages/thumbor/engines/__init__.py", line 167, in load
  image_or_frames = self.create_image(buffer)
File "/usr/lib/python2.7/dist-packages/wikimedia_thumbor/engine/vips/vips.py", line 95, in create_image
  return super(Engine, self).create_image(result)
File "/usr/lib/python2.7/dist-packages/wikimedia_thumbor/engine/imagemagick/imagemagick.py", line 62, in create_image
  temp_file.write(buffer)

For a whole list of these: https://logstash.wikimedia.org/goto/b5f41c34b06ba5bbc08447d9b1550a8a

Meaning the buffer is None, probably meaning that fetch_result.buffer is None and the original file could not be retrieved from the file store ?

In T311004#8456746, @TheDJ wrote:

File "/usr/lib/python2.7/dist-packages/wikimedia_thumbor/engine/imagemagick/imagemagick.py", line 62, in create_image
  temp_file.write(buffer)

I got the same error when I tried to thumbnail this file on the production version of Thumbor with Debian:Stretch and Python2.7 locally.
Here is the error message from libvips which causes the break of the code -> vipspng: profile 'icc': 'RGB ': RGB color space not permitted on grayscale PNG vips2png: unable to write.

But on the Debian:Buster and Python3.7 (it will be a production version but now it is only on staging) I don't see this error locally and I successfully get the thumbnail of this image. ImageMagick can already convert RGB to grayscale than the ImageMagick version for Debian:Stretch.

Yeah likely the combo of libpng and vips then. This refers to a similar problem I think: https://github.com/libvips/libvips/issues/1248

Also checked log stash and all the images I checked with this error are indeed grayscale

@hnowlan has checked the mentioned file on the staging and he didn't get any error as on the current production version of Thumbor. Since we will soon replace the current Thumbor production version(Debian Stretch/Python2.7) with the current staging one(Debian Buster/Python3.7), this ticket can be moved to done.