Mailing List Archive

FLIF for Wikimedia
Hey guys,


some years ago I stumbled across the FLIF-format, which might be very
interesting for wikimedia commons and/or Mediawiki in general.

I try to summon the fileformat and it's advantages a bit:


It's a free, patent free, lossless image compression format, which
supports RGB(A) / greyscale images as well as palette-images.

FLIF also supports animations and 16 bit/channel color-deph for still
images as well as animations. embedded ICC color profiles, Exif and XMP
metadata are supported. They started to work on RGGB-raw-file-support,
but this is not fully implemented right now.

There's a small JavaScript library which can be used until there's a
browser support given, so theres no need to wait until there is
browser-support.

A small portion of a FLIF file, can be decoded as well (progressive
decoding).

For thumbnails we can simply load a 5-10% portion of a multi-mb file and
show this as a thumbnail. If a user want a larger view, later, we just
fetch some additional data to the already saved one, removing the need
to fully download the same 'data' again.

It's also great for resposive designs, where the user might rotate his
device and know need a 50% larger resolution of the same file.

If the user click on that image, to get a fullscreen popup we can also
use the thumbnail-data and just fetch some additional KB to fullfil this
requirement of a larger resolution.

Also the browser might start rendering with a 1% portion of the file,
and show a low quality image. When some more percent are downloaded, the
browser can update the low quality image with a larger one.

###

My idea was, to convert all new uploads to FLIF at the time we receive
those files. So JPGs get a lot larger, GIF and PNG some KB smaller, but
the most interesting advantage is: we do not get any generation-loss
anymore:

If someone upload a JPG-file, we save it to FLIF. If someone want to
edit the file again, he need to download the FLIF and read it nativly
with an application or download it as PNG and upload the edited file
again as PNG. We then simply convert it back to FLIF for storage.

###

There's also an advantage for the caching proxies, they does not need to
handle image files in various sizes, which should simplify the overhead,
because we use just one filename and url for all views on that file.

###

I hope I found the right place to discuss this topic, have a nice
weekend! :)


Best regards

Ruben

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Hi,

On Sat, 2017-12-02 at 22:20 +0100, RubenKelevra wrote:
> There's a small JavaScript library which can be used until there's a
> browser support given, so theres no need to wait until there is
> browser-support.

Please provide a link to that library.

Thanks,
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
The library can be found here: http://flif.info/

Sent from my iPhone

> On Dec 2, 2017, at 5:49 PM, Andre Klapper <aklapper@wikimedia.org> wrote:
>
> Hi,
>
>> On Sat, 2017-12-02 at 22:20 +0100, RubenKelevra wrote:
>> There's a small JavaScript library which can be used until there's a
>> browser support given, so theres no need to wait until there is
>> browser-support.
>
> Please provide a link to that library.
>
> Thanks,
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Hey Andre,

On 03.12.2017 00:49, Andre Klapper wrote:
> On Sat, 2017-12-02 at 22:20 +0100, RubenKelevra wrote:
>> There's a small JavaScript library which can be used until there's a
>> browser support given, so theres no need to wait until there is
>> browser-support.
>
> Please provide a link to that library.

the library called Poly-FLIF and you can find a livedemo[1] and the
sourcecode on github[2].

[1] https://uprootlabs.github.io/poly-flif/
[2] https://github.com/UprootLabs/poly-flif


Best regards


Ruben


>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia (Demonstration) [ In reply to ]
I've picked a featured image of today for a small demonstration:

$ du -h Mansudae-Monument-Bow-2014.* | sort -n
2,0M Mansudae-Monument-Bow-2014.jpg
4,9M Mansudae-Monument-Bow-2014..progressiv.jpg *
6,5M Mansudae-Monument-Bow-2014.flif
16M Mansudae-Monument-Bow-2014.png

*(saved again with Gimp as progressive JPG with Quality 100%)

I cut it to 50 KiB (the desired size for a thumbnail of around 100px).

$ dd if=$if of=$of bs=1024 count=50

$ du -h Mansudae-Monument-Bow-2014.50KiB.* | sort -n
52K Mansudae-Monument-Bow-2014.50KiB.flif
52K Mansudae-Monument-Bow-2014.50KiB.jpg
52K Mansudae-Monument-Bow-2014.50KiB.png

The original image[1] in contrast to the 50 KiB FLIF[2] which
outperforms progressive JPG[3] as well as interlaced PNG[4].

https://imgur.com/a/84RbJ

And I did another test with 250 KB to simulate a further download of the
file:

https://imgur.com/a/twXxr

Those tests show clearly an advantage of FLIF at this time since only
JPG progressive has any chance of competing fair... which means we still
have to rely on generation loss and lossy compression.

FLIF, on the other hand, does not have any (heavy) generation loss, as
WebP, JPG or JPG2000 do have on lossy compression.

FLIF is also able to provide a 3.77% Download a 200px width thumbnail
with very low distortion and with just 0.75% a 100 px width thumbnail
with very low distortion. While the main competitor (PNG) still shows a
black screen.

FLIF in comparison also provides the ability to store motion-pictures
like GIF or APNG which is still not widely supported for PNG.


---


Hope this helps a bit without extensive own testing to get an impression
of the capabilities of this file format.



Best regards

Ruben

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Hey,

I consider myself an image file format nerd, so thanks a lot for
sharing this! FLIF was new to me.

I would like to share two important notes:

1. Unfortunately the flif.info website does not say a word about the
CPU resources their current implementation burns when converting a,
let's say, PNG to FLIF. It's pretty important to realize that CPU
resources are even more valuable than storage space and network
bandwidth. Sure, It's not really possible to come up with an exact
threshold. But if, let's say, converting a PNG to FLIF saves 100 KiB,
but takes a minute, this minute will never pay off.

