Bug 114532 (WebP) - add support for WEBP image reading (image import and inside .ods/.odt)
Summary: add support for WEBP image reading (image import and inside .ods/.odt)
Status: VERIFIED FIXED
Alias: WebP
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:7.4.0
Keywords:
: 108147 130759 140440 149317 (view as bug list)
Depends on:
Blocks: Format-Filters 143154
  Show dependency treegraph
 
Reported: 2017-12-18 12:18 UTC by squeezechart
Modified: 2022-06-19 12:48 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description squeezechart 2017-12-18 12:18:10 UTC
please add support for WEBP image format (image import and inside .ods/.odt)

https://developers.google.com/speed/webp/

It is a modern, free and open image format (Apache 2.0 License).
WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.
Comment 1 Heiko Tietze 2018-01-02 09:00:58 UTC
Discussion has been done in bug 114533 with the recommendation to not implement this filter.
Comment 2 Buovjaga 2020-02-18 14:59:10 UTC
*** Bug 130759 has been marked as a duplicate of this bug. ***
Comment 3 Ming Hua 2020-12-05 08:04:59 UTC
*** Bug 108147 has been marked as a duplicate of this bug. ***
Comment 4 Buovjaga 2021-02-16 08:46:13 UTC
*** Bug 140440 has been marked as a duplicate of this bug. ***
Comment 5 Telesto 2021-02-16 15:36:00 UTC
Tendency to ask for re-evaluation.. 
Based on partial reading of bug 114533 comment 6. Bug reports coming in.. And this format really becoming more common.. I'm seeing ostrich with head the sand in front of me already :P. Mentally of course, because the image being saved in WEBP and Writer/Draw/Impress/Calc won't render :-)
Comment 6 Philippe Morin 2021-03-23 20:45:03 UTC
I am French-speaking end-user who want to confirm this is a good feature request. I'm using LibreOffice Draw right now and I had to convert files from webp to png because WEBP wouldn't work. The file I'm working on is some kind of tech tree (personal project) for a video game and I took the files on a MediaWiki-based wiki.

I think such feature would empowering for end-users.
Comment 7 Philippe Morin 2021-03-23 21:13:30 UTC
I want to report a new experience I just had...

