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.
Discussion has been done in bug 114533 with the recommendation to not implement this filter.
*** Bug 130759 has been marked as a duplicate of this bug. ***
*** Bug 108147 has been marked as a duplicate of this bug. ***
*** Bug 140440 has been marked as a duplicate of this bug. ***
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 :-)
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.
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.
(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
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/
(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
WEBP Support in Web Browsers: https://caniuse.com/webp AVIF Support in Web Browsers: https://caniuse.com/avif
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
I downloaded an image from a web page using my web browser. I then tried to add it to a presentation using Impress. I was confused when the file browser in Impress did not display the image I had downloaded. I only realised later that the image was a WebP image, and that LibreOffice presumably did not support it. It would be good to support WebP now that all major browsers support it and more images on the web are going to be using this format.
Any chance to get this format supported in a future release ?
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.
Lubos is looking at this.
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.
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.
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.
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.
(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.
Would it be possible to automatically convert WebP on paste into something well supported like PNG?
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?
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.
I'm more for Yet Another Option (YAO) for conversion, with default checked.
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.
(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.
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.
So, READING is fixed. New bugs need to be linked here via See Also.
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
(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.
(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.
(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.
(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 :)
(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.
(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.
(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.
(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.
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.
(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.
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.)
*** Bug 149317 has been marked as a duplicate of this bug. ***
(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!
Height months after the integration of the WebP format in LibreOffice, it's still incomplete because images are converted to PNG format when saving the document. Is there a particular motivation for this blocking? Is there an ETA for full support of this image file format? Thank you.
(In reply to phv from comment #44) > Is there a particular motivation for this blocking? Why post a question, when you don't read existing stuff where you post?
I was expecting an answer rather than a condescending remark. I read the previous forty-two comments but if several development directions have been mentioned, none seems to have been picked: some contributors suggested to add an option in expert mode, others to reserve this image format to odf 1.3 extended. I can't find any bug reports about the future of this format in LibreOffice either, maybe this topic has been covered elsewhere? Hence the simple and sincere question from a non-developer: is there a technical issue or a negative decision that prevent a complete support? If not an answer, at least tell me how to get one: should I open a new report?
If WebP images are copied together with text from web browser and pasted into LibreOffice Writer, only the text is taken over, but the images only as placeholders (empty frame). Tested on several versions of LibreOffice including the current 7.6 (but so far only on Windows 7, 32 bit).
Nik, please open a separate bug report on the issue you've found.
I've updated our media support wiki page: https://wiki.documentfoundation.org/index.php?title=Media_Support%2FSummary&type=revision&diff=679435&oldid=175870
OpenDocument 1.4 is currently under development at OASIS Open. The current working drafts can be found on GitHub : https://github.com/oasis-tcs/odf-tc/tree/master/docs/odf1.4 It seems important to me that this new ODS 1.4 format adds support for the WebP image format. WebP is becoming an essential standard and it allows very high lossless compression (better than what AVIF offers, the latter is only good for lossy compression, to replace JPEG). Vivien GUEANT.
(In reply to Vivien GUEANT from comment #50) > OpenDocument 1.4 is currently under development at OASIS Open. > ... New bug please, with see also to this closed issue.
(In reply to Vivien GUEANT from comment #50) > OpenDocument 1.4 is currently under development at OASIS Open. > The current working drafts can be found on GitHub : > https://github.com/oasis-tcs/odf-tc/tree/master/docs/odf1.4 > > It seems important to me that this new ODS 1.4 format adds support for the > WebP image format. ODF specification doesn't mandate support for any image format. It recommends only that raster images are stored as PNG and vector images as SVG. I don't see a need to change that.
We had some demand from french administration to support it.