If you follow the discussions on Wikimedia Commons, you will find this
argument quite often: Downloading PNGs, optimizing them, and uploading
them again is practically never worth it. Think of all the resources
that are burned to do this: CPU time, download and upload, database
storage and time, disk storage for the new revision, and not to forget
the user doing all this.

Sure, your suggestion avoids a lot of this. But the CPUs involved will
experience heavy load, both on the server as well as clients that need
to recode FLIF files via a JavaScript library first.

2. Lossy file formats like JPEG should never be converted to lossless
formats. This will actually decrease quality (over time). The problem
is that the image data will still contain the exact same JPEG
artifacts, but the fact that it was a JPEG (and how it was encoded) is
lost. No tool specialized in squeezing the maximum quality out of
lossy JPEGs can work any more. And there are a lot of super-awesome
tools like this. Not only tools like JPEGCROP and such that can cut
and even combine JPEGs without actually recoding them. There are also
"JPEG repair" filters that know how to reverse the JPEG encoding
algorithm and can squeeze out a tiny little bit of extra information
regular JPEG decoders can't see.

This said, I'm all for adding FLIF to the list of allowed file formats!

Best
Thiemo

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Hey Thiemo,

On 04.12.2017 10:43, Thiemo Kreuz wrote:> I consider myself an image
file format nerd, so thanks a lot for
> sharing this! FLIF was new to me.Don't mind it! :)

> I would like to share two important notes:
>
> 1. Unfortunately the flif.info website does not say a word about the
> CPU resources their current implementation burns when converting a,
> let's say, PNG to FLIF.Well, currently it's single core and not
optimized at all. You should know CABAC encoding from x264/x265 so it's
slow, but not dead slow.

The website doesn't mention it because it highly depends on the subject
as well as the setting on encoding named effort.

Currently, effort is default 60, I tried 100 a lot, but there's nearly
nothing to gain. So I assume we always want to use the good default. :)

PNG Encoding of the current featured picture of today[1] at a medium
image size for the web, 1.280×868 Pixel, opened in Gimp, converted to
sRGB and exported as maximum compression without any checkbox done in
Gimp ... takes Gimp 3 seconds to write it to the Harddisk.

Transcoding this PNG to FLIF takes on my machine (i3-2330M@2.20GHz; 12
GB RAM):
real 0m7,405s
user 0m7,320s
sys 0m0,053s

decoding the file again to PNG on the same machine (with FLIF)
real 0m1,077s
user 0m1,067s
sys 0m0,007s

For comparison, we save 708 KByte in comparison to PNG in this case, and
the PNG exported by FLIF is just 14 KByte bigger than the one created by
Gimp.

> It's pretty important to realize that CPU
> resources are even more valuable than storage space and network
> bandwidth. Sure, It's not really possible to come up with an exact
> threshold. But if, let's say, converting a PNG to FLIF saves 100 KiB,
> but takes a minute, this minute will never pay off.
So my Point was more: Get rid of this bloody Download a JPG, do some
Stuff & Upload a 3 Times locally saved JPG again, calling it an improvement.

> If you follow the discussions on Wikimedia Commons, you will find this
> argument quite often: Downloading PNGs, optimizing them, and uploading
> them again is practically never worth it. Think of all the resources
> that are burned to do this: CPU time, download and upload, database
> storage and time, disk storage for the new revision, and not to forget
> the user doing all this.
Yep, but enabling FLIF for new files would do nothing to the old Data at
all, I don't want to start a discussion about converting petabytes of
Data, but all new revisions should be done in FLIF, if you ask me.
> Sure, your suggestion avoids a lot of this. But the CPUs involved will
> experience heavy load, both on the server as well as clients that need
> to recode FLIF files via a JavaScript library first.
FLIF is very fast to decode via JavaScript, and in general, as the
example shown above, it takes just 1 second to decode and encode a
medium size image as PNG with just one thread on a pretty outdated
notebook with an unoptimized decoder and encoder. :)

Try adding a FLIF to a website and test out if the website load anywhat
slower with the FLIF ... at the small image sizes you get on articles,
the performance impact is neglectable and comparable to loading a font
file to the browser.
> 2. Lossy file formats like JPEG should never be converted to lossless
> formats. This will actually decrease quality (over time). The problem
> is that the image data will still contain the exact same JPEG
> artifacts, but the fact that it was a JPEG (and how it was encoded) is
> lost.
Yes, but those images should never be saved as JPG in the first place.
Even under Android RAW-Photography is going to be a thing. FLIF just
started to get rudimentary RAW-capabilities, which means you can just
convert the special RAW-File to a FLIF and upload it with any loss in
quality.

> No tool specialized in squeezing the maximum quality out of
> lossy JPEGs can work anymore. And there are a lot of super-awesome
> tools like this. Not only tools like JPEGCROP and such that can cut
> and even combine JPEGs without actually recoding them.
Well, if you really want to start a discussion about a lossless rotation
of JPG files, let me guess how many uploads are rotated losslessly...
0.0002%?

> There are also "JPEG repair" filters that know how to reverse the JPEG
encoding
> algorithm and can squeeze out a tiny little bit of extra information
> regular JPEG decoders can't see.
Great! Just recommend this for new uploads to be done if the source
material is JPG, let the ppl convert it with this to PNG and then to
FLIF or ask the FLIF maintainers if they want to add this as an
import-filter, for FLIF itself! :)

But the your argument was: "Think of all the resources that are burned
to do this: CPU time, download and upload, database storage and time,
disk storage for the new revision, and not to forget the user doing all
this."

