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 <[email protected]> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
