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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l