Which perfectly fit's here too. On a 20 MPixel picture small JPG
Artefacts are no issue at all, but users which Download the JPG and
upload it again, after doing some needed work to it, like cropping or
color enhancement, this is a problem. Each version get more artifacts
and we constantly get a loss of quality which each revision...

I don't think we should have accepted JPGs in the first place. :)

> This said, I'm all for adding FLIF to the list of allowed file formats!
Wonderful, hope I get some feedback from you on the things I pointed out! :)
If you want to let a note on the GIMP/eog enhancement request, feel free
to do so:
https://bugzilla.gnome.org/buglist.cgi?quicksearch=flif

[1] File:Umschreibung by Olafur Eliasson, Munich, December 2016 -04.jpg

Best regards


Ruben

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
On Mon, Dec 4, 2017 at 10:34 AM Ruben Kelevra <ruben@vfn-nrw.de> wrote:

> > Sure, your suggestion avoids a lot of this. But the CPUs involved will
> > experience heavy load, both on the server as well as clients that need
> > to recode FLIF files via a JavaScript library first.
> FLIF is very fast to decode via JavaScript, and in general, as the
> example shown above, it takes just 1 second to decode and encode a
> medium size image as PNG with just one thread on a pretty outdated
> notebook with an unoptimized decoder and encoder. :)
>
> Try adding a FLIF to a website and test out if the website load anywhat
> slower with the FLIF ... at the small image sizes you get on articles,
> the performance impact is neglectable and comparable to loading a font
> file to the browser.
>
>
Requiring Javascript just to look at an image seems rather ridiculous to
me, fast or not. It's just...silly sounding. So my browser doesn't support
FLIF...you have to use JS to turn it into some format (PNG) that I can
understand...for what, minimal size savings on the order of a few KB? That
doesn't seem worth the complexity...

How does it fall back for users with Javascript disabled outright? How fast
is it on older hardware? How about mobile? Remember: not everyone has fast
desktops or laptops :)

It doesn't look like there's very much support in the authoring area
either[0]. So we'd have to encode all uploads to this format. Would we be
storing the original PNGs as well, similar to how we store video transcodes
in multiple formats? If so, there goes any space savings on WMF's end.

The fact that the Debian RFP for the encoder/decoder has stalled for almost
2 years isn't very promising... [1]

Considering there's effectively zero browser support (comments like
[2][3][4] and *especially* [5] are pretty discouraging) it just doesn't
seem worth it the technical maintenance to support it on our end.

Don't get me wrong, the format itself seems kinda cool, but I'd be very
hesitant to be a pioneer for a new graphics standard that nobody else seems
to want to pick up yet.

-Chad

[0] http://flif.info/software.html#graphics-software
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812761
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1240692#c6
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1240692#c8
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=539120#c4
[5] https://bugs.chromium.org/p/chromium/issues/detail?id=539120#c11
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
An encode latency of 7 seconds and decode latency of 1 second arent what I
would call "very fast" (the decode latency measurement probably isnt
realistic as decode and encode to png is different from just display in
browser. Then again all these measurements are going to vary by filesize,
not to mention low power devices like phones)

If it indeed takes 1 second to decode, thats probably more time than the
space savings would save time wise on a moderate speed internet connection.

And time is only one metric. Often image encoding is limitted by memory.


Anyways i'd be opposed to this unless the bandwidth saving was extreme.
Wikipedia is not the place to be a testing ground for experimental image
formats that browsers arent even supporting.


--
bawolff

p.s.lossless rotatio /cropping of jpegs is actually very common due to
rotatebot

