GNU bug report logs -
#51381
HEIF image format support
Previous Next
Reported by: Stefan Kangas <stefan <at> marxist.se>
Date: Mon, 25 Oct 2021 03:39:02 UTC
Severity: wishlist
Fixed in version 29.1
Done: Stefan Kangas <stefan <at> marxist.se>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51381 in the body.
You can then email your comments to 51381 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Mon, 25 Oct 2021 03:39:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Kangas <stefan <at> marxist.se>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 25 Oct 2021 03:39:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Severity: wishlist
Apple seems to have moved over to use the HEIF image format. It seems
like Canon is also trying to push this for their cameras, and it is
being presented as a "JPEG replacement".
Whatever we think of that, this means that many unsuspecting Emacs will
soon be faced with such images.
For example, I stumbled upon this comment from one user:
"I have used image-dired from time to time, but less so now since
Apple's default image type is .heic. I can't open these images in
the emacs-mac (Mitsuharo's version).
"Is there any work ongoing to natively open .heic in Emacs?"
https://www.reddit.com/r/emacs/comments/nzxms5/comment/h1vbepq/
GIMP, imagemagick, krita, nomacs, etc. have added HEIC support using the
LGPLv3 licensed library libheif.[1]
See more about where it is supported here:
https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format#Support
Should Emacs have built-in support for the HEIC image format? Would it
be welcome if someone wrote up a patch for it?
Footnotes:
[1] https://github.com/strukturag/libheif
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Mon, 25 Oct 2021 04:06:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 51381 <at> debbugs.gnu.org (full text, mbox):
On Mon, 25 Oct 2021 12:38:00 +0900,
Stefan Kangas wrote:
>
> For example, I stumbled upon this comment from one user:
>
> "I have used image-dired from time to time, but less so now since
> Apple's default image type is .heic. I can't open these images in
> the emacs-mac (Mitsuharo's version).
As the Mac port supports image types the Image I/O framework can
handle, HEIC images can be displayed on macOS 10.15 and later. You
need the following setting mentioned in the info node "Mac Images":
(when (and (image-type-available-p 'image-io)
(not (boundp 'imagemagick-render-type)))
;; Image I/O is used as a fallback of ImageMagick.
(setq imagemagick-enabled-types t)
(setq imagemagick-types-inhibit
(cons 'XML (delq 'PDF imagemagick-types-inhibit)))
(imagemagick-register-types))
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Mon, 25 Oct 2021 08:51:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 51381 <at> debbugs.gnu.org (full text, mbox):
On Mon, 25 Oct 2021 13:05:45 +0900,
YAMAMOTO Mitsuharu wrote:
>
> As the Mac port supports image types the Image I/O framework can
> handle, HEIC images can be displayed on macOS 10.15 and later.
Actually, HEIC is supported on macOS 10.13 and later; HEICS support is
added in macOS 10.15.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Mon, 25 Oct 2021 15:23:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
> Apple seems to have moved over to use the HEIF image format. It seems
> like Canon is also trying to push this for their cameras, and it is
> being presented as a "JPEG replacement".
>
> Whatever we think of that, this means that many unsuspecting Emacs will
> soon be faced with such images.
Probably mostly Apple users, and has already been noted, Emacs on Macos
already understands all image formats that the OS supports.
> Should Emacs have built-in support for the HEIC image format? Would it
> be welcome if someone wrote up a patch for it?
I think it's too niche to warrant adding full-fledged support for it,
but image-convert.el supports it (if the external utilities do). I've
now added .heic to auto-mode-alist so that this should work
automatically.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Mon, 25 Oct 2021 15:35:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I think it's too niche to warrant adding full-fledged support for it,
> but image-convert.el supports it (if the external utilities do). I've
> now added .heic to auto-mode-alist so that this should work
> automatically.
Sounds good to me. Could we back-port that fix to emacs-28?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Mon, 25 Oct 2021 15:47:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> I think it's too niche to warrant adding full-fledged support for it,
>> but image-convert.el supports it (if the external utilities do). I've
>> now added .heic to auto-mode-alist so that this should work
>> automatically.
>
> Sounds good to me. Could we back-port that fix to emacs-28?
Uhm... I guess it does sound unlikely to regress anything, but I think
it's too late in the release cycle to add even that. I mean, there
could be someone out there that has .heic files that are something else.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Mon, 25 Oct 2021 19:38:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Uhm... I guess it does sound unlikely to regress anything, but I think
> it's too late in the release cycle to add even that. I mean, there
> could be someone out there that has .heic files that are something else.
OK, I understand. Thanks for fixing this on master!
I don't think there is anything more to do here, is there? The fix you
installed is all there is to it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Mon, 25 Oct 2021 19:41:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
> I don't think there is anything more to do here, is there? The fix you
> installed is all there is to it?
Yup. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Mon, 25 Oct 2021 21:37:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen wrote:
> Probably mostly Apple users, and has already been noted, Emacs on Macos
> already understands all image formats that the OS supports.
The previous comments refer to image support in the "Mac port",
which is not mainline GNU Emacs. (I have always thought it a confusing
name.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Mon, 25 Oct 2021 21:44:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> The previous comments refer to image support in the "Mac port",
> which is not mainline GNU Emacs. (I have always thought it a confusing
> name.)
Oh! Hm. Well, I thought mainline Emacs also used the OS facilities to
render images, but I may well be wrong. Alan?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Tue, 26 Oct 2021 10:16:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 51381 <at> debbugs.gnu.org (full text, mbox):
On Mon, Oct 25, 2021 at 11:43:01PM +0200, Lars Ingebrigtsen wrote:
> Glenn Morris <rgm <at> gnu.org> writes:
>
> > The previous comments refer to image support in the "Mac port",
> > which is not mainline GNU Emacs. (I have always thought it a confusing
> > name.)
>
> Oh! Hm. Well, I thought mainline Emacs also used the OS facilities to
> render images, but I may well be wrong. Alan?
Yeah, but we need to teach Emacs about the image format. I'm not sure
how to do that. I once tried to teach it to load PDFs using *step
functionality and failed miserably. This is the same.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Wed, 27 Oct 2021 13:07:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> Yeah, but we need to teach Emacs about the image format. I'm not sure
> how to do that. I once tried to teach it to load PDFs using *step
> functionality and failed miserably. This is the same.
Is there any chance we can entice the MacPorts people to fix this in
mainline Emacs? (I'm just wildly assuming that this works there,
without having actually had a peek.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Wed, 27 Oct 2021 16:14:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 51381 <at> debbugs.gnu.org (full text, mbox):
On Wed, Oct 27, 2021 at 03:06:14PM +0200, Lars Ingebrigtsen wrote:
> Alan Third <alan <at> idiocy.org> writes:
>
> > Yeah, but we need to teach Emacs about the image format. I'm not sure
> > how to do that. I once tried to teach it to load PDFs using *step
> > functionality and failed miserably. This is the same.
>
> Is there any chance we can entice the MacPorts people to fix this in
> mainline Emacs? (I'm just wildly assuming that this works there,
> without having actually had a peek.)
When you say MacPorts do you actually mean the Emacs Mac port by
Yamamoto Mitsuharu? I'm not sure he'd care much for working on the NS
port, but you can always ask.
FWIW NSImage (on macOS) is already capable of loading an heic file, if
we just point it to it. I thought all we needed to do is add heic to
ns_can_use_native_image_api in nsimage.m and then load an image with
the type of "heic" or whatever, but it doesn't work and I'm not sure
what else I need to do. Probably define heic as a type elsewhere.
But aside from all of that, is heic supported on a Free OS yet?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Wed, 27 Oct 2021 16:26:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> When you say MacPorts do you actually mean the Emacs Mac port by
> Yamamoto Mitsuharu? I'm not sure he'd care much for working on the NS
> port, but you can always ask.
Yes, that's that what/who I was thinking of... Macports is something
else, come to think of it. :-)
> FWIW NSImage (on macOS) is already capable of loading an heic file, if
> we just point it to it. I thought all we needed to do is add heic to
> ns_can_use_native_image_api in nsimage.m and then load an image with
> the type of "heic" or whatever, but it doesn't work and I'm not sure
> what else I need to do. Probably define heic as a type elsewhere.
>
> But aside from all of that, is heic supported on a Free OS yet?
Yes, imagemagick supports it, so (via image-convert and the external
commands) Emacs can display heic on Debian, for instance.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Wed, 27 Oct 2021 19:15:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Yes, imagemagick supports it, so (via image-convert and the external
> commands) Emacs can display heic on Debian, for instance.
Just to point out that we prefer GraphicsMagick to ImageMagick if it is
installed. Which is a good thing: it has better performance, security
track record, and fewer dependencies.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Thu, 28 Oct 2021 21:01:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Yup. :-)
I finally got around to testing this, with an image from
https://github.com/nokiatech/heif_conformance
on current master:
0. curl --output /tmp/C001.heic
https://raw.githubusercontent.com/nokiatech/heif_conformance/master/conformance_files/C001.heic
1. emacs -Q --eval '(setq image-use-external-converter t)' /tmp/C001.heic
But I get the error message "Unknown image type", and nothing else.
I also tried image1.heic from here:
https://github.com/tigranbs/test-heic-images
with the same result.
Am I doing something wrong? I have all three of GraphicsMagick, ffmpeg
and ImageMagick installed AFAICT.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Thu, 28 Oct 2021 21:15:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
>> Yes, imagemagick supports it, so (via image-convert and the external
>> commands) Emacs can display heic on Debian, for instance.
>
> Just to point out that we prefer GraphicsMagick to ImageMagick if it is
> installed. Which is a good thing: it has better performance, security
> track record, and fewer dependencies.
Yes, GraphicsMagick is better all over. But as usual, ImageMagick is
first out with support for the new shiny thing -- GraphicsMagick (in
Debian/bookworm, at least) does not support .heic, but ImageMagick does.
Stefan Kangas <stefan <at> marxist.se> writes:
> 1. emacs -Q --eval '(setq image-use-external-converter t)' /tmp/C001.heic
>
> But I get the error message "Unknown image type", and nothing else.
It probably autodetects GraphicsMagick? The logic doesn't look for
support per image format, but just uses one of the three.
Try setting `image-converter' to `imagemagick' and restart Emacs.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Thu, 28 Oct 2021 22:19:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> It probably autodetects GraphicsMagick? The logic doesn't look for
> support per image format, but just uses one of the three.
>
> Try setting `image-converter' to `imagemagick' and restart Emacs.
Aha! Yup, that works.
I have three questions:
A) If e.g. GraphicsMagick fails, shouldn't we try falling back to the
other converters?
B) Could the above error message be better? For example, could it say
which image converter(s) we tried?
C) Shouldn't `image-use-external-converter' be t by default?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 05:29:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 51381 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Thu, 28 Oct 2021 14:00:32 -0700
> Cc: 51381 <at> debbugs.gnu.org
>
> https://github.com/nokiatech/heif_conformance
>
> on current master:
>
> 0. curl --output /tmp/C001.heic
> https://raw.githubusercontent.com/nokiatech/heif_conformance/master/conformance_files/C001.heic
> 1. emacs -Q --eval '(setq image-use-external-converter t)' /tmp/C001.heic
>
> But I get the error message "Unknown image type", and nothing else.
Why do we prefer external-converter for this, instead of having those
images supported natively? I thought we wanted to move away of
ImageMagick dependencies?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 12:35:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
> A) If e.g. GraphicsMagick fails, shouldn't we try falling back to the
> other converters?
Sure. We could re-probe the converters when something fails and then
use the other converter, for instance? Or we could just probe every
time, but keep a table of what we've tried.
Or we could probe all the converters at startup, and maintain a mapping
of which converter does what -- that sounds cleanest.
> B) Could the above error message be better? For example, could it say
> which image converter(s) we tried?
Sure. Patches for a) and b) are welcome. :-)
> C) Shouldn't `image-use-external-converter' be t by default?
I dunno... there's security implications.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 12:36:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Why do we prefer external-converter for this, instead of having those
> images supported natively? I thought we wanted to move away of
> ImageMagick dependencies?
We don't want to make Emacs depend on All The C Image Libraries That
Exist. For obscure formats, seldom used, it's fine to use an external
program (if the user wants to).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 13:09:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> We don't want to make Emacs depend on All The C Image Libraries That
> Exist. For obscure formats, seldom used, it's fine to use an external
> program (if the user wants to).
How about supporting the GraphicsMagick library instead of or in
addition to ImageMagick? Or was that already rejected?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 13:09:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> A) If e.g. GraphicsMagick fails, shouldn't we try falling back to the
>> other converters?
>
> Sure. We could re-probe the converters when something fails and then
> use the other converter, for instance? Or we could just probe every
> time, but keep a table of what we've tried.
>
> Or we could probe all the converters at startup, and maintain a mapping
> of which converter does what -- that sounds cleanest.
>
>> B) Could the above error message be better? For example, could it say
>> which image converter(s) we tried?
>
> Sure. Patches for a) and b) are welcome. :-)
OK! I will open two separate bug reports for that.
>> C) Shouldn't `image-use-external-converter' be t by default?
>
> I dunno... there's security implications.
That's true.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 13:20:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas wrote:
> How about supporting the GraphicsMagick library instead of or in
> addition to ImageMagick? Or was that already rejected?
I took no comments in 4+ years as a sign no-one was interested:
https://debbugs.gnu.org/14358
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 13:29:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 51381 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Stefan Kangas <stefan <at> marxist.se>, 51381 <at> debbugs.gnu.org
> Date: Fri, 29 Oct 2021 14:35:20 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Why do we prefer external-converter for this, instead of having those
> > images supported natively? I thought we wanted to move away of
> > ImageMagick dependencies?
>
> We don't want to make Emacs depend on All The C Image Libraries That
> Exist. For obscure formats, seldom used, it's fine to use an external
> program (if the user wants to).
Is HEIF an "obscure format"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 13:38:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Is HEIF an "obscure format"?
Outside of Mac users -- very. (And on Mac, the OS displays all the
images.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 13:55:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 51381 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: stefan <at> marxist.se, 51381 <at> debbugs.gnu.org
> Date: Fri, 29 Oct 2021 15:37:02 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Is HEIF an "obscure format"?
>
> Outside of Mac users -- very. (And on Mac, the OS displays all the
> images.)
Then why are you spending so much time on this subject, which AFAIU is
not about Mac?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 14:08:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Then why are you spending so much time on this subject
Am I? I wasn't aware.
> , which AFAIU is not about Mac?
It's both about Mac and not.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 14:11:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Is HEIF an "obscure format"?
I'm not sure. Adoption seems to be picking up:
https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format#Support
> Outside of Mac users -- very. (And on Mac, the OS displays all the
> images.)
But note that interoperability with Mac (and iOS, where you explicitly
have to turn HEIF off if you don't want it) is pretty important even to
GNU/Linux users.
But I also don't see it as a major problem (just a small one) if we give
it a year or three to see if this format really starts to really pick up.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 14:15:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 51381 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: stefan <at> marxist.se, 51381 <at> debbugs.gnu.org
> Date: Fri, 29 Oct 2021 16:06:48 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Then why are you spending so much time on this subject
>
> Am I? I wasn't aware.
This thread amassed 3 dozens of messages.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 29 Oct 2021 14:16:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > Then why are you spending so much time on this subject
>>
>> Am I? I wasn't aware.
>
> This thread amassed 3 dozens of messages.
I'm very efficient.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Sat, 30 Oct 2021 16:22:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> Stefan Kangas wrote:
>
>> How about supporting the GraphicsMagick library instead of or in
>> addition to ImageMagick? Or was that already rejected?
>
> I took no comments in 4+ years as a sign no-one was interested:
> https://debbugs.gnu.org/14358
Thanks, Glenn. I will reopen that bug to see if the situation has
changed since 2014.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Sat, 30 Oct 2021 16:38:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 51381 <at> debbugs.gnu.org (full text, mbox):
close 51381 29.1
thanks
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> I don't think there is anything more to do here, is there? The fix you
>> installed is all there is to it?
>
> Yup. :-)
I'm therefore closing this bug. There was some discussion about how the
native support for HEIC fails on macOS, but that's a separate issue. If
anyone wants to look into it, I recommend opening a new bug report.
bug marked as fixed in version 29.1, send any further explanations to
51381 <at> debbugs.gnu.org and Stefan Kangas <stefan <at> marxist.se>
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Sat, 30 Oct 2021 16:38:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 26 Nov 2021 13:03:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 51381 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Oct 27, 2021 at 05:13:17PM +0100, Alan Third wrote:
>
> FWIW NSImage (on macOS) is already capable of loading an heic file, if
> we just point it to it. I thought all we needed to do is add heic to
> ns_can_use_native_image_api in nsimage.m and then load an image with
> the type of "heic" or whatever, but it doesn't work and I'm not sure
> what else I need to do. Probably define heic as a type elsewhere.
Patch attached. I'm not entirely sure this won't break anything, so
testing on a platform that already supports heif files would probably
be a good idea.
It doesn't support any of the interesting features of heif, for
example it doesn't allow you to view multiple images (like an animated
gif), but I have a suspicion the IM/GM code won't support that anyway,
so no great loss.
--
Alan Third
[0001-Add-native-HEIC-support-on-macOS-bug-51381.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Fri, 26 Nov 2021 14:09:01 GMT)
Full text and
rfc822 format available.
Message #109 received at 51381 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> Patch attached. I'm not entirely sure this won't break anything, so
> testing on a platform that already supports heif files would probably
> be a good idea.
Works fine for me on my M1 Apple laptop.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Wed, 22 Dec 2021 20:54:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 51381 <at> debbugs.gnu.org (full text, mbox):
On Fri, Nov 26, 2021 at 01:02:28PM +0000, Alan Third wrote:
> On Wed, Oct 27, 2021 at 05:13:17PM +0100, Alan Third wrote:
> >
> > FWIW NSImage (on macOS) is already capable of loading an heic file, if
> > we just point it to it. I thought all we needed to do is add heic to
> > ns_can_use_native_image_api in nsimage.m and then load an image with
> > the type of "heic" or whatever, but it doesn't work and I'm not sure
> > what else I need to do. Probably define heic as a type elsewhere.
>
> Patch attached. I'm not entirely sure this won't break anything, so
> testing on a platform that already supports heif files would probably
> be a good idea.
>
> It doesn't support any of the interesting features of heif, for
> example it doesn't allow you to view multiple images (like an animated
> gif), but I have a suspicion the IM/GM code won't support that anyway,
> so no great loss.
Since nobody complained I've pushed this to master.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#51381
; Package
emacs
.
(Sat, 25 Dec 2021 16:21:03 GMT)
Full text and
rfc822 format available.
Message #115 received at 51381-done <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
>> Patch attached. I'm not entirely sure this won't break anything, so
>> testing on a platform that already supports heif files would probably
>> be a good idea.
>>
>> It doesn't support any of the interesting features of heif, for
>> example it doesn't allow you to view multiple images (like an animated
>> gif), but I have a suspicion the IM/GM code won't support that anyway,
>> so no great loss.
>
> Since nobody complained I've pushed this to master.
Thanks. I guess there is nothing more to do here, so I'm closing this
bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 23 Jan 2022 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 149 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.