GNU bug report logs - #52931
27.1; image-size sometimes yields a wrong image size in pixels

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52931 in the body.
You can then email your comments to 52931 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; image-size sometimes yields a wrong image size in pixels
Date: Sat, 01 Jan 2022 18:00:54 +0100

Dear all,

to reproduce this issue, please download the following image:

    https://www.metalevel.at/ei/202202.png

Then start Emacs with

    $ emacs -Q

and evaluate the following form to obtain the image's size in pixels:

    (let ((img (create-image "202202.png")))
      (image-size img t))

In my case, this yields:

    (30 . 30)

This occurs even though the image dimensions in pixels are actually 202x202:

    $ identify 202202.png
    202202.png PNG 202x202 202x202+0+0 8-bit sRGB 6502B 0.000u 0:00.009

Is there a way to obtain this size in pixels with image-size?

The value of max-image-size in my configuration is nil.

Thank you and all the best!
Markus

In GNU Emacs 27.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scroll bars)
 of 2020-12-12 built on macbook
Windowing system distributor 'The X.Org Foundation', version 11.0.11502000
System Description:  Mac OS X 10.11.3

Configured using:
 'configure --prefix=/opt/local --disable-silent-rules --without-ns
 --without-dbus --without-gconf --without-libotf --without-m17n-flt
 --with-gmp --with-gnutls --with-json --with-xml2 --with-modules
 --infodir /opt/local/share/info/emacs --with-x-toolkit=lucid
 --without-xaw3d --without-imagemagick --with-xpm --with-jpeg
 --with-tiff --with-gif --with-png --with-lcms2 --without-rsvg
 --with-xft 'CFLAGS=-pipe -Os -arch x86_64'
 CPPFLAGS=-I/opt/local/include 'LDFLAGS=-L/opt/local/lib
 -Wl,-headerpad_max_install_names -lfreetype -lfontconfig -Wl,-no_pie
 -arch x86_64''

Configured features:
XPM JPEG TIFF GIF PNG GSETTINGS GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2
FREETYPE HARFBUZZ XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM
MODULES THREADS JSON PDUMPER LCMS2 GMP

Message #8 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1;
 image-size sometimes yields a wrong image size in pixels
Date: Sat, 01 Jan 2022 19:09:10 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Date: Sat, 01 Jan 2022 18:00:54 +0100
> 
> Dear all,
> 
> to reproduce this issue, please download the following image:
> 
>     https://www.metalevel.at/ei/202202.png
> 
> Then start Emacs with
> 
>     $ emacs -Q
> 
> and evaluate the following form to obtain the image's size in pixels:
> 
>     (let ((img (create-image "202202.png")))
>       (image-size img t))
> 
> In my case, this yields:
> 
>     (30 . 30)

I cannot reproduce this: I get (202 . 202), both in Emacs 27.1 and in
the current master version.

Maybe this is macOS-specific?

Message #11 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1; image-size sometimes yields a wrong image size
 in pixels
Date: Tue, 27 Sep 2022 19:28:31 +0200

Markus Triska <triska <at> metalevel.at> writes:

> to reproduce this issue, please download the following image:
>
>     https://www.metalevel.at/ei/202202.png
>
> Then start Emacs with
>
>     $ emacs -Q
>
> and evaluate the following form to obtain the image's size in pixels:
>
>     (let ((img (create-image "202202.png")))
>       (image-size img t))
>
> In my case, this yields:
>
>     (30 . 30)

This happens when Emacs isn't able to find the image.  Specify the full
image file name in create-image instead of using a relative one.

Closing.

Message #18 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1;
 image-size sometimes yields a wrong image size in pixels
Date: Wed, 28 Sep 2022 19:24:45 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> This happens when Emacs isn't able to find the image.  Specify the full
> image file name in create-image instead of using a relative one.
>
> Closing.

Why could Eli not reproduce it though? Is this difference between
operating systems expected?

Thank you and all the best,
Markus

Message #21 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1; image-size sometimes yields a wrong image size
 in pixels
Date: Wed, 28 Sep 2022 19:28:03 +0200

Markus Triska <triska <at> metalevel.at> writes:

> Why could Eli not reproduce it though?

Presumably he evaluated the form with the current directory in the
directory the file was in.

Message #24 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1;
 image-size sometimes yields a wrong image size in pixels
Date: Wed, 28 Sep 2022 20:09:21 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Presumably he evaluated the form with the current directory in the
> directory the file was in.

That's what I did too, and yet I only get (30 . 30) as I reported.
I used $ emacs -Q in the same directory where the image resides.

Message #27 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: larsi <at> gnus.org, 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1;
 image-size sometimes yields a wrong image size in pixels
Date: Wed, 28 Sep 2022 21:43:37 +0300

> Cc: 52931 <at> debbugs.gnu.org
> From: Markus Triska <triska <at> metalevel.at>
> Date: Wed, 28 Sep 2022 20:09:21 +0200
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > Presumably he evaluated the form with the current directory in the
> > directory the file was in.
> 
> That's what I did too, and yet I only get (30 . 30) as I reported.
> I used $ emacs -Q in the same directory where the image resides.

