> > _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 the server? I think client-side thumbnail generation is risky when things start getting corrupt. A client-side bug could result in a user uploading thumbnails that are for a different image. And if you want to run a visual signature check on the server-side to avoid that issue, you might be looking at similar processing time checking that the thumbnail is for the correct image then if the server was to generate the actual thumbnail. It would be worth researching if there's a very fast "is this thumbnail a smaller version of that image" algorithm out there. We don't need 100% confidence either, if we're looking to avoid shuffling bugs in a given upload batch. Regarding the issue of a single intermediary size versus multiple, there's still a near-future plan to have pregenerated buckets for Media Viewer (which can be reused for a whole host of other things). Those could be used like mip-maps like you describe. Since these sizes will be generated at upload time, why not use them? However quality starts to introduce noticeable visual artifacts when the bucket (source image)'s dimensions are too close to the thumbnail you want to render. Consider the existing Media Viewer width buckets: 320, 640, 800, 1024, 1280, 1920, 2560, 2880 I think that generating the 300px thumbnail based on the 320 bucket is likely to introduce very visible artifacts with thin lines, etc. compared to using the biggest bucket (2880px). Maybe there's a smart compromise, like picking the higher bucket (eg. 300px thumbnail would use the 640 bucket as its source, etc.). I think that we need a battery of visual test to determine what's the best strategy here. All of this is dependent on Ops giving the green light for pregenerating the buckets, though. The swift capacity for it is slowing being brought online, but I think Ops' prerequisite wish to saying yes to it is that we focus on the post-swift strategy for thumbnails. We also need to figure out the performance impact of generating all these thumbnails on upload. On a very meta note, we might generate the smaller buckets based on the biggest bucket and only the 2-3 biggest buckets based on the original (still to avoid visual artifacts). Another related angle I'd like to explore is to submit a simplified version of this RFC: https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizeswhere we'd propose a single bucket list option instead of multiple (presumably, the Media Viewer ones, if not, we'd update Media Viewer to use the new canon list of buckets). And where we would still allow arbitrary thumbnail sizes below a certain limit. For example, people would still be allowed to request thumbnails that are smaller than 800px at any size they want, because these are likely to be thumbnails in the real sense of the term, and for anything above 800px they would be limited to the available buckets (eg. 1024, 1280, 1920, 2560, 2880). This would still allow foundation-hosted wikis to have flexible layout strategies with their thumbnail sizes, while reducing the craziness of this attack vector on the image Scalers and gigantic waste of disk and memory space on the thumbnail hosting. I think it would be an easier sell for the community, the current RFC is too extreme in banning all arbitrary sizes and offers too many bucketing options. I feel like the standardization of true thumbnail sizes (small images, <800px) is much more subject to endless debate with no consensus. On Thu, May 1, 2014 at 12:21 PM, Erwin Dokter <er...@darcoury.nl> wrote: > 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 instance... >> * once upload is complete, keep on making user-facing thumbnails as >> before... but make them from the smaller mipmap levels instead of the >> full-scale original >> > > Would it not suffice to just produce *one* scaled down version (ie. > 2048px) which the real-time scaler can use to produce the thumbs? > > Regards, > -- > Erwin Dokter > > > > _______________________________________________ > 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
