Allow easier access to neighboring pixels in Dynamic module

[jywarren]

Currently the Dynamic module runs on each pixel, one by one:

image-sequencer/src/modules/Dynamic/Module.js

Lines 37 to 45 in efd5bf7

	function changePixel(r, g, b, a) {
	var combined = (r + g + b) / 3.000;
	return [
	options.red_function( r, g, b, a),
	options.green_function(r, g, b, a),
	options.blue_function( r, g, b, a),
	options.alpha_function(r, g, b, a),
	];
	}

It has read access to the existing pixel, and uses that data to generate a new pixel color.

But to do some activities, it's helpful to be able to access neighboring pixels. This can become computationally intensive, but also useful for some operations. We could make a neighbor(x,y) pixel available to specify pixels x, y away from the current pixel.

[jywarren]

GitMate.io thinks the contributor most likely able to help you is @ccpandhare.

Possibly related issues are #108 (Math Module), #146 (Monochrome "fallback" on Dynamic module not working), #112 (Scale module), #5 (image cropping module), and #75 (Pixel Manipulation and GIFs).

[tech4GT]

@jywarren should we make a function to do this in the dynamic module?

function neighbour(x,y){
/*Some Definition*/
}

[jywarren]

Yes, i think that makes sense! :-)

…

On Tue, Mar 13, 2018 at 2:51 PM, Varun Gupta ***@***.***> wrote: @jywarren <https://github.com/jywarren> should we make a function to do this in the dynamic module? function neighbour(x,y){ /*Some Definition*/ } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#201 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ_CDQrCOl4MkBD4czQyhDojE03o8ks5teBUjgaJpZM4Sm5iL> .

[ccpandhare]

I think the neighbour function isn't really solving the underlying problem... What if I need probably the second neighbour? Maybe we could have a more generic function which makes code more readable So instead of [Ndarray(i*w + j*4 + 0), Ndarray(i*w + j*4 + 1), Ndarray(i*w + j*4 + 2), Ndarray(i*w + j*4 + 3)] Maybe we can just do newFunction(i,j) which will return the same array above? Just my thoughts though! Or maybe this could even support range based slice queries for a set of pixels or something?

…

On Wed, Mar 14, 2018, 03:46 Jeffrey Warren ***@***.***> wrote: Yes, i think that makes sense! :-) On Tue, Mar 13, 2018 at 2:51 PM, Varun Gupta ***@***.***> wrote: > @jywarren <https://github.com/jywarren> should we make a function to do > this in the dynamic module? > > function neighbour(x,y){ > /*Some Definition*/ > } > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > < #201 (comment) >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AABfJ_CDQrCOl4MkBD4czQyhDojE03o8ks5teBUjgaJpZM4Sm5iL > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#201 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AT0xnF6yykSeZrUl8zSJ7gfvhOxLPxjWks5teEVRgaJpZM4Sm5iL> .

[tech4GT]

@ccpandhare actually the neighbor function is supposed to be generic only, it will yield the pixel at x,y distance from the current pixel, as @jywarren was saying, will it be fine then?

[ccpandhare]

Yeah!

…

On Wed, Mar 14, 2018, 13:33 Varun Gupta ***@***.***> wrote: @ccpandhare <https://github.com/ccpandhare> actually the neighbor function is supposed to be generic only, it will yield the pixel at x,y distance from the current pixel, as @jywarren <https://github.com/jywarren> was saying, will it be fine then? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#201 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AT0xnJntY9BWtCVYPJBD2xk71gFz-jEkks5teM65gaJpZM4Sm5iL> .

[tech4GT]

@jywarren i have made this work but i have a doubt, should we put the logic to get neighboring pixels in PixelManipulation itself and pass it to changePixel so that other modules can also use it if need be?
What i mean is that changePixel can be defined like this

function changePixel(r,g,b,a,neighbour){
/*some code*/
neighbour(x,y) gives the neighbouring pixel
/*some other code*/
}

since neighbour is last parameter, its not required hence other modules which do not use neighbors would need no change

function changePixel(r,g,b,a){
/*function definition*/
}

or we can define the logic in dynamic module and pass it to PixelManipulation which will in turn pass it to module's changePixel ?

[jywarren]

I think it's possible we could expose access to neighbor() without passing it as a parameter, if we pass it using a closure -- my brain bends a bit thinking about it, but can't we allow changePixel() access? Ugh, it's been too long since I did this...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures

Otherwise, i like your passing neighbor() as the 5th parameter. Thanks for thinking this through!!!

[tech4GT]

@jywarren actually the thing is that the pixels object is not available in the module.js so even if we define the logic there there is no way that we get access to pixels there so we have to pass it to pixelmanipulation, only way this can work is if we bind the neighbour function to an object inside module.js and access that object directly in changepixel, would that be fine

Var obj={}
Obj.fun=getneighbor(){}
Changepixel uses obj.fun

[tech4GT]

This obj is passed to pixelmanipulation

[tech4GT]

#204 @jywarren done without extra parameter🎉

[tech4GT]

closed in #207