On Monday, December 4, 2017, Ruben Kelevra <ruben@vfn-nrw.de> wrote:
> Hey Thiemo,
>
> On 04.12.2017 10:43, Thiemo Kreuz wrote:> I consider myself an image
> file format nerd, so thanks a lot for
>> sharing this! FLIF was new to me.Don't mind it! :)
>
>> I would like to share two important notes:
>>
>> 1. Unfortunately the flif.info website does not say a word about the
>> CPU resources their current implementation burns when converting a,
>> let's say, PNG to FLIF.Well, currently it's single core and not
> optimized at all. You should know CABAC encoding from x264/x265 so it's
> slow, but not dead slow.
>
> The website doesn't mention it because it highly depends on the subject
> as well as the setting on encoding named effort.
>
> Currently, effort is default 60, I tried 100 a lot, but there's nearly
> nothing to gain. So I assume we always want to use the good default. :)
>
> PNG Encoding of the current featured picture of today[1] at a medium
> image size for the web, 1.280×868 Pixel, opened in Gimp, converted to
> sRGB and exported as maximum compression without any checkbox done in
> Gimp ... takes Gimp 3 seconds to write it to the Harddisk.
>
> Transcoding this PNG to FLIF takes on my machine (i3-2330M@2.20GHz; 12
> GB RAM):
> real 0m7,405s
> user 0m7,320s
> sys 0m0,053s
>
> decoding the file again to PNG on the same machine (with FLIF)
> real 0m1,077s
> user 0m1,067s
> sys 0m0,007s
>
> For comparison, we save 708 KByte in comparison to PNG in this case, and
> the PNG exported by FLIF is just 14 KByte bigger than the one created by
> Gimp.
>
>> It's pretty important to realize that CPU
>> resources are even more valuable than storage space and network
>> bandwidth. Sure, It's not really possible to come up with an exact
>> threshold. But if, let's say, converting a PNG to FLIF saves 100 KiB,
>> but takes a minute, this minute will never pay off.
> So my Point was more: Get rid of this bloody Download a JPG, do some
> Stuff & Upload a 3 Times locally saved JPG again, calling it an
improvement.
>
>> If you follow the discussions on Wikimedia Commons, you will find this
>> argument quite often: Downloading PNGs, optimizing them, and uploading
>> them again is practically never worth it. Think of all the resources
>> that are burned to do this: CPU time, download and upload, database
>> storage and time, disk storage for the new revision, and not to forget
>> the user doing all this.
> Yep, but enabling FLIF for new files would do nothing to the old Data at
> all, I don't want to start a discussion about converting petabytes of
> Data, but all new revisions should be done in FLIF, if you ask me.
>> Sure, your suggestion avoids a lot of this. But the CPUs involved will
>> experience heavy load, both on the server as well as clients that need
>> to recode FLIF files via a JavaScript library first.
> FLIF is very fast to decode via JavaScript, and in general, as the
> example shown above, it takes just 1 second to decode and encode a
> medium size image as PNG with just one thread on a pretty outdated
> notebook with an unoptimized decoder and encoder. :)
>
> Try adding a FLIF to a website and test out if the website load anywhat
> slower with the FLIF ... at the small image sizes you get on articles,
> the performance impact is neglectable and comparable to loading a font
> file to the browser.
>> 2. Lossy file formats like JPEG should never be converted to lossless
>> formats. This will actually decrease quality (over time). The problem
>> is that the image data will still contain the exact same JPEG
>> artifacts, but the fact that it was a JPEG (and how it was encoded) is
>> lost.
> Yes, but those images should never be saved as JPG in the first place.
> Even under Android RAW-Photography is going to be a thing. FLIF just
> started to get rudimentary RAW-capabilities, which means you can just
> convert the special RAW-File to a FLIF and upload it with any loss in
> quality.
>
>> No tool specialized in squeezing the maximum quality out of
>> lossy JPEGs can work anymore. And there are a lot of super-awesome
>> tools like this. Not only tools like JPEGCROP and such that can cut
>> and even combine JPEGs without actually recoding them.
> Well, if you really want to start a discussion about a lossless rotation
> of JPG files, let me guess how many uploads are rotated losslessly...
> 0.0002%?
>
>> There are also "JPEG repair" filters that know how to reverse the JPEG
> encoding
>> algorithm and can squeeze out a tiny little bit of extra information
>> regular JPEG decoders can't see.
> Great! Just recommend this for new uploads to be done if the source
> material is JPG, let the ppl convert it with this to PNG and then to
> FLIF or ask the FLIF maintainers if they want to add this as an
> import-filter, for FLIF itself! :)
>
> But the your argument was: "Think of all the resources that are burned
> to do this: CPU time, download and upload, database storage and time,
> disk storage for the new revision, and not to forget the user doing all
> this."
>
> Which perfectly fit's here too. On a 20 MPixel picture small JPG
> Artefacts are no issue at all, but users which Download the JPG and
> upload it again, after doing some needed work to it, like cropping or
> color enhancement, this is a problem. Each version get more artifacts
> and we constantly get a loss of quality which each revision...
>
> I don't think we should have accepted JPGs in the first place. :)
>
>> This said, I'm all for adding FLIF to the list of allowed file formats!
> Wonderful, hope I get some feedback from you on the things I pointed out!
:)
> If you want to let a note on the GIMP/eog enhancement request, feel free
> to do so:
> https://bugzilla.gnome.org/buglist.cgi?quicksearch=flif
>
> [1] File:Umschreibung by Olafur Eliasson, Munich, December 2016 -04.jpg
>
> Best regards
>
>
> Ruben
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Changing a crucial element of the fifth most popular website on the
Internet may be a good example for an article about [[PITA]] :D

While I'm open to new formats/technologies I think a fundamental
prerequisite is a widespread support among browsers/clients. JS-only
support will severely weaken user experience for high-latency users,
destroying it for non-JS users.

Also, we currently have not enough resources to pioneer and, furthermore,
we are bound -per mission- to serve our content in the most accessible way.

Vito

2017-12-04 23:09 GMT+01:00 Brian Wolff <bawolff@gmail.com>:

