_don't consider the upload complete_ until those are done! a web uploader
or API-using bot should probably wait until it's done before uploading the
next file, for instance...
You got me a little confused at that point, are you talking about the
client generating the intermediary sizes, or
Another point about picking the one true bucket list: currently Media
Viewer's buckets have been picked based on the most common screen
resolutions, because Media Viewer tries to always use the entire width of
the screen to display the image, so trying to achieve a 1-to-1 pixel
correspondence
An extremely crude benchmark on our multimedia labs instance, still using
the same test image:
original - 3002 (original size) 0m0.268s
original - 2048 0m1.344s
original - 1024 0m0.856s
original - 512 0m0.740s
original - 256 0m0.660s
2048 - 1024 0m0.444s
2048 - 512 0m0.332s
2048 - 256 0m0.284s
Hi Gilles,
Thanks for the comparison images. When I was playing around with this
a while back, I found that images with lots of parallel lines and lots
of easily recognized detail were the best to see what sorts of
problems rescaling can cause. Here's a few
On Thu, May 1, 2014 at 3:54 AM, Gilles Dubuc gil...@wikimedia.org wrote:
_don't consider the upload complete_ until those are done! a web uploader
or API-using bot should probably wait until it's done before uploading
the
next file, for instance...
You got me a little confused at
The slowest part of large images scaling in production is their retrieval
from Swift, which could be much faster for bucketed images.
On Thu, May 1, 2014 at 7:57 AM, Gilles Dubuc gil...@wikimedia.org wrote:
An extremely crude benchmark on our multimedia labs instance, still using
the same
On 01-05-2014 16:57, Gilles Dubuc wrote:
And here's a side-by-side comparison of these images generated with
chaining and images that come from our regular image scalers:
https://dl.dropboxusercontent.com/u/109867/imagickchaining/index.html Try
to guess which is which before inspecting the page
Dear all,
sorry for cross-posting but I just have sent all participants of the
Hackathon a PDF with travel information and a personalized public
transport ticket.
Should you plan to attend the Hackathon but have not received the Travel
Information mail, then please contact me.
Thanks and
Thank you to everybody who participated in this bugday!
We managed to update about 50 tickets and moved 29 tickets out of the
General/Unknown bucket. More details on
https://www.mediawiki.org/wiki/Bug_management/Triage/20140429
andre
On Thu, 2014-04-24 at 00:21 +0530, Andre Klapper wrote:
Hi Tony,
could you clarify your intention for this email?
Are you seeking for more input whether it's a good idea, or if this
actually needed? Or are you searching for agreement as you plan to work
on a patch yourself? Or are you looking for somebody to work on this?
It's not entirely clear to
hi,
is there a possibility to get a banner on enwp for ghana to wiki loves
earth, as this is this years main contest there?
https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Earth_2014_in_Ghana
rupert
-- Forwarded message --
From: Enock Seth Nyamador kwadzo...@gmail.com
On May 1, 2014 6:22 PM, rupert THURNER rupert.thur...@gmail.com wrote:
is there a possibility to get a banner on enwp for ghana to wiki loves
earth, as this is this years main contest there?
https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Earth_2014_in_Ghana
That doesn't have anything to
Update.
-- Forwarded message --
From: Adam Baso ab...@wikimedia.org
Date: Thu, May 1, 2014 at 7:52 PM
Subject: Re: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation
To: Wikimedia Mailing List wikimedi...@lists.wikimedia.org
After examining this, it looks like
13 matches
Mail list logo