Do you get this if the image file name is in absolute form, with all
the leading directories?

Message #30 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1;
 image-size sometimes yields a wrong image size in pixels
Date: Wed, 28 Sep 2022 20:57:13 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Do you get this if the image file name is in absolute form, with all
> the leading directories?

No: Using an absolute file name, or a file name that starts with "~"
works as expected. For you, using a relative file also worked?

Message #33 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: triska <at> metalevel.at, 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1;
 image-size sometimes yields a wrong image size in pixels
Date: Wed, 28 Sep 2022 22:10:00 +0300

> Cc: 52931 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 28 Sep 2022 19:28:03 +0200
> 
> Markus Triska <triska <at> metalevel.at> writes:
> 
> > Why could Eli not reproduce it though?
> 
> Presumably he evaluated the form with the current directory in the
> directory the file was in.

Relative file names of images aren't expanded against the current
directory.  I guess this factoid is part of the problem.

Message #36 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: larsi <at> gnus.org, 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1;
 image-size sometimes yields a wrong image size in pixels
Date: Wed, 28 Sep 2022 22:12:49 +0300

> From: Markus Triska <triska <at> metalevel.at>
> Cc: larsi <at> gnus.org,  52931 <at> debbugs.gnu.org
> Date: Wed, 28 Sep 2022 20:57:13 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Do you get this if the image file name is in absolute form, with all
> > the leading directories?
> 
> No: Using an absolute file name, or a file name that starts with "~"
> works as expected. For you, using a relative file also worked?

It will, if the file is in the "right" place.

What do you think Emacs does when you use relative image file names in
create-image?

Message #39 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1;
 image-size sometimes yields a wrong image size in pixels
Date: Wed, 28 Sep 2022 22:09:24 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> What do you think Emacs does when you use relative image file names in
> create-image?

I would hope it does the same thing it does for every other function I
know where relative file names are used: Use the file from the current
working directory, i.e., default-directory. However, as far as I can
tell, create-image is currently unexpectedly not doing this reliably, or
at least not on OSX, even though it seems to do it on your system.

Message #42 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: larsi <at> gnus.org, 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1;
 image-size sometimes yields a wrong image size in pixels
Date: Thu, 29 Sep 2022 08:44:06 +0300

> From: Markus Triska <triska <at> metalevel.at>
> Cc: larsi <at> gnus.org,  52931 <at> debbugs.gnu.org
> Date: Wed, 28 Sep 2022 22:09:24 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > What do you think Emacs does when you use relative image file names in
> > create-image?
> 
> I would hope it does the same thing it does for every other function I
> know where relative file names are used: Use the file from the current
> working directory, i.e., default-directory.

No, it doesn't do that.  It looks up relative file names along
image-load-path.  The reason is that image files are many times
displayed on the tool bar and the fringes, which are not specific to a
buffer, and thus we cannot possibly ensure default-directory is always
set to the right place when we display those.

> However, as far as I can tell, create-image is currently
> unexpectedly not doing this reliably, or at least not on OSX, even
> though it seems to do it on your system.

I used an absolute file name in my tests, because, obviously, the file
you posted doesn't live here in the same directory as on your system.

So I think we now understand the reason for the problem, and there's
nothing else we should do here.

Message #45 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Markus Triska <triska <at> metalevel.at>
Cc: larsi <at> gnus.org, 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1; image-size sometimes yields a wrong image size
 in pixels
Date: Thu, 29 Sep 2022 06:15:01 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> No, it doesn't do that.  It looks up relative file names along
> image-load-path.  The reason is that image files are many times
> displayed on the tool bar and the fringes, which are not specific to a
> buffer, and thus we cannot possibly ensure default-directory is always
> set to the right place when we display those.

The `create-image' docstring says:

    Image file names that are not absolute are searched for in the
    "images" sub-directory of ‘data-directory’ and
    ‘x-bitmap-file-path’ (in that order).

Does this need clarifying?

Message #48 received at 52931 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: larsi <at> gnus.org, triska <at> metalevel.at, 52931 <at> debbugs.gnu.org
Subject: Re: bug#52931: 27.1; image-size sometimes yields a wrong image size
 in pixels
Date: Thu, 29 Sep 2022 16:28:57 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 29 Sep 2022 06:15:01 -0700
> Cc: larsi <at> gnus.org, 52931 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > No, it doesn't do that.  It looks up relative file names along
> > image-load-path.  The reason is that image files are many times
> > displayed on the tool bar and the fringes, which are not specific to a
> > buffer, and thus we cannot possibly ensure default-directory is always
> > set to the right place when we display those.
> 
> The `create-image' docstring says:
> 
>     Image file names that are not absolute are searched for in the
>     "images" sub-directory of ‘data-directory’ and
>     ‘x-bitmap-file-path’ (in that order).
> 
> Does this need clarifying?

I added a more accurate sentence there:

    "Create an image from FILE-OR-DATA.
  FILE-OR-DATA is an image file name or image data.  If it is a relative
  file name, the function will look for it along `image-load-path'.

But I failed to remove the one you mention, which is somewhat
misleading.  Now done.

Previous Next

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