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