In a surprising turn of events, the latest survey
https://www.surveymonkey.com/s/F6CGPDJ shows that people consistently
prefer the chained thumbnails (each thumbnail generated based on the next
bigger thumbnail) to the ones we currently generate from the original and
to thumbnails generated all
After taking a closer look at what commands run exactly in production, it
turns out that I probably applied the IM parameters in the wrong order when
I put together the survey (order matters, particularly for sharpening).
I'll regenerate the images and make another (hopefully better) survey that
Buttons is French: Suiv. - Make it English
That's a bug in SurveyMonkey, the buttons are in French because I was using
the French version of the site at the time the survey was created, and now
that text on those buttons can't be fixed. I'll make sure to switch
SurveyMoney to English before
Another round, using one of Rob's test images.
The directly scaled images look sharper.
I've now realized that our image scaler uses the -sharpen option in most
cases (as long as the thumbnail is 0.85 times the size of the original or
smaller, if I'm reading the code correctly). This time I
On Thu, May 1, 2014 at 7:02 AM, Gilles Dubuc gil...@wikimedia.org wrote:
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
_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
There've been some issues reported lately with image scaling, where
resource usage on very large images has been huge (problematic for batch
uploads from a high-resolution source). Even scaling time for typical
several-megapixel JPEG photos can be slower than desired when loading up
into something
On 04/30/2014 12:51 PM, Brion Vibber wrote:
* at upload time, perform a series of scales to produce the mipmap levels
* _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
14 matches
Mail list logo
