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
