Bug 1195 : Bilinear filtering hard-coded in internal blit function
Last modified: 2010-06-05 03:05




Status:
ASSIGNED
Resolution:
-
Priority:
P2
Severity:
enhancement

 

Reporter:
-RoB-
Assigned To:
fry

Attachment Type Created Size Actions

Description:   Opened: 2009-03-10 16:22
As part of the cleaning up of the API for PImage in Revision 4720, the internal blit function
was hard-coded to use bilinear filtering with the following at line 1428:

boolean smooth = true; // may as well go with the smoothing these days

I would like to question the logic behind this change. While I understand the thinking behind
this comment, there are some occasions when using nearest neighbour to blit is desired, e.g.,
to achieve pixelation when zooming into an image.

Can the old behavior, using smooth() and noSmooth() to control the use of bilinear filtering,
be reinstated?

----

NOTE: This change to the blit function has made the documentation for copy() misleading, as
the image in the documentation clearly shows pixelation.

PImage img = loadImage("eames.jpg");
image(img, 0, 0);
copy(15, 25, 10, 10, 35, 25, 50, 50);

The example code is inaccurate in other ways (stroke color and rect position) but these are
perhaps less problematic than the representation of the effect of copying a small area to a
larger one.
Additional Comment #1 From fry 2010-06-05 03:05
the logic is that 1) cpu cycles (the reason for the pixelation) is less of
an issue, 2) almost nobody wants pixelated images, and 3) it's a mess to
make smooth/noSmooth and the rest of the functions that deal with images
handle this kind of situation consistently across all of the renderers,
which comes back to #2. my free time is limited, and i have to choose my
battles.

i'll leave it as a feature request if someone wants to take care of making
this work consistently across the rest of the API.
This bug is now being tracked here.