> An encode latency of 7 seconds and decode latency of 1 second arent what I
> would call "very fast" (the decode latency measurement probably isnt
> realistic as decode and encode to png is different from just display in
> browser. Then again all these measurements are going to vary by filesize,
> not to mention low power devices like phones)
>
> If it indeed takes 1 second to decode, thats probably more time than the
> space savings would save time wise on a moderate speed internet connection.
>
> And time is only one metric. Often image encoding is limitted by memory.
>
>
> Anyways i'd be opposed to this unless the bandwidth saving was extreme.
> Wikipedia is not the place to be a testing ground for experimental image
> formats that browsers arent even supporting.
>
>
> --
> bawolff
>
> p.s.lossless rotatio /cropping of jpegs is actually very common due to
> rotatebot
>
> On Monday, December 4, 2017, Ruben Kelevra <ruben@vfn-nrw.de> wrote:
> > Hey Thiemo,
> >
> > On 04.12.2017 10:43, Thiemo Kreuz wrote:> I consider myself an image
> > file format nerd, so thanks a lot for
> >> sharing this! FLIF was new to me.Don't mind it! :)
> >
> >> I would like to share two important notes:
> >>
> >> 1. Unfortunately the flif.info website does not say a word about the
> >> CPU resources their current implementation burns when converting a,
> >> let's say, PNG to FLIF.Well, currently it's single core and not
> > optimized at all. You should know CABAC encoding from x264/x265 so it's
> > slow, but not dead slow.
> >
> > The website doesn't mention it because it highly depends on the subject
> > as well as the setting on encoding named effort.
> >
> > Currently, effort is default 60, I tried 100 a lot, but there's nearly
> > nothing to gain. So I assume we always want to use the good default. :)
> >
> > PNG Encoding of the current featured picture of today[1] at a medium
> > image size for the web, 1.280×868 Pixel, opened in Gimp, converted to
> > sRGB and exported as maximum compression without any checkbox done in
> > Gimp ... takes Gimp 3 seconds to write it to the Harddisk.
> >
> > Transcoding this PNG to FLIF takes on my machine (i3-2330M@2.20GHz; 12
> > GB RAM):
> > real 0m7,405s
> > user 0m7,320s
> > sys 0m0,053s
> >
> > decoding the file again to PNG on the same machine (with FLIF)
> > real 0m1,077s
> > user 0m1,067s
> > sys 0m0,007s
> >
> > For comparison, we save 708 KByte in comparison to PNG in this case, and
> > the PNG exported by FLIF is just 14 KByte bigger than the one created by
> > Gimp.
> >
> >> It's pretty important to realize that CPU
> >> resources are even more valuable than storage space and network
> >> bandwidth. Sure, It's not really possible to come up with an exact
> >> threshold. But if, let's say, converting a PNG to FLIF saves 100 KiB,
> >> but takes a minute, this minute will never pay off.
> > So my Point was more: Get rid of this bloody Download a JPG, do some
> > Stuff & Upload a 3 Times locally saved JPG again, calling it an
> improvement.
> >
> >> If you follow the discussions on Wikimedia Commons, you will find this
> >> argument quite often: Downloading PNGs, optimizing them, and uploading
> >> them again is practically never worth it. Think of all the resources
> >> that are burned to do this: CPU time, download and upload, database
> >> storage and time, disk storage for the new revision, and not to forget
> >> the user doing all this.
> > Yep, but enabling FLIF for new files would do nothing to the old Data at
> > all, I don't want to start a discussion about converting petabytes of
> > Data, but all new revisions should be done in FLIF, if you ask me.
> >> Sure, your suggestion avoids a lot of this. But the CPUs involved will
> >> experience heavy load, both on the server as well as clients that need
> >> to recode FLIF files via a JavaScript library first.
> > FLIF is very fast to decode via JavaScript, and in general, as the
> > example shown above, it takes just 1 second to decode and encode a
> > medium size image as PNG with just one thread on a pretty outdated
> > notebook with an unoptimized decoder and encoder. :)
> >
> > Try adding a FLIF to a website and test out if the website load anywhat
> > slower with the FLIF ... at the small image sizes you get on articles,
> > the performance impact is neglectable and comparable to loading a font
> > file to the browser.
> >> 2. Lossy file formats like JPEG should never be converted to lossless
> >> formats. This will actually decrease quality (over time). The problem
> >> is that the image data will still contain the exact same JPEG
> >> artifacts, but the fact that it was a JPEG (and how it was encoded) is
> >> lost.
> > Yes, but those images should never be saved as JPG in the first place.
> > Even under Android RAW-Photography is going to be a thing. FLIF just
> > started to get rudimentary RAW-capabilities, which means you can just
> > convert the special RAW-File to a FLIF and upload it with any loss in
> > quality.
> >
> >> No tool specialized in squeezing the maximum quality out of
> >> lossy JPEGs can work anymore. And there are a lot of super-awesome
> >> tools like this. Not only tools like JPEGCROP and such that can cut
> >> and even combine JPEGs without actually recoding them.
> > Well, if you really want to start a discussion about a lossless rotation
> > of JPG files, let me guess how many uploads are rotated losslessly...
> > 0.0002%?
> >
> >> There are also "JPEG repair" filters that know how to reverse the JPEG
> > encoding
> >> algorithm and can squeeze out a tiny little bit of extra information
> >> regular JPEG decoders can't see.
> > Great! Just recommend this for new uploads to be done if the source
> > material is JPG, let the ppl convert it with this to PNG and then to
> > FLIF or ask the FLIF maintainers if they want to add this as an
> > import-filter, for FLIF itself! :)
> >
> > But the your argument was: "Think of all the resources that are burned
> > to do this: CPU time, download and upload, database storage and time,
> > disk storage for the new revision, and not to forget the user doing all
> > this."
> >
> > Which perfectly fit's here too. On a 20 MPixel picture small JPG
> > Artefacts are no issue at all, but users which Download the JPG and
> > upload it again, after doing some needed work to it, like cropping or
> > color enhancement, this is a problem. Each version get more artifacts
> > and we constantly get a loss of quality which each revision...
> >
> > I don't think we should have accepted JPGs in the first place. :)
> >
> >> This said, I'm all for adding FLIF to the list of allowed file formats!
> > Wonderful, hope I get some feedback from you on the things I pointed out!
> :)
> > If you want to let a note on the GIMP/eog enhancement request, feel free
> > to do so:
> > https://bugzilla.gnome.org/buglist.cgi?quicksearch=flif
> >
> > [1] File:Umschreibung by Olafur Eliasson, Munich, December 2016 -04.jpg
> >
> > Best regards
> >
> >
> > Ruben
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
> Point was more: Get rid of this bloody Download a JPG, do some Stuff &
Upload a 3 Times locally saved JPG again […]

I'm afraid I did not made my point clear enough. With all respect to your
enthusiasm, but the scenario you describe is exactly what your suggestion
will not improve. How could it? We can not control what people do on their
local computers.

Even worse: FLIF is not even needed for the scenario you describe. We could
just convert all JPEG to PNG. But this will not happen for the reasons
collected in this thread.

> those images should never be saved as JPG in the first place.

Sure. Go and encourage people to upload RAW. That's very much welcome. But
converting their JPEG after they made them will make many scenarios worse.
Even including the one you aim for: What you want is to allow people to
download an image, open, edit and save it without ever thinking about the
file format. FLIF can not do that, yet.

