GNU bug report logs - #39994
27.0.90; Broken image-converter probe for imagemagick

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39994 <at> debbugs.gnu.org
Subject: bug#39994: 27.0.90; Broken image-converter probe for imagemagick
Date: Mon, 03 Aug 2020 02:31:39 +0300

>> 1. AFAIR one of the goals for creating image-converter.el
>> was to handle such rare image formats as WEBP,
>> but I tried to open a webp file, and image-converter failed
>> because it doesn't recognize WEBP.
>>
>> There is no WEBP mentioned in the output of "identify -list format".
>> After installing `apt-get install webp`, another command
>> "identify -list delegate" reports its support with:
>>
>>   Delegate                Command
>>   -------------------------------------------------------------------------------
>>          webp =>          "dwebp' -pam '%i' -o '%o"
>>           png<= webp      "cwebp' -quiet %Q '%i' -o '%o"
>
> My imagemagick says:
>
> $ identify -list format | grep -i webp
>      WEBP* WEBP      rw-   WebP Image Format (libwebp 0.6.1[0208])
>
> So I guess that you have a too-old imagemagick installation?  I don't
> really think this is an image-converter.el bug, though -- it's best
> effort, and if you don't have external programs to display these things,
> then it fails.

I already upgraded to the latest version, and now the output is exactly
the same as yours above.  Then even without installing the Debian
package 'webp', visiting a webp file shows it just fine as an image with
"Image[image-convert]" in the mode-line.  So there is no problem anymore.

>> 2. After adding manually webp to image-converter-regexp,
>> there is another problem: image-converter--convert-magick
>> calls the command with
>>
>>   (apply #'call-process (car command)
>>          nil t nil
>>
>> where the arg 't' means to mix standard error output with ordinary output,
>> but ImageMagick outputs some info messages to stderr, e.g.:
>>
>>   Decoded /tmp/magick-20114vaPD-fxUjRW4. Dimensions: 320 x 214 . Format: lossy. Now saving...
>>   Saved file /tmp/magick-20114h1Jh0D04beDR
>>
>> thus breaking the image output.
>
> Yes, it's a pain that we can't direct stderr to its own buffer.  Is
> there any reason why?  We don't want to write this stuff to a file
> (which is allowed), because of the problems with clean-up.

I can't reproduce this problem anymore since webp opens without an error.

>> 3. Visiting an image file from an archive signals the error
>>
>>   Cannot display image: (IMAGE-FORMAT should be a symbol like ‘image/png’)
>
> Do you have a test case for this?

The test case is to zip a png file and a webp file.
Then visiting a png file in the archive displays the image,
whereas visiting a webp file signals the error:

  "Unknown image type; consider switching ‘image-use-external-converter’ on"

But the value of 'image-use-external-converter' is already 't'.

>> 4. Exif fails to visit images with the error:
>>
>>   Cannot display image: (sequencep 122)
>>
>> Shouldn't exif code be called with ignore-errors, so its errors won't
>> affect the image displaying?
>>
>> Test case:
>>
>>   exif --output=blackz.jpg --tag=Artist --ifd=0 --set-value='z' test/data/image/black.jpg
>
> I seem to recall fixing this, and this test case doesn't fail for me (in
> Emacs 28.1).

Yes, you already fixed it.  So it looks like everything is fixed here,
and the feature request to support image-converter in archives
could be moved to a separate bug#.

PS: Also 'image-next-file' currently ignores webp files in Dired-mode.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.