Re: [Wikitech-l] You can now vote in the Community Wishlist Survey

[Johan Jönsson]

On Tue, Nov 28, 2017 at 7:01 AM, Johan Jönsson  wrote:
> Hey everyone,
>
> The voting phase of the 2017 Community Wishlist Survey has now started. Read
> the proposals and support the ones you want to support to make the wikis
> better:
> https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey

As a last reminder – if you wanted to check this out but haven't, you
can vote for another 12 hours.

//Johan Jönsson
--

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

Re: [Wikitech-l] FLIF for Wikimedia

[Brian Wolff]

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  wrote:
> So... 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 

Re: [Wikitech-l] FLIF for Wikimedia

[Ruben Kelevra]

Hey Andre,

On 10.12.2017 22:10, Andre Klapper wrote:
> On Sun, 2017-12-10 at 21:42 +0100, Ruben Kelevra wrote:
>> So... 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: [Wikitech-l] FLIF for Wikimedia

[Ruben Kelevra]

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:
>> So... 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: [Wikitech-l] FLIF for Wikimedia

[Andre Klapper]

On Sun, 2017-12-10 at 21:42 +0100, Ruben Kelevra wrote:
> So... 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: [Wikitech-l] FLIF for Wikimedia

[Ruben Kelevra]

So... 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