Bug 114533 - add support for FLIF image format (image import and inside .ods/.odt)
Summary: add support for FLIF image format (image import and inside .ods/.odt)
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
6.0.0.0.beta2
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-18 12:24 UTC by squeezechart
Modified: 2018-01-02 10:48 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

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

http://flif.info/
https://github.com/FLIF-hub/FLIF

It is a modern, free and open image format (LGPLv3 license).

FLIF is a novel lossless image format which outperforms PNG, lossless WebP, lossless BPG, lossless JPEG2000, and lossless JPEG XR in terms of compression ratio.

According to the compression experiments we have performed [older results here], FLIF files are on average:

    14% smaller than lossless WebP,
    22% smaller than lossless BPG,
    33% smaller than brute-force crushed PNG files (using ZopfliPNG),
    43% smaller than typical PNG files,
    46% smaller than optimized Adam7-interlaced PNG files,
    53% smaller than lossless JPEG 2000 compression,
    74% smaller than lossless JPEG XR compression.
Comment 1 Buovjaga 2017-12-26 18:08:54 UTC
I don't know, man.

Let's ask design team about adding support for exotic formats like this.

Bug 114532 is about webp

bug 114531 is about jpeg-xr

bug 114530 is about lepton

reporter also has an older request for packjpg, bug 74128 and Tomaž had a valid point in there: "I don't think we can use it because if we "pack" a jpeg file in the document then other programs (OpenOffice, Calligra, MS Office for example) that don't support packJPG (and probably never will) won't be able to show it."
Comment 2 Heiko Tietze 2017-12-27 11:30:17 UTC
LibreOffice' goal is to manage as many file formats as possible. That is basically meant for office documents but being able to deal with various graphic formats is not prejudicial. 

On the other hand, haven't heard about FLIF and users can always convert alien image formats with one of the plethora of image tools. Wouldn't put special effort in the implementation.
Comment 3 squeezechart 2017-12-27 13:24:26 UTC
importing and using modern open-source image formats should be one of the strengths of open-source office suites.

packJPG and Lepton save up to 30% bandwidth and decompress in the blink of an eye.
Original JPEG is restored and can easily be exported when saving as MSO document.

JPEG-XR is already used by MSO inside documents.
WEBP is a modern standard of Google that works in many browsers and smartphones.
FLIF compresses even better and gets more and more attention.

Using them, we can say "it stands out from the office suite crowd" also for LO 6.0(In reply to Heiko Tietze from comment #2)
> LibreOffice' goal is to manage as many file formats as possible. That is
> basically meant for office documents but being able to deal with various
> graphic formats is not prejudicial. 
> 
> On the other hand, haven't heard about FLIF and users can always convert
> alien image formats with one of the plethora of image tools. Wouldn't put
> special effort in the implementation.

importing and using modern open-source image formats should be one of the strengths of open-source office suites.

packJPG and Lepton save up to 30% bandwidth and decompress in the blink of an eye.
Original JPEG is restored and can easily be exported when saving as MSO document.

JPEG-XR is already used by MSO inside documents.
WEBP is a modern standard of Google that works in many browsers and smartphones.
FLIF compresses even better and gets more and more attention.

Using them, we can say "it stands out from the office suite crowd" also for LO 6.0
Comment 4 Tomaz Vajngerl 2018-01-02 04:53:15 UTC
It is our responsibility to the user that the document he creates can be opened with older versions of LO and other office suites. It is true that there is no limitations which image formats should a document format support (neither by ODF nor OOXML - just recommendations), we still need to choose the formats that are widely used and supported by others. When a less supported format is used, we need to warn the user that, which means we need to implement this missing functionality.

Also there are other considerations in addition as every new library increases the size of LO and increases the maintenance burden and things needed to be tested. So by that we shouldn't adopt just any image format but one that would be at least used a lot (yes and that generally is the chicken or the egg problem why even we have more capable formats we still use many decade old ones).

Generally I would avoid PackJPG or Lepton as they can save you some % by using a modern entropy coder, but that is not that high to be worth it (it is much less gain when using properly optimized JPEG files AFAIK). They are mostly used by cloud storage providers (it was created by dropbox) where they can just silently losslessly compress the images and gain space (even 5-10% for petabytes of images is a lot). Support of both is practically non-existent.

I'm not too keen by adapting WebP now when the next-gen format based on AV1 is not too far away (PIK, also developed by google is looking promising) and Microsoft being part of AOM alliance I would expect to see support added to Windows programs as well. WebP has support in Chrome, but generally, even on Linux, it mostly isn't supported in image viewers.

FLIF is a great lossless image encoder, but currently it lacks support practically everywhere. Not sure why we should adopt it when it is a good chance it will be used just by a couple of people. It also uses a CABAC variant for compression, which legal status is unknown. I would avoid - much more keen to support WebP instead if I have to choose.

JPEG XR is the only format which I would be comfortable to add. The reason is that it is supported and used by MSO in some situations (if you apply a image filter, the original is stored in JPEG-XR so the user can revert the applied filter) and it is generally supported on every Windows 7 and beyond. The problem with JPEG XR is that it is not really much of an improvement over JPEG or PNG (sometimes it is even worse) and that the open-source libjxr is practically un-maintained library.
Comment 5 Tomaz Vajngerl 2018-01-02 05:05:07 UTC
Also removing support for a image format is much harder so adapting a new image format should take a lot of consideration as it can have long lasting effects. 

For most use-cases recompressing a image and lowering the resolution would save much more bits with virtually very little consequence for most people.
Comment 6 Heiko Tietze 2018-01-02 09:04:43 UTC
When Tomaz says FLIF has potential we should keep this ticket open, also as reference with the discussion. Resolved the other tickets regarding very special formats as WONTFIX but set JPG XR to NEW too.
Comment 7 Buovjaga 2018-01-02 10:18:04 UTC
(In reply to Heiko Tietze from comment #6)
> When Tomaz says FLIF has potential we should keep this ticket open, also as
> reference with the discussion. Resolved the other tickets regarding very
> special formats as WONTFIX but set JPG XR to NEW too.

He said he would avoid FLIF, in part due to potential legal trouble. JPEG XR also comes out as pretty "meh" and unmaintained. I would just close both of the report.
Comment 8 Heiko Tietze 2018-01-02 10:27:51 UTC
(In reply to Buovjaga from comment #7)
> I would just close both of the report.

No objection from my side.
Comment 9 Buovjaga 2018-01-02 10:48:19 UTC
Yep, let's close as we can't really go pioneering with this stuff.