Zipped image file

Zipped image file

[Angelo Graziosi]

Suppose one uses bzip2 to compress a PNG file, foo.png ---> foo.png.bzip2. Visiting this file, Emacs says that cannot display the image because cannot determine the image type. The file is shown using (Fundamental Image) mode and only its codes are displayed (something like '\123'). Is this to be expected (master build)? I think it is decompressed but only its 'textual' nature is displayed not the image. Is there a command M-x ... I can use to convert that 'text' in image?

With text file, for example, visiting foo.txt.bzip2 works, the file is decompressed and readable.

Thanks,
  Angelo.

Re: Zipped image file

[Paul Eggert]

On 9/6/19 2:04 PM, Angelo Graziosi wrote:
> Suppose one uses bzip2 to compress a PNG file, foo.png ---> foo.png.bzip2. Visiting this file, Emacs says that cannot display the image because cannot determine the image type.

I see similar symptoms, but the display works as expected if the file is 
named foo.png.bz2. Is the extension '.bzip2' popular? I generally see 
just '.bz2'.

Anyway, I suggest filing a bug report (presumably with a fix) if it's a 
problem for you.

Re: Zipped image file

[Angelo Graziosi]

> Il 6 settembre 2019 alle 23.24 Paul Eggert ha scritto:
> 
> 
> On 9/6/19 2:04 PM, Angelo Graziosi wrote:
> > Suppose one uses bzip2 to compress a PNG file, foo.png ---> foo.png.bzip2. Visiting this file, Emacs says that cannot display the image because cannot determine the image type.
> 
> I see similar symptoms, but the display works as expected if the file is 
> named foo.png.bz2. Is the extension '.bzip2' popular? I generally see 
> just '.bz2'.

There was a mistake: read 'foo.png.bzip2' == 'foo.png.bz2' in the above text.

Here both foo.png.bz2 and foo.png.bzip2 produce almost the same result: only 'garbage' is displayed, not the PNG image.

Anyway, the .bz2 version is decompressed but not the .bzip2. I have checked this also with a text file: foo.txt.bz2 is displayed correctly a fully readable; foo.txt.bzip2 is displayed as 'garbage' (should have seen .bzip2 files somewhere...).

BTW, I tested this both on Windows build and GNU/Linux (cairo build).

If this is to be expected, it is useless to file a bug report.

Re: Zipped image file

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 6 Sep 2019 14:24:02 -0700
> Cc: emacs-devel@gnu.org
> 
> On 9/6/19 2:04 PM, Angelo Graziosi wrote:
> > Suppose one uses bzip2 to compress a PNG file, foo.png ---> foo.png.bzip2. Visiting this file, Emacs says that cannot display the image because cannot determine the image type.
> 
> I see similar symptoms, but the display works as expected if the file is 
> named foo.png.bz2.

You mean, you see the image?  If so, I suspect this might be because
your Emacs is built with ImageMagick.

Re: Zipped image file

[Paul Eggert]

On 9/7/19 3:21 AM, Eli Zaretskii wrote:
>> I see similar symptoms, but the display works as expected if the file is
>> named foo.png.bz2.
> You mean, you see the image?  If so, I suspect this might be because
> your Emacs is built with ImageMagick.

Yes, sorry, I think that was the problem.

The behavior Angelo observes isn't expected, as it's a regression from Emacs 26 
on typical platforms. So a bug report is warranted.

Re: Zipped image file

[Eli Zaretskii]

> Cc: angelo.g0@libero.it, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 7 Sep 2019 03:39:50 -0700
> 
> On 9/7/19 3:21 AM, Eli Zaretskii wrote:
> >> I see similar symptoms, but the display works as expected if the file is
> >> named foo.png.bz2.
> > You mean, you see the image?  If so, I suspect this might be because
> > your Emacs is built with ImageMagick.
> 
> Yes, sorry, I think that was the problem.
> 
> The behavior Angelo observes isn't expected, as it's a regression from Emacs 26 
> on typical platforms. So a bug report is warranted.

I see the same behavior in Emacs 26.3, so I'm not sure there's been a
regression.  Even if I use create-image with an explicit 'png
argument, the image from a compressed file isn't displayed correctly.
I wonder how come you see something different.

Re: Zipped image file

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 4653 bytes --]

On 9/7/19 4:05 AM, Eli Zaretskii wrote:
> I see the same behavior in Emacs 26.3

When I visit the attached file with the Emacs bundled in Ubuntu 18.04.3, I see 
the image. The Emacs version is as follows:

In GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
  of 2017-09-22, modified by Debian built on lgw01-amd64-050
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description:	Ubuntu 18.04.3 LTS

Configured using:
  'configure --build x86_64-linux-gnu --prefix=/usr
  --sharedstatedir=/var/lib --libexecdir=/usr/lib
  --localstatedir=/var/lib --infodir=/usr/share/info
  --mandir=/usr/share/man --with-pop=yes
 
--enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.2/site-lisp:/usr/share/emacs/site-lisp
  --with-sound=alsa --without-gconf --build x86_64-linux-gnu
  --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
  --localstatedir=/var/lib --infodir=/usr/share/info
  --mandir=/usr/share/man --with-pop=yes
 
--enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.2/site-lisp:/usr/share/emacs/site-lisp
  --with-sound=alsa --without-gconf --with-x=yes --with-x-toolkit=gtk3
  --with-toolkit-scroll-bars 'CFLAGS=-g -O2
  -fdebug-prefix-map=/build/emacs25-jYekUr/emacs25-25.2+1=. -fstack-protector-strong
  -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
  -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
   value of $LC_ALL: en_US.utf8
   value of $LC_COLLATE: en_US.UTF-8
   value of $LC_CTYPE: en_US.UTF-8
   value of $LC_MESSAGES: en_US.UTF-8
   value of $LANG: C
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   global-whitespace-mode: t
   tooltip-mode: t
   global-eldoc-mode: t
   electric-quote-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
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent messages:
Loading 00debian-vars...done
Loading /etc/emacs/site-start.d/50a2ps.el (source)...done
Loading /etc/emacs/site-start.d/50autoconf.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Loading debian-ispell...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done

Load-path shadows:
/usr/share/emacs/25.2/site-lisp/debian-startup hides 
/usr/share/emacs/site-lisp/debian-startup

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils whitespace time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic 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 charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 90655 3677)
  (symbols 48 20171 0)
  (miscs 40 414 121)
  (strings 32 15616 5216)
  (string-bytes 1 462508)
  (vectors 16 12343)
  (vector-slots 8 440995 4880)
  (floats 8 164 7)
  (intervals 56 257 0)
  (buffers 976 18))

[-- Attachment #2: Example.png.bz2 --]
[-- Type: application/x-bzip, Size: 2728 bytes --]

Re: Zipped image file

[Eli Zaretskii]

> Cc: angelo.g0@libero.it, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 7 Sep 2019 05:03:53 -0700
> 
> On 9/7/19 4:05 AM, Eli Zaretskii wrote:
> > I see the same behavior in Emacs 26.3
> 
> When I visit the attached file with the Emacs bundled in Ubuntu 18.04.3, I see 
> the image. The Emacs version is as follows:
> 
> In GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
>   of 2017-09-22, modified by Debian built on lgw01-amd64-050
> Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
> System Description:	Ubuntu 18.04.3 LTS

Using Emacs 25.2 without ImageMagick, the image doesn't display here.
What I see is the binary contents of the uncompressed PNG file.

Re: Zipped image file

[Eli Zaretskii]

> Date: Sat, 07 Sep 2019 15:14:59 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: angelo.g0@libero.it, emacs-devel@gnu.org
> 
> > Cc: angelo.g0@libero.it, emacs-devel@gnu.org
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > Date: Sat, 7 Sep 2019 05:03:53 -0700
> > 
> > On 9/7/19 4:05 AM, Eli Zaretskii wrote:
> > > I see the same behavior in Emacs 26.3
> > 
> > When I visit the attached file with the Emacs bundled in Ubuntu 18.04.3, I see 
> > the image. The Emacs version is as follows:
> > 
> > In GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
> >   of 2017-09-22, modified by Debian built on lgw01-amd64-050
> > Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
> > System Description:	Ubuntu 18.04.3 LTS
> 
> Using Emacs 25.2 without ImageMagick, the image doesn't display here.
> What I see is the binary contents of the uncompressed PNG file.

I'm guessing that ImageMagick uncompresses the file by itself, which
is why you see an image in this case.

Re: Zipped image file

[Angelo Graziosi]

> Il 7 settembre 2019 alle 12.21 Eli Zaretskii <eliz@gnu.org> ha scritto:
> 
> 
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > Date: Fri, 6 Sep 2019 14:24:02 -0700
> > Cc: emacs-devel@gnu.org
> > 
> > On 9/6/19 2:04 PM, Angelo Graziosi wrote:
> > > Suppose one uses bzip2 to compress a PNG file, foo.png ---> foo.png.bzip2. Visiting this file, Emacs says that cannot display the image because cannot determine the image type.
> > 
> > I see similar symptoms, but the display works as expected if the file is 
> > named foo.png.bz2.
> 
> You mean, you see the image?  If so, I suspect this might be because
> your Emacs is built with ImageMagick.

My builds are without ImageMagick.

In any case, I filed a bug report: https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-09/msg00138.html

Re: Zipped image file

[Stefan Monnier]

> Suppose one uses bzip2 to compress a PNG file, foo.png --->

I can see how that can happen by accident, but other than that is there
a good reason to bzip-compress a .png file?

[ This question is somewhat orthogonal to the question at
  hand, admittedly.  ]


        Stefan

Re: Zipped image file

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On 9/7/19 7:36 AM, Stefan Monnier wrote:
> is there
> a good reason to bzip-compress a .png file?

Although typically bzip2 doesn't compress .png files well, there are 
counterexamples such as the attached contrived file which has an 878:1 
compression ratio.

PS. Watch out, it's a torture-test image. If you uncompress it and view it, 
older versions of Emacs will crash and newer versions show only a placeholder 
box, ImagickMagick's "display" program dumps core, Firefox displays it only at 
lower resolution while chewing up CPU, etc.)

[-- Attachment #2: s.png.bz2 --]
[-- Type: application/x-bzip, Size: 297 bytes --]