René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"implement means to specify smoothing with PImage.resize()","articleBody":"_Original author: b...@processing.org (June 07, 2010 01:13:31)_\n\nThis bug automatically added from:\nhttp://dev.processing.org/bugs/show_bug.cgi?id=1195\n\nComment from -RoB-, 2009-03-10 16:22\n\nAs part of the cleaning up of the API for PImage in Revision 4720, the internal blit function \nwas hard-coded to use bilinear filtering with the following at line 1428:\n\n  boolean smooth = true;  // may as well go with the smoothing these days\n\nI would like to question the logic behind this change. While I understand the thinking behind \nthis comment, there are some occasions when using nearest neighbour to blit is desired, e.g., \nto achieve pixelation when zooming into an image.\n\nCan the old behavior, using smooth() and noSmooth() to control the use of bilinear filtering, \nbe reinstated?\n\n---\n\nNOTE: This change to the blit function has made the documentation for copy() misleading, as \nthe image in the documentation clearly shows pixelation.\n\n  PImage img = loadImage(\"eames.jpg\");\n  image(img, 0, 0);\n  copy(15, 25, 10, 10, 35, 25, 50, 50);\n\nThe example code is inaccurate in other ways (stroke color and rect position) but these are \nperhaps less problematic than the representation of the effect of copying a small area to a \nlarger one.\n\n_Original issue: http://code.google.com/p/processing/issues/detail?id=165_\n","author":{"url":"https://github.com/processing-bugs","@type":"Person","name":"processing-bugs"},"datePublished":"2013-02-10T16:07:33.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/204/processing/issues/204"}