[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39994: 27.0.90; Broken image-converter probe for imagemagick
From: |
Juri Linkov |
Subject: |
bug#39994: 27.0.90; Broken image-converter probe for imagemagick |
Date: |
Mon, 03 Aug 2020 02:31:39 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) |
>> 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.