Best
Thiemo
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Le 06/12/2017 à 14:27, Thiemo Kreuz a écrit :
> Sure. Go and encourage people to upload RAW. That's very much welcome.
Is it? I thought that Commons didn't include a RAW file format in its
list of authorized file type.
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Hey Thiemo,

On 06.12.2017 14:27, Thiemo Kreuz wrote:
>> Point was more: Get rid of this bloody Download a JPG, do some Stuff &
> Upload a 3 Times locally saved JPG again […]
>
> I'm afraid I did not made my point clear enough. With all respect to your
> enthusiasm, but the scenario you describe is exactly what your suggestion
> will not improve. How could it? We can not control what people do on their
> local computers.I'm sure we can't, but we can follow our primary goal,
to spread information and educate users to handle their contributed data
and time better. JPG has huge generation loss, that's why I always
choose PNG for my private files or use a program which can handle raw.

We don't educate the users currently about the right choice of file
formats, so they upload their files in the format which is available for
them.

Taking JPG directly from a camera which does not support raw is fine,
but we should take the step and convert this initial JPG to a lossless
format because:

Every user which edit those file will take the JPG and save a "new
version" in the same format because they want to preserve the filename.

If we would convert the JPG to PNG or FLIF, this step would be lossless
while we don't control anything on the user side.

This was my point.
> Even worse: FLIF is not even needed for the scenario you describe. We
could
> just convert all JPEG to PNG. But this will not happen for the reasons
> collected in this thread.

FLIF is better instead of PNG because it supports animations, is faster
to decode, use less disk space. Also saving it interlaced does not
increase the file size significantly and we just need to save one file
instead of at least 3 different versions of the same file: the
thumbnail, the zoomed version, and the original file.

With FLIF this file would be always the same while the browser would
limit the amount of data required for the display size.

> Sure. Go and encourage people to upload RAW. That's very much welcome. But
> converting their JPEG after they made them will make many scenarios worse.
Well, yeah, I tried several times in the past ... and no, my RAW-Format
is still not supported:

"Bei der Übertragung gab es einen Fehler
Auf diesem Wiki sind Dateien mit der Endung „.NEF“ nicht zulässig."

Means .NEF is not supported.

"Bei der Übertragung gab es einen Fehler
Auf diesem Wiki sind Dateien mit der Endung „.DNG“ nicht zulässig."

Means, .DNG is not supported.

With FLIF we could simply accept all which does have a free decoder and
convert them to FLIF. Which would 'free' the file format. :)

> Even including the one you aim for: What you want is to allow people to
> download an image, open, edit and save it without ever thinking about the
> file format. FLIF can not do that, yet.
Since we could easily convert the FLIF on export to PNG and any new
version could be uploaded in PNG an internally converted to FLIF to
reduce the disk space requirements as well.

I hope GIMP and Gnome will support FLIF soon.


Thanks a lot for your critic, I appreciate our discussion. :)


Best regards


Ruben

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Sooooo... to break the current discussion down, there is no hard "we
don't want this format" yet shown up.

What's the next step guys? Generate a feature request for MediaWiki
which enables FLIF as possible input-format and ships the poly-flif
JavaScript library for browsers which does not natively support FLIF?

We talk here about the chicken-egg problem, so yeah, this javascript
crap is hard to swallow, but we must start somewhere, right?

Best regards

Ruben

On 08.12.2017 22:00, Ruben Wisniewski wrote:
> Hey Thiemo,
>
> On 06.12.2017 14:27, Thiemo Kreuz wrote:
>>> Point was more: Get rid of this bloody Download a JPG, do some Stuff &
>> Upload a 3 Times locally saved JPG again […]
>>
>> I'm afraid I did not made my point clear enough. With all respect to your
>> enthusiasm, but the scenario you describe is exactly what your suggestion
>> will not improve. How could it? We can not control what people do on their
>> local computers.I'm sure we can't, but we can follow our primary goal,
> to spread information and educate users to handle their contributed data
> and time better. JPG has huge generation loss, that's why I always
> choose PNG for my private files or use a program which can handle raw.
>
> We don't educate the users currently about the right choice of file
> formats, so they upload their files in the format which is available for
> them.
>
> Taking JPG directly from a camera which does not support raw is fine,
> but we should take the step and convert this initial JPG to a lossless
> format because:
>
> Every user which edit those file will take the JPG and save a "new
> version" in the same format because they want to preserve the filename.
>
> If we would convert the JPG to PNG or FLIF, this step would be lossless
> while we don't control anything on the user side.
>
> This was my point.
>> Even worse: FLIF is not even needed for the scenario you describe. We
> could
>> just convert all JPEG to PNG. But this will not happen for the reasons
>> collected in this thread.
>
> FLIF is better instead of PNG because it supports animations, is faster
> to decode, use less disk space. Also saving it interlaced does not
> increase the file size significantly and we just need to save one file
> instead of at least 3 different versions of the same file: the
> thumbnail, the zoomed version, and the original file.
>
> With FLIF this file would be always the same while the browser would
> limit the amount of data required for the display size.
>
>> Sure. Go and encourage people to upload RAW. That's very much welcome. But
>> converting their JPEG after they made them will make many scenarios worse.
> Well, yeah, I tried several times in the past ... and no, my RAW-Format
> is still not supported:
>
> "Bei der Übertragung gab es einen Fehler
> Auf diesem Wiki sind Dateien mit der Endung „.NEF“ nicht zulässig."
>
> Means .NEF is not supported.
>
> "Bei der Übertragung gab es einen Fehler
> Auf diesem Wiki sind Dateien mit der Endung „.DNG“ nicht zulässig."
>
> Means, .DNG is not supported.
>
> With FLIF we could simply accept all which does have a free decoder and
> convert them to FLIF. Which would 'free' the file format. :)
>
>> Even including the one you aim for: What you want is to allow people to
>> download an image, open, edit and save it without ever thinking about the
>> file format. FLIF can not do that, yet.
> Since we could easily convert the FLIF on export to PNG and any new
> version could be uploaded in PNG an internally converted to FLIF to
> reduce the disk space requirements as well.
>
> I hope GIMP and Gnome will support FLIF soon.
>
>
> Thanks a lot for your critic, I appreciate our discussion. :)
>
>
> Best regards
>
>
> Ruben
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
On Sun, 2017-12-10 at 21:42 +0100, Ruben Kelevra wrote:
> Sooooo... to break the current discussion down, there is no hard "we
> don't want this format" yet shown up.
>
> What's the next step guys?

