bug#44172: 28.0.50; Exporting image data

bug#44172: 28.0.50; Exporting image data

[Lars Ingebrigtsen]

There's been some discussion off-list about adding simple image
manipulation functions to Emacs, and there's really only three
transforms that are in scope for Emacs: Cropping, rotating and resizing.

Now, there are packages out there that allow doing this, but they rely
on external programs to actually do the image wrangling.  I wondered
what it would take to make it possible to do this in-Emacs, and I think
we basically have all the needed stuff -- we just need to hook it up and
make it available.

1) Making image data available to Emacs Lisp.

This is something that I've often wanted for other reasons -- I want to
know how an SVG was rendered, for instance (especially when doing
font-based stuff), and there's no way to actually tell.

So I think Emacs should have a function like

(export-image-data IMAGE &rest SPECS)

that will just take the image cache data for IMAGE (or the frame
specified by SPECS, if multi-frame) and dump the RGB(A) data into the
current buffer (which should be unibyte, for efficiency), and return
a plist of width/height/bytes-per-pixel/rgb(a) ordering.  This is
basically the PPM binary format, but without the heading.

This allows us to do easy transforms like cropping and rotating from
Lisp, too.

2) Create image files.

But mogrifying images is all well and good, but if we can't save the
data, it's not much use.  Of course we could just save the data as PPM,
but that's not very helpful.  So Emacs needs to be able to write image
files...  which sounds like a big thing, but it isn't really: As long as
we can save .jpeg and .png files, that's fine.

Fortunately, Emacs links with libpng and libjpeg already, so adding a

(encode-image-data TYPE)

function is less work than it would seem.




In GNU Emacs 28.0.50 (build 124, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
 of 2020-10-22 built on xo
Repository revision: 954a4decfcc8e41084789516773b22d0adc11d91
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44172: 28.0.50; Exporting image data

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 23 Oct 2020 13:18:40 +0200
> 
> 2) Create image files.

Doesn't svg.el come close enough?

bug#44172: 28.0.50; Exporting image data

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Doesn't svg.el come close enough?

Not really -- if you have an image you've cropped, you can certainly
write it out as .svg, but it'd be huge.  Then PPM would be preferable.
But neither are much good, in general.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44172: 28.0.50; Exporting image data

[Alan Third]

On Fri, Oct 23, 2020 at 01:18:40PM +0200, Lars Ingebrigtsen wrote:
> 
> 1) Making image data available to Emacs Lisp.
> 
> This is something that I've often wanted for other reasons -- I want to
> know how an SVG was rendered, for instance (especially when doing
> font-based stuff), and there's no way to actually tell.
> 
> So I think Emacs should have a function like
> 
> (export-image-data IMAGE &rest SPECS)
> 
> that will just take the image cache data for IMAGE (or the frame
> specified by SPECS, if multi-frame) and dump the RGB(A) data into the
> current buffer (which should be unibyte, for efficiency), and return
> a plist of width/height/bytes-per-pixel/rgb(a) ordering.  This is
> basically the PPM binary format, but without the heading.
> 
> This allows us to do easy transforms like cropping and rotating from
> Lisp, too.

Are you talking about using an image spec that we use to display
images, which can already include rotation and resizing?

That would be difficult because the stored image data doesn't have
those transformations applied, unless you're using imagemagick. We'd
have to draw it to a buffer (either on-screen or off) and then read
back that data.

-- 
Alan Third

bug#44172: 28.0.50; Exporting image data

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> Are you talking about using an image spec that we use to display
> images, which can already include rotation and resizing?

Yes.

> That would be difficult because the stored image data doesn't have
> those transformations applied, unless you're using imagemagick. We'd
> have to draw it to a buffer (either on-screen or off) and then read
> back that data.

But it's the untransformed data that we'd want here, so that sounds
great to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44172: 28.0.50; Exporting image data

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> There's been some discussion off-list about adding simple image
> manipulation functions to Emacs, and there's really only three
> transforms that are in scope for Emacs: Cropping, rotating and resizing.

