bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Markus Triska]

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

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Eli Zaretskii]

> From: Markus Triska <triska@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?

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Lars Ingebrigtsen]

Markus Triska <triska@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.

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Markus Triska]

Lars Ingebrigtsen <larsi@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

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Lars Ingebrigtsen]

Markus Triska <triska@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.

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Markus Triska]

Lars Ingebrigtsen <larsi@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.

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Eli Zaretskii]

> Cc: 52931@debbugs.gnu.org
> From: Markus Triska <triska@metalevel.at>
> Date: Wed, 28 Sep 2022 20:09:21 +0200
> 
> Lars Ingebrigtsen <larsi@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?

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Markus Triska]

Eli Zaretskii <eliz@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?

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Eli Zaretskii]

> Cc: 52931@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 28 Sep 2022 19:28:03 +0200
> 
> Markus Triska <triska@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.

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: larsi@gnus.org,  52931@debbugs.gnu.org
> Date: Wed, 28 Sep 2022 20:57:13 +0200
> 
> Eli Zaretskii <eliz@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?

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Markus Triska]

Eli Zaretskii <eliz@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.

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: larsi@gnus.org,  52931@debbugs.gnu.org
> Date: Wed, 28 Sep 2022 22:09:24 +0200
> 
> Eli Zaretskii <eliz@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.

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Stefan Kangas]

Eli Zaretskii <eliz@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?

bug#52931: 27.1; image-size sometimes yields a wrong image size in pixels

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 29 Sep 2022 06:15:01 -0700
> Cc: larsi@gnus.org, 52931@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@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.