I tried dragging and dropping a WEBP picture from this page(https://subnautica.fandom.com/wiki/Fabricator#Basic_Materials) directly into my Draw Gallery (which I started using today). While the WEBP picture does appear as a working thumbnail, it doesn't behave like the PNG files I converted.

Expected behaviour:
Previously drag-dropped (from a webpage) WEBP picture in the Draw Gallery will be added to a page when dragged-dropped into it, or when using the "Insert" option from the contextual menu.

Observed behaviour:
Previously drag-dropped (from a webpage) WEBP picture in the Draw Gallery WON'T BE added to a page when dragged-dropped into it, or when using the "Insert" option from the contextual menu. Instead, a "Object image vide" (sorry, French UI) will be inserted (at least that's what the "Undo" option displays.

Let me conclude: I often saw end-users adding files from a web page by dragging-dropping them into their document. Someone like me could even decide to start a gallery with pictures in mixed formats. Adding WEBP would prevent poor UX.
Comment 8 Heiko Tietze 2021-03-24 08:30:46 UTC
(In reply to Philippe Morin from comment #7)
> I tried dragging and dropping a WEBP picture from ...
> Adding WEBP would prevent poor UX.

Good point
Comment 9 launchpad 2021-03-24 13:20:53 UTC
In addition to webp, which has been supported by major web browsers for a long time now, we need support for avif, which is supported by Chrome now and will also be supported in Firefox 87 (at the end of this month).

AVIF has Landed! :
https://jakearchibald.com/2020/avif-has-landed/
Comment 10 Philippe Morin 2021-03-24 13:25:47 UTC
(In reply to launchpad from comment #9)
> In addition to webp, which has been supported by major web browsers for a
> long time now, we need support for avif
+1
Comment 11 launchpad 2021-03-24 13:32:09 UTC
WEBP Support in Web Browsers:
https://caniuse.com/webp

AVIF Support in Web Browsers:
https://caniuse.com/avif
Comment 12 BogdanB 2021-06-19 14:05:19 UTC
Inserting a "webp" file is getting a "unknown image format" info in LibreOffice. Tested in Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 51754ca5349d7bf655d57ded37381188d0bc4bcf
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

"Support for the format has increased over the years, and as of May 2021 WebP was supported by 94% of the web browsers in use worldwide".[7] - https://en.wikipedia.org/wiki/WebP
Comment 13 David D Lowe 2021-07-28 14:55:53 UTC Comment hidden (me-too)
Comment 14 Thierry 2022-01-15 11:37:22 UTC
Any chance to get this format supported in a future release ?
Comment 15 Timur 2022-01-16 06:42:30 UTC
I will mark this as High. No really need to wait for 3 more duplicates and 3 more years... But it still requires a volunteer dev, unless someone pays.
Comment 16 Miklos Vajna 2022-01-19 13:25:05 UTC
Lubos is looking at this.
Comment 17 Commit Notification 2022-01-31 09:45:26 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/60eaa424c5e213f31227008e1ed66a646491a360

support for the WebP image format (tdf#114532)

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Luboš Luňák 2022-02-01 10:37:29 UTC
As the commit message says, my commit adds full WebP support except for embedding in .ods/.odt documents, as that would make them unreadable by versions not having WebP support.
Comment 19 phv 2022-02-01 11:42:46 UTC
First of all, thank you for this work.

What I'm experiencing is that the WebP image is converted to PNG, so with a weight up to 50% higher, when saved inside a .odt document

Could we consider that the expert configuration option "AddReplacementImage" disable this conversion, as it does currently with SVG images?

I regret not being able to take full advantage of this new feature.
Comment 20 Timur 2022-02-01 12:58:21 UTC
If someone uses a new LO 7.4 when it's out and embeds WebP .ods/.odt and sends that file to someone else or opens it on other computer, I guess it would be logical and intuitive that there must also be LO 7.4. 
So I don't see a need for a delay from comment 18. It's a new feature, not modifying existing behavior. I'd prefer to see all completed and bug closed.
Comment 21 Aron Budea 2022-02-01 16:13:04 UTC
(In reply to Timur from comment #20)
> If someone uses a new LO 7.4 when it's out and embeds WebP .ods/.odt and
> sends that file to someone else or opens it on other computer, I guess it
> would be logical and intuitive that there must also be LO 7.4. 
It's not that simple, you might not even know you're adding a WebP to the document, eg. when copying a thumbnail from Wikipedia and pasting it into LO, a WebP format image is on the clipboard. Or even if you know when you add a WebP image to your document yourself, it'd be hard to keep track of which of your documents contained WebP images and which ones didn't when sending it around.
Comment 22 Heiko Tietze 2022-02-02 08:54:39 UTC
Would it be possible to automatically convert WebP on paste into something well supported like PNG?
Comment 23 phv 2022-02-02 12:12:28 UTC
I'm one of those who complain when LibreOffice converts data without warning; whether it's vector images transformed into raster or formula formatting lost with fodt file.

Let's take the case of a user who, reading that LibreOffice now supports the new image file format, converts all JPEG images to WebP, but it results in a much heavier file because the software does convert WebP to PNG: he will either report the bug or regret that the software didn't say anything.

I cannot stress enough the importance of communicating with the user, to let him choose what to do; but don't do it without him knowing at the risk of losing trust.

Why not add a popup that appears when saving to inform about the image file format incompatibility with older LibreOffice versions?
Comment 24 Mike Kaganski 2022-02-06 13:55:36 UTC
Please just add a note about automatic conversion into PNG (maybe for some transition period, after which embedding of WebP itself would be expected without any conversion and fallback?) to the release notes. Having something like an infobar with a conversion note is subject for a completely separate issue.
Comment 25 Timur 2022-02-06 15:13:00 UTC Comment hidden (obsolete)
Comment 26 Tomaz Vajngerl 2022-02-07 02:11:10 UTC
So IMHO we should store both WebP and PNG in the document. The reason is that after we decide that WebP has been supported in enough LO versions, we can just turn off saving the additional PNG fallback. Any documents that were created in the mean time with the WebP images will be able to remove the fallback PNG after this with just re-saving the file.

One thing we need to remember is that WebP on the web is mostly used to super-compress the images to save bandwidth, so the images will mostly be using the lossy part of WebP. So if we convert such an image to PNG the size will increase significantly, so storing the original WebP in addition is insignificant compared to the overall size of PNG.

I did a test - a 24MP photo compressed to 80% WebP was giving me 2.6MB. Convert that to PNG at compression level 9 resulted in 33.7MB and it took a looong time to compress. Reducing the compression level to a more typical 5 gave me 35.8MB. So the PNG vs. PNG + WebP is not even 10% increase in size and the size of WebP is similar to the difference between the PNG compression levels.

There is another thing we can do and instead PNG use JPEG in such cases (Lossy WebP), so we would keep WebP and use JPEG for the fallback when opening in the older versions of LibreOffice. JPEG at 80,85,90 is giving me 4MB/5MB/6.6MB, which combined with the original WebP is still less than 1/3 of the PNG.
Comment 27 Mike Kaganski 2022-02-07 06:13:33 UTC
(In reply to Tomaz Vajngerl from comment #26)

TL;DR summary of the following: that is a very dangerous and serves only a couple of users.

The idea to save both formats (one as fallback) would only serve people who have the ultimate goal to get to the original bytes at some unspecified future time. What is the real use case, that would require someone to desperately need the original embedded image bytes, as opposed to a converted copy?

OTOH, there are *real* use cases, that would be served poorly by that decision.
1. People who chose WebP to save space. Well, PNG is not ideal for those; but speculating that 110% is better for those who are unhappy with 100% is not reasonable, right? And we possibly need to have a "convert lossy WebP to" option with JPEG and PNG, like we have in Compress dialog - as you suggest.
2. People who didn't even realize they used a WebP (IMO, the vast majority, who e.g. dragged the images from a web page). They don't care about the image original format at all. They would have to pay their disk space (that +10%) for a couple of those who needed it.

And the last category of users would be in real danger then. You argue that the idea behind saving both formats is being able to return to WebP at some later stage - meaning that the fallback PNG would be dropped, right? But that means that at some update, unprepared users would suddenly have their existing documents dropping embedded PNGs, which they would not notice, because they use a version that supports the format; but you have no control who is their recipients are, and what they use. Of course, the decision to drop PNG would happen when WebP support in ODF readers is reasonable, but you can't guarantee 100% - and that means that *existing* edited documents with pre-existing images can suddenly become unreadable on colleagues' systems where they used to be working. It would be OK to argue "you use a modern program that supports WebP; you have just inserted a WebP into a new document; it's OK that this image is not shown on your colleague who uses AOO 4.1" - but it is *not* OK to tell that about document that they had happily edited for long time, and that broke after editing with updated LO, without any image insertion.

So IMO:

1. If people want to be notified about conversion, do that using an infobar (just inform, do not ask and do not provide options there, except maybe a button to go to relevant configuration, or to help).
2. Provide a (preferably expert) option to *not* convert at all - i.e., for those who really want to use WebP, let them have the WebP - with no fallback.
3. Provide an option to convert lossy WebP to JPEG instead of PNG.
4. Do not complicate things with a fallback. That will inevitably hit much more users in long term, than those who benefit from that.
Comment 28 Mike Kaganski 2022-02-07 06:45:31 UTC
Also: please let's close this bug, and file new bugs.

Although this one started as "please add support for WEBP image format (image import and inside .ods/.odt)", the stated scope is too broad for a single issue. It would be reasonable to only track manageable scope here (which is "add support for reading" - and which is RESOLVED FIXED by now); and track other multiple aspects (transition period behavior; related options; point in time to end the transition) separately, maybe blocking this one, or having a separate meta.
Comment 29 Timur 2022-02-07 08:20:15 UTC
So, READING is fixed. New bugs need to be linked here via See Also.
Comment 30 BogdanB 2022-02-07 08:39:38 UTC
It is working. I can insert a WebP image in LibreOffice.

Verified with
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: d5f015185240a7bddfed7ddf10d6b5426e35fb72
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 31 Tomaz Vajngerl 2022-02-07 09:50:03 UTC
(In reply to Mike Kaganski from comment #27) 
> The idea to save both formats (one as fallback) would only serve people who
> have the ultimate goal to get to the original bytes at some unspecified
> future time. What is the real use case, that would require someone to
> desperately need the original embedded image bytes, as opposed to a
> converted copy?

I mean we agree that in the future we will enable WebP as a native format don't we? If NO then you wold have a point, if YES then this is IMHO the most smooth way to transition. Also throwing away the original image is always the last resort option, which we can aviod. 

 
> OTOH, there are *real* use cases, that would be served poorly by that
> decision.
> 1. People who chose WebP to save space. Well, PNG is not ideal for those;
> but speculating that 110% is better for those who are unhappy with 100% is
> not reasonable, right? And we possibly need to have a "convert lossy WebP
> to" option with JPEG and PNG, like we have in Compress dialog - as you
> suggest.

If someone uses WebP to save space he will turn off saving the fallback images and by that agree that he know what the consequences are (the option is already available). Most people using that know the consequences. This option is currently not available to users.

> 2. People who didn't even realize they used a WebP (IMO, the vast majority,
> who e.g. dragged the images from a web page). They don't care about the
> image original format at all. They would have to pay their disk space (that
> +10%) for a couple of those who needed it.

So what? I don't see your point - we already do this for a bunch of vector formats that add much more to the size.

Also this is why I suggested the JPEG + WebP, which would only amount to 1/3 of the PNG size and we can safely do this because we don't destroy the original file. 
  
> And the last category of users would be in real danger then. You argue that
> the idea behind saving both formats is being able to return to WebP at some
> later stage - meaning that the fallback PNG would be dropped, right? But
> that means that at some update, unprepared users would suddenly have their
> existing documents dropping embedded PNGs, which they would not notice,
> because they use a version that supports the format; but you have no control
> who is their recipients are, and what they use. Of course, the decision to
> drop PNG would happen when WebP support in ODF readers is reasonable, but
> you can't guarantee 100% - and that means that *existing* edited documents
> with pre-existing images can suddenly become unreadable on colleagues'
> systems where they used to be working. It would be OK to argue "you use a
> modern program that supports WebP; you have just inserted a WebP into a new
> document; it's OK that this image is not shown on your colleague who uses
> AOO 4.1" - but it is *not* OK to tell that about document that they had
> happily edited for long time, and that broke after editing with updated LO,
> without any image insertion.

I don't think you have a point here, because this can be said for any kind of functionality added on top of ODF. We expect the users to upgrade in a reasonable time and if not, it's on them.
Comment 32 Tomaz Vajngerl 2022-02-07 10:07:12 UTC
(In reply to Mike Kaganski from comment #27)
> 1. If people want to be notified about conversion, do that using an infobar
> (just inform, do not ask and do not provide options there, except maybe a
> button to go to relevant configuration, or to help).

Not sure... when do you want to do this? on insertion or on save?

> 2. Provide a (preferably expert) option to *not* convert at all - i.e., for
> those who really want to use WebP, let them have the WebP - with no fallback.

This means the format will have to be added to LibreOffice as a native format, or this won't work.

> 3. Provide an option to convert lossy WebP to JPEG instead of PNG.

Users will mostly not understand this option and the consequence of it. Either we do it by default or don't do this at all.. which will be bad.  

> 4. Do not complicate things with a fallback. That will inevitably hit much
> more users in long term, than those who benefit from that.

Which I don't think you established well enough.
Comment 33 Mike Kaganski 2022-02-07 10:09:45 UTC
(In reply to Tomaz Vajngerl from comment #31)
> I don't think you have a point here, because this can be said for any kind
> of functionality added on top of ODF. We expect the users to upgrade in a
> reasonable time and if not, it's on them.

:)
No, in this case it's different. As I said, it's OK when you open your file in a new shiny LO, add a new image from a web page, and save, and it doesn't show in another's system - because the added image was a WebP. But it's a very different case when I worked on this document for a long time, it opened on another system just fine with all its images; now I upgraded, opened this document to type "The end." on the last page, saved, and it "lost" all its images in the middle, when viewed on another system, which were there before. That is very much "data loss" from user PoV, who needs not to know that internally, those images, that were working fine, were a time bomb "a showing fallback + another format that will suddenly be the only one kept in some future".

Note that IIUC, there's no plans to drop the fallbacks that we save for those other formats that you refer; and that is the whole difference in this point.
Comment 34 Mike Kaganski 2022-02-07 10:15:15 UTC
(In reply to Tomaz Vajngerl from comment #32)
> (In reply to Mike Kaganski from comment #27)
> > 1. If people want to be notified about conversion, do that using an infobar
> > (just inform, do not ask and do not provide options there, except maybe a
> > button to go to relevant configuration, or to help).
> 
> Not sure... when do you want to do this? on insertion or on save?

At insertion time (which doesn't mean it needs to actually convert the image at that moment - only inform that it would be converted on save).

> > 2. Provide a (preferably expert) option to *not* convert at all - i.e., for
> > those who really want to use WebP, let them have the WebP - with no fallback.
> 
> This means the format will have to be added to LibreOffice as a native
> format, or this won't work.

Yes. And that would mean that current LO may be configured into the state that we expect to happe in the future - just changing the settings from current defaults.

> > 3. Provide an option to convert lossy WebP to JPEG instead of PNG.
> 
> Users will mostly not understand this option and the consequence of it.
> Either we do it by default or don't do this at all.. which will be bad.  

I am perfectly OK with using JPG by default; all options that I suggested should be expert options, to not confuse most. But people may argue that they would convert a lossy format to another lossy format, and have extra loss ... well, that was my idea, which might not be worth that, so not married to that option at all :)
Comment 35 Tomaz Vajngerl 2022-02-07 10:57:03 UTC
(In reply to Mike Kaganski from comment #33) 
> :)
> No, in this case it's different. As I said, it's OK when you open your file
> in a new shiny LO, add a new image from a web page, and save, and it doesn't
> show in another's system - because the added image was a WebP. But it's a
> very different case when I worked on this document for a long time, it
> opened on another system just fine with all its images; now I upgraded,
> opened this document to type "The end." on the last page, saved, and it
> "lost" all its images in the middle, when viewed on another system, which
> were there before. That is very much "data loss" from user PoV, who needs
> not to know that internally, those images, that were working fine, were a
> time bomb "a showing fallback + another format that will suddenly be the
> only one kept in some future".

But you talk about "another system" -- what is that? It seems to me a highly hypothetical situation that you will rarely ever encounter in reality. 
It is still possible to not forcefully drop the PNG/JPEG fallback files from document and do this just when the user agrees.   

> Note that IIUC, there's no plans to drop the fallbacks that we save for
> those other formats that you refer; and that is the whole difference in this
> point.

We pretty much could drop fallback PNG files for SVG files today.
Comment 36 Mike Kaganski 2022-02-07 11:06:06 UTC
(In reply to Tomaz Vajngerl from comment #35)
> We pretty much could drop fallback PNG files for SVG files today.

Oh - in that case, I'm fine with the fallback option. Just suggest that we first perform that experiment dropping the SVG fallback, to fully understand the complications. Because it's easier to add something (the fallback), than to remove it later.
Comment 37 Tomaz Vajngerl 2022-02-07 11:26:50 UTC
(In reply to Mike Kaganski from comment #34)
> At insertion time (which doesn't mean it needs to actually convert the image
> at that moment - only inform that it would be converted on save).

Makes sense. Well conversion should be done after that in the background... don't think you want to do it on save.

> Yes. And that would mean that current LO may be configured into the state
> that we expect to happe in the future - just changing the settings from
> current defaults.

Well but then there is some work that is needed to be done...
 
> I am perfectly OK with using JPG by default; all options that I suggested
> should be expert options, to not confuse most. But people may argue that
> they would convert a lossy format to another lossy format, and have extra
> loss ... well, that was my idea, which might not be worth that, so not
> married to that option at all :)

If you keep the original WebP, then you can do as much loss to the fallback file as necessary. There is always the original file available.
Comment 38 Tomaz Vajngerl 2022-02-07 11:30:56 UTC
(In reply to Mike Kaganski from comment #36)
> Oh - in that case, I'm fine with the fallback option. Just suggest that we
> first perform that experiment dropping the SVG fallback, to fully understand
> the complications. Because it's easier to add something (the fallback), than
> to remove it later.

Sounds great to me ... file a bug report and make ESC aware.
Comment 39 Timur 2022-02-07 13:18:45 UTC
So, options are: 

1. Automatically convert WebP on paste into something well supported like PNG. 
2. Store both WebP and PNG or JPG in the document, remove the fallback PNG after. Provide a (preferably expert) option to *not* convert at all. 
3. Notify about conversion on insert using an infobar/popup about the image file format incompatibility with older LibreOffice versions. Inform and do not ask and do not provide options there.
4. Turn off saving the fallback images and by that agree that he know what the consequences are (the option is already available) - how? 
5. Notify user for WebP incompatibility with older LO on filesave, via dialog OK/Cancel and "do not ask anymore", like for saving to DOC/X.

Please clarify 4., how is is available? 

I concur with comment 23, I'm not for conversion, rather for option 5.
Comment 40 Tomaz Vajngerl 2022-02-07 14:47:15 UTC
(In reply to Timur from comment #39)
> So, options are: 
> 
> 1. Automatically convert WebP on paste into something well supported like
> PNG. 
> 2. Store both WebP and PNG or JPG in the document, remove the fallback PNG
> after. Provide a (preferably expert) option to *not* convert at all. 
> 3. Notify about conversion on insert using an infobar/popup about the image
> file format incompatibility with older LibreOffice versions. Inform and do
> not ask and do not provide options there.
> 4. Turn off saving the fallback images and by that agree that he know what
> the consequences are (the option is already available) - how? 
> 5. Notify user for WebP incompatibility with older LO on filesave, via
> dialog OK/Cancel and "do not ask anymore", like for saving to DOC/X.
> 
> Please clarify 4., how is is available? 

In expert configuration: officecfg::Office::Common::Save::Graphic::AddReplacementImages true/false

This is for all replacement graphics, but we can also provide a WebP specific one if really needed. 

> I concur with comment 23, I'm not for conversion, rather for option 5.
Comment 41 Mike Kaganski 2022-02-07 15:01:50 UTC
By the way, the storage of WebP could also depend on ODF level setting, based on the ODF text (that mentions in <draw:image> that "vector graphics should be stored in the [SVG] format and bitmap graphics in the [PNG] format"). So we could use WebP in files with ODF 1.3 extended, and use PNG/JPEG (the latter being not mentioned in the standard unfortunately, but is de-facto standard) for 1.3 and prior? (I understand that this might be a stretch, but OTOH this allows to simplify the options.)
Comment 42 Mike Kaganski 2022-05-26 11:09:59 UTC
*** Bug 149317 has been marked as a duplicate of this bug. ***
Comment 43 Philippe Morin 2022-06-19 12:48:59 UTC
(In reply to Commit Notification from comment #17)
> Luboš Luňák committed a patch related to this issue....

Thanks! I'll try to have a look!