bug#73976: 31.0.50; King Features comics JPEG misrendered

bug#73976: 31.0.50; King Features comics JPEG misrendered

[Eric Gillespie]

This is not new in emacs 30; I first noticed the problem in
emacs 29.

1. Load any King Features comic in a browser such as Firefox,
   e.g. https://www.usatoday.com/comics/?content_id=bba01&feat_name=beetlebailey
2. Grab the image URL (e.g. https://adn.kingfeatures.net/?a=4478135.jpg)
3. Load it in emacs e.g. M-x eww RET https://adn.kingfeatures.net/?a=4478135.jpg RET
4. Or download it and open it locally with find-file

Expected:
Emacs renders the comic properly.

Actual:
All the black is missing.  Possibly other problems.

I don't know what it is about these JPEGs in particular.  I don't
see this anywhere else.  The WEBP format of the same comics from
comicskingdom.com work just fine.


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.2) of 2024-10-23 built on dogato
Repository revision: 5e5689a2a40cd16d7593a0c7ddea5511adc3bf22
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101012
System Description: openSUSE Tumbleweed

Configured using:
 'configure -C --prefix=/opt/emacs-master --disable-silent-rules
 --with-native-compilation=no'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE
XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired dired-loaddefs rfc822 mml
mml-sec epa derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader sendmail misearch multi-isearch vc-git
diff-mode track-changes easy-mmode files-x vc-dispatcher pp view
yank-media mhtml-mode css-mode smie js c-ts-common treesit imenu cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs sgml-mode facemenu shr-color color textsec uni-scripts
idna-mapping ucs-normalize uni-confusable textsec-check cl-extra
help-mode gnutls network-stream url-http mail-parse rfc2231 rfc2047
rfc2045 ietf-drums url-gw nsm url-cache url-auth format-spec eww xdg
vtable mule-util url-queue thingatpt shr pixel-fill kinsoku url-file svg
xml dom browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util url-parse
auth-source cl-seq eieio eieio-core cl-macs icons password-cache json
map byte-opt gv bytecomp byte-compile url-vars mailcap puny mm-url gnus
nnheader gnus-util text-property-search time-date subr-x mail-utils
range wid-edit mm-util mail-prsvr cl-loaddefs cl-lib rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list
replace newcomment text-mode lisp-mode prog-mode register page tab-bar
menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse
jit-lock font-lock syntax font-core term/tty-colors frame minibuffer
nadvice seq simple cl-generic indonesian philippine cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process emacs)

Memory information:
((conses 16 263844 159517) (symbols 48 14439 0)
 (strings 32 67064 2810) (string-bytes 1 1419060) (vectors 16 46148)
 (vector-slots 8 545056 44215) (floats 8 206 3510)
 (intervals 56 296 24) (buffers 992 11))

bug#73976: 31.0.50; King Features comics JPEG misrendered

[Eli Zaretskii]

> From: Eric Gillespie <epg@pretzelnet.org>
> Date: Wed, 23 Oct 2024 16:03:05 -0500
> 
> This is not new in emacs 30; I first noticed the problem in
> emacs 29.
> 
> 1. Load any King Features comic in a browser such as Firefox,
>    e.g. https://www.usatoday.com/comics/?content_id=bba01&feat_name=beetlebailey
> 2. Grab the image URL (e.g. https://adn.kingfeatures.net/?a=4478135.jpg)
> 3. Load it in emacs e.g. M-x eww RET https://adn.kingfeatures.net/?a=4478135.jpg RET
> 4. Or download it and open it locally with find-file
> 
> Expected:
> Emacs renders the comic properly.
> 
> Actual:
> All the black is missing.  Possibly other problems.
> 
> I don't know what it is about these JPEGs in particular.  I don't
> see this anywhere else.  The WEBP format of the same comics from
> comicskingdom.com work just fine.

Looks like some problem with libjpeg: I can only see the problem if I
disable the use of MS-Windows native image APIs (which forces Emacs to
use libjpeg instead).  With the default setting of
w32-use-native-image-API on MS-Windows the saved image displays
correctly.

bug#73976: 31.0.50; King Features comics JPEG misrendered

[Eric Gillespie]

Eli Zaretskii <eliz@gnu.org> writes:

> Looks like some problem with libjpeg

Well, maybe.  Everything else that loads it fine also seems to
use libjpeg.  It could be a bug in HOW emacs uses libjpeg.

Firefox, gimp, gwenview, and even 'jpegtopnm | pnmtoxwd | xwud'
all work.

The one other tool I found which doesn't handle these images
correctly is xli, which bails out without even trying:

/home/epg/Downloads/adn.kingfeatures.jpg is a 2047x597 JPEG image, color space YCCK, 4 comps., Huffman coding
jpegLoad: weird output color space
zopen: warning: caching was disabled by previous caller
/home/epg/Downloads/adn.kingfeatures.jpg: unknown or unsupported image type

Light googling suggest YCCK may be an odd duck, and may be what
throws emacs for a loop...

Thanks!

-- 
Eric Gillespie <*> epg@pretzelnet.org