Working on widespread FLIF support among browsers/clients, to not
require JavaScript support in browsers. In my humble opinion...

andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Sadly Google stick to cheer for their WebP-crap, my ticket #539120 for
the chromium project dated back to late 2015, while there are some
supporters, the main reason was back then 'it's not yet finalized' which
isn't true anymore.

Since we need the Poly-flif stuff anyway - not any user uses the latest
or the most advanced browser(s/ versions) - it's a good starting point,
isn't it?

I also create a feature request for all my daily driver software to get
FLIF support to this stuff too.


Best regards

Ruben

On 10.12.2017 22:10, Andre Klapper wrote:
> On Sun, 2017-12-10 at 21:42 +0100, Ruben Kelevra wrote:
>> Sooooo... to break the current discussion down, there is no hard "we
>> don't want this format" yet shown up.
>>
>> What's the next step guys?
>
> Working on widespread FLIF support among browsers/clients, to not
> require JavaScript support in browsers. In my humble opinion...
>
> andre
>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Hey Andre,

On 10.12.2017 22:10, Andre Klapper wrote:
> On Sun, 2017-12-10 at 21:42 +0100, Ruben Kelevra wrote:
>> Sooooo... to break the current discussion down, there is no hard "we
>> don't want this format" yet shown up.
>>
>> What's the next step guys?
>
> Working on widespread FLIF support among browsers/clients, to not
> require JavaScript support in browsers. In my humble opinion...
Well, I tried it again:

https://bugs.chromium.org/p/chromium/issues/detail?id=793683

Maybe this time they'll be a bit more open since WebP haven't been
getting off the ground for two years and FLIF still looks a lot more
promising in my eyes.


Best regards

Ruben

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Maybe not a hard no, but I would rate the probability as somewhere around
1%.

If you really wanted to push this (with the understanding that its probably
not going anywhere) I would say make a report, comingup with a solid case
with a solid implementation plan, including:
* what is the fallback plan for non js users and users with old browsers
* what would the bandwidth saving be in typical usage on typical wikipedia
pages
* what is the server side latency on an uncached hit where we have to
generate a thumbnail for the request, compared to existing formats
*what is the client side latency to render with the polyfill compared to
native format. What happens during rendering? What about people using
old-generation cell phones with lackluster cpus? Is it in a separate worker
thread or does it stop the main js thread? What is the general affect to
the user during polyfil loading.
*combining server side latency, client side latency bandwidth difference,
etc what is the overall difference in loading time for the user on a
typical wikipedia page- and what is it for a (client side) cached hit vs
(server side i.e. thumb is already rendered) vs totally uncached where
thumbnail has to be converted on the fly.

I think that would be the minimum information required to convince people
to do this, and i doubt that that would be enough unless the numbers are
super good.

--
bawolff

On Sunday, December 10, 2017, Ruben Kelevra <ruben@vfn-nrw.de> wrote:
> Sooooo... to break the current discussion down, there is no hard "we
> don't want this format" yet shown up.
>
> What's the next step guys? Generate a feature request for MediaWiki
> which enables FLIF as possible input-format and ships the poly-flif
> JavaScript library for browsers which does not natively support FLIF?
>
> We talk here about the chicken-egg problem, so yeah, this javascript
> crap is hard to swallow, but we must start somewhere, right?
>
> Best regards
>
> Ruben
>
> On 08.12.2017 22:00, Ruben Wisniewski wrote:
>> Hey Thiemo,
>>
>> On 06.12.2017 14:27, Thiemo Kreuz wrote:
>>>> Point was more: Get rid of this bloody Download a JPG, do some Stuff &
>>> Upload a 3 Times locally saved JPG again […]
>>>
>>> I'm afraid I did not made my point clear enough. With all respect to
your
>>> enthusiasm, but the scenario you describe is exactly what your
suggestion
>>> will not improve. How could it? We can not control what people do on
their
>>> local computers.I'm sure we can't, but we can follow our primary goal,
>> to spread information and educate users to handle their contributed data
>> and time better. JPG has huge generation loss, that's why I always
>> choose PNG for my private files or use a program which can handle raw.
>>
>> We don't educate the users currently about the right choice of file
>> formats, so they upload their files in the format which is available for
>> them.
>>
>> Taking JPG directly from a camera which does not support raw is fine,
>> but we should take the step and convert this initial JPG to a lossless
>> format because:
>>
>> Every user which edit those file will take the JPG and save a "new
>> version" in the same format because they want to preserve the filename.
>>
>> If we would convert the JPG to PNG or FLIF, this step would be lossless
>> while we don't control anything on the user side.
>>
>> This was my point.
>>> Even worse: FLIF is not even needed for the scenario you describe. We
>> could
>>> just convert all JPEG to PNG. But this will not happen for the reasons
>>> collected in this thread.
>>
>> FLIF is better instead of PNG because it supports animations, is faster
>> to decode, use less disk space. Also saving it interlaced does not
>> increase the file size significantly and we just need to save one file
>> instead of at least 3 different versions of the same file: the
>> thumbnail, the zoomed version, and the original file.
>>
>> With FLIF this file would be always the same while the browser would
>> limit the amount of data required for the display size.
>>
>>> Sure. Go and encourage people to upload RAW. That's very much welcome.
But
>>> converting their JPEG after they made them will make many scenarios
worse.
>> Well, yeah, I tried several times in the past ... and no, my RAW-Format
>> is still not supported:
>>
>> "Bei der Übertragung gab es einen Fehler
>> Auf diesem Wiki sind Dateien mit der Endung „.NEF“ nicht zulässig."
>>
>> Means .NEF is not supported.
>>
>> "Bei der Übertragung gab es einen Fehler
>> Auf diesem Wiki sind Dateien mit der Endung „.DNG“ nicht zulässig."
>>
>> Means, .DNG is not supported.
>>
>> With FLIF we could simply accept all which does have a free decoder and
>> convert them to FLIF. Which would 'free' the file format. :)
>>
>>> Even including the one you aim for: What you want is to allow people to
>>> download an image, open, edit and save it without ever thinking about
the
>>> file format. FLIF can not do that, yet.
>> Since we could easily convert the FLIF on export to PNG and any new
>> version could be uploaded in PNG an internally converted to FLIF to
>> reduce the disk space requirements as well.
>>
>> I hope GIMP and Gnome will support FLIF soon.
>>
>>
>> Thanks a lot for your critic, I appreciate our discussion. :)
>>
>>
>> Best regards
>>
>>
>> Ruben
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
Hey Brian,

