P5.js: get() returns pixel/image inconsitently

[Spongman]

re: https://codepen.io/Spongman/pen/wNeoJd?editors=0011

here's a table of the return type of get(x,y,w,h) based on different values for passed parameters.

size\coord             0,0         -1,0        -100,-100   undefined,undefined
undefined x undefined  pixel       pixel       pixel       image       
NaN x NaN              image       image       image       image       
0 x 0                  image       pixel       pixel       image       
1 x 0                  image       image       pixel       image       
1 x 1                  pixel       pixel       pixel       pixel       
2 x 2                  image       image       pixel       image       

there's a lot of strange inconsitencies here, and IMO _only_ get(number, number) should return a pixel array, and _everything_ else should return an Image (or perhaps an error).

ie, it I believe it would be more consistent if it read:

size\coord             0,0         -1,0        -100,-100   undefined,undefined
undefined x undefined  pixel       pixel       pixel       image       
NaN x NaN              ?           ?           ?           ?          
0 x 0                  image       image       image       image       
1 x 0                  image       image       image       image       
1 x 1                  image       image       image       image       
2 x 2                  image       image       image       image       

this would make the actual returned value match up with what is specified in the docs.

[hellonearthis]

1 x 1 should be a pixel, so many strange use cases.

[Spongman]

well, currently 1x1 _does_ return a pixel, and that's one of the inconsitencies i was talking about.

there is already a way to return the pixel value at a given point: get(x,y), i don't think there's a need to have get(x,y,1,1) do precisely the same thing, especially since there is currently _no_ other way to get a 1x1 Image from that method.

IMHO the result of an overloaded method should depend on the _types_ of its arguments, not the values (this is the reason that this method doesn't call validateParameters). I believe the docs should list 3 different overloads of this method that are strictly adhered to:

• get() : returns an image
• get(x,y) : returns a pixel
• get(x, y, w, h) : returns an image

consider writing a program that requires fetching arbitrary sized and arbitrarily positioned sub-images from a given image/canvas. with the current code you have to special-case the cases where the required size is 1x1 or the requested image is outside the source range. i'm finding it hard to think of a case where either the current behavior of get(x,y,1,1) or the out-of-bounds returning a pixel behavior makes sense.

[Spongman]

just putting some links in here for reference:

• #2720 Get() only returns pixel
• #2330 get() image function trouble with w,h parameters
• #1040 p5.Renderer2D.get() not working with bounds outside the top or left side of canvas
• #1041 Fix for get() not working with bounds outside the top or left side of canvas
• #1038 p5.Renderer2D.get() partially handles overlapping and does not handle cropping

[Spongman]

here's an example that demonstrates the returned value of get(x,y,w,h) changing type from image to pixel array when the bounds go out of range. the rectangle is drawn red when the type is wrong:

https://codepen.io/Spongman/pen/dazybG?editors=0011

here's an example where instead of returning a 1x1 image, it returns a pixel array. this time it just crashes:

https://codepen.io/Spongman/pen/rPzNZV?editors=0011

[limzykenneth]

For me the proposal of

• get() : returns an image
• get(x,y) : returns a pixel
• get(x, y, w, h) : returns an image

sounds reasonable.

[meiamsome]

What's the purpose of overloading this function so much?
getImage(x?, y?, w?, h?)
and
getPixel(x, y) or getColor(x, y)or colorAt(x, y) or pixelAt(x, y)
Would seem to be both way more descriptive and less ambiguous. I understand this current design comes from Processing but it is far harder to work with when we don't have compile-time type checking to help users.