Using 7.3 and jpeg images, I was getting a file of roughly the size of the images contained. With 7.4 and webp, the size of the resulting file is x4 the size of the images.
Webp is not stored in the file at the moment - it gets converted to PNG, to ensure backward compatibility (see tdf#114532 for details). For some images (mostly those using lossy compression), PNG may be several times larger.
1 Like
So, I better wait before importing images in that format? Will this be changed or is it the intended functionality?
It totally depends on what you need or expect. For people who tried unsuccessfully to insert some images (that were WebP) into their documents, and who don’t care about their storage format, it’s OK to use it now. For those who explicitly need WebP, it’s of course not the right time.
Note that current version already can read files with embedded WebP - only does not generate them itself, for the reasons stated.
Yes, at some point (when we decide that the number of those who use recent enough versions is large enough, or maybe even earlier - if we decide to have WebP together with a PNG/JPEG fallback in the file).
Yes it is the intended functionality (for now), and the two statements are not mutually exclusive.
Well, I’m changing all the images from one format to another to save space, converting it to PNG totally defeats the purpose. I read in the link that some people proposed to disable conversion when backwards compatibility isn’t an issue. Was that option discarded?
I mentioned that (configurable) fallback image is a possibility, it’s not yet decided. And anyway, it needs someone to do the work, not only to decide 
My main confusion comes from the fact that webp support is a featured change for version 7.4, so I thought they could be used right away. Maybe it should’ve been stated more clearly in the release notes, instead of making a reference to the bug status.
Maybe 
- done.
1 Like
Really looking forward to you being able to roll back that change in the release notes
What? I’m not going to roll back anything there. I just added a clarification. The change itself is important enough to be mentioned there; it (1) marks when the software became capable to process the format (so e.g. it would mean that when this version and later become dominant, the rest could be done), and (2) it makes it possible for users to insert what was not inserted before at all. That some users need more is OK.
Up to now if you wanted to include a WEBP image you had to open it in a graphics editor and convert it to jpg (or png depending on the image). That jpg would then be inserted into the document. This workflow is still available but now the WEBP suitable for conversion to png can go straight in.
TBH, I prefer to continue converting them to jpg and inserting them like that. When properly compressed, the difference with webp isn’t too big. PNG might be good for some types of graphics, but not for comic covers.