On 11.12.2017 00:10, Brian Wolff wrote:
> Maybe not a hard no, but I would rate the probability as somewhere around
> 1%.
>
> If you really wanted to push this (with the understanding that its probably
> not going anywhere) I would say make a report, comingup with a solid case
> with a solid implementation plan, including:
> * what is the fallback plan for non js users and users with old browsers
> * what would the bandwidth saving be in typical usage on typical wikipedia
> pages
> * what is the server side latency on an uncached hit where we have to
> generate a thumbnail for the request, compared to existing formats
> *what is the client side latency to render with the polyfill compared to
> native format. What happens during rendering? What about people using
> old-generation cell phones with lackluster cpus? Is it in a separate worker
> thread or does it stop the main js thread? What is the general affect to
> the user during polyfil loading.
> *combining server side latency, client side latency bandwidth difference,
> etc what is the overall difference in loading time for the user on a
> typical wikipedia page- and what is it for a (client side) cached hit vs
> (server side i.e. thumb is already rendered) vs totally uncached where
> thumbnail has to be converted on the fly.
>
> I think that would be the minimum information required to convince people
> to do this, and i doubt that that would be enough unless the numbers are
> super good.
Thanks alot for this open feedback, Brian. I think about that. :)


Best regards

Ruben

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
10 ???. 2017 ?. 23:42 ???????????? "Ruben Kelevra" <ruben@vfn-nrw.de>
???????:

Sooooo... to break the current discussion down, there is no hard "we
don't want this format" yet shown up.


Nope, you've been provided ample reasons why a phab ticket requesting this
will probably be declined on the spot.
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
If you want to work on implementing support for FLIF, I would recommend
doing it as an extension (similar to e.g.
https://www.mediawiki.org/wiki/Extension:PdfHandler) rather than in
MediaWiki core.

--
Bartosz Dziewo?ski

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
I concur with the extension idea.
I'd add that have options for degrees of using FLIF would be a good idea as
well. I.E. the decision could be to simply 1) accept FLIF (and possibly
serve PNG thumbs for browsers without js), to 2) encourage FLIF use, or to
3)"force" FLIF by converting everything to FLIF and serving only FLIF
versions to browsers.

Even option 1 seems unlikely to gather support at this point, but it is a
lot more likely than option 3.

Chico Venancio

2017-12-11 14:22 GMT-03:00 Bartosz Dziewo?ski <matma.rex@gmail.com>:

> If you want to work on implementing support for FLIF, I would recommend
> doing it as an extension (similar to e.g. https://www.mediawiki.org/wiki
> /Extension:PdfHandler) rather than in MediaWiki core.
>
> --
> Bartosz Dziewo?ski
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: FLIF for Wikimedia [ In reply to ]
To be clear, there are generally no objections to "1) accept FLIF (and possibly
serve PNG thumbs for browsers without js" other than convince commons
it would be a good idea to accept the format. All the controversial
bit is converting files to FLIF. Accepting FLIF files for upload is
non-controversial if the communities want them.

--
Brian

On Mon, Dec 11, 2017 at 5:30 PM, Chico Venancio
<chicocvenancio@gmail.com> wrote:
> I concur with the extension idea.
> I'd add that have options for degrees of using FLIF would be a good idea as
> well. I.E. the decision could be to simply 1) accept FLIF (and possibly
> serve PNG thumbs for browsers without js), to 2) encourage FLIF use, or to
> 3)"force" FLIF by converting everything to FLIF and serving only FLIF
> versions to browsers.
>
> Even option 1 seems unlikely to gather support at this point, but it is a
> lot more likely than option 3.
>
> Chico Venancio
>
> 2017-12-11 14:22 GMT-03:00 Bartosz Dziewo?ski <matma.rex@gmail.com>:
>
>> If you want to work on implementing support for FLIF, I would recommend
>> doing it as an extension (similar to e.g. https://www.mediawiki.org/wiki
>> /Extension:PdfHandler) rather than in MediaWiki core.
>>
>> --
>> Bartosz Dziewo?ski
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l