I think we should have a special `image-edit-mode' to support this.  We
could have a keybinding to go to between that mode and `image-mode' (say
`C-x C-q').

In the short-term, I think `image-mode' should stop pretending it can
edit images by making `image-save' into an obsolete alias for
`write-file'.

bug#44172: 28.0.50; Exporting image data

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> In the short-term, I think `image-mode' should stop pretending it can
> edit images by making `image-save' into an obsolete alias for
> `write-file'.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44172: 28.0.50; Exporting image data

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> In the short-term, I think `image-mode' should stop pretending it can
>> edit images by making `image-save' into an obsolete alias for
>> `write-file'.
>
> Yup.

Oops, this doesn't actually work though, does it?  For example,
`image-save' is also what gives us a command to save images in eww.

bug#44172: 28.0.50; Exporting image data

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>>> In the short-term, I think `image-mode' should stop pretending it can
>>> edit images by making `image-save' into an obsolete alias for
>>> `write-file'.
>>
>> Yup.
>
> Oops, this doesn't actually work though, does it?  For example,
> `image-save' is also what gives us a command to save images in eww.

Oh, `image-save'!  No, that can't be deprecated.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44172: bug#49347: image-save not working as expected for transformed image saving!

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oh, `image-save'!  No, that can't be deprecated.

Maybe we should remove the key binding from `image-mode' though?
Or is it useful in `image-mode' buffers?

bug#44172: bug#49347: image-save not working as expected for transformed image saving!

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Oh, `image-save'!  No, that can't be deprecated.
>
> Maybe we should remove the key binding from `image-mode' though?
> Or is it useful in `image-mode' buffers?

It's not very useful in `image-mode' buffers, but it's nice for
consistency, perhaps?  I think whenever you see an image in Emacs, you
should be able to interact with it that way.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44172: bug#49347: image-save not working as expected for transformed image saving!

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It's not very useful in `image-mode' buffers, but it's nice for
> consistency, perhaps?  I think whenever you see an image in Emacs, you
> should be able to interact with it that way.

I'm all for consistency, but in this case I think it confuses more than
it helps.  Actually, to explain what I think, "rotate" is an even better
example than "save", so please bear with me:

- eww: I'm hard-pressed to think of a case when I have ever wanted to
  rotate an image on a website.

- image-dired-thumbnail-mode: the thumbnails are currently rotatable,
  but that just makes it go out of synch with the picture.

- In the icons.el library I'm working on, we will use SVG images as
  icons.  They should not rotate on "r".  The same goes for the logo on
  the about/splash screen, etc.

IOW, I think we should consider "what might the user want to do with an
image here?" and then provide the bindings to do that.  The consistency
I would go for is more along the line of "every time you rotate an
image, it is the 'r' key" rather than "you can always rotate an image,
anywhere, even if it makes no sense".

For `image-save' specifically, I think this command makes sense in eww
as you will obviously want to be able to save images from websites.
I also think it would make obvious sense in a new `image-edit-mode'.

But I don't see that it makes sense in `image-mode' that is
fundamentally about displaying an image in various ways, and where users
might be lead to think that any activated display options (scaling,
etc.) will be reflected in a saved file.

bug#44172: bug#49347: image-save not working as expected for transformed image saving!

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> - eww: I'm hard-pressed to think of a case when I have ever wanted to
>   rotate an image on a website.

I do that all the time.  :-)  Well, OK, not all the time, but it's
happened more than once when people post upside-down images for the lulz.

> For `image-save' specifically, I think this command makes sense in eww
> as you will obviously want to be able to save images from websites.
> I also think it would make obvious sense in a new `image-edit-mode'.

I think whenever a user sees an image in Emacs, they should be able to
save it somewhere so that they can use it for something else.

> But I don't see that it makes sense in `image-mode' that is
> fundamentally about displaying an image in various ways, and where users
> might be lead to think that any activated display options (scaling,
> etc.) will be reflected in a saved file.

I see your point.  I have no strong opinions on whether these bindings
should be in image-mode, too -- if they're too confusing, we can remove
them there.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no