search

imgflo / imgflo-server

HTTP image processing server based on imgflo
48 stars 7 forks source link

Width and height could be optional for noflo-canvas graphs #9

Closed automata closed 9 years ago

automata commented 9 years ago

Graphs like insta_1977 just overwrite width and height, should we keep the way it is?

jonnor commented 9 years ago

@automata What do you mean? Is height/width for insta_1977 different from the input image? If so, why?

jonnor commented 9 years ago

@automata I see a problem now. A custom property is used for the URL. This is broken, because API consumers will expect "input" to be the property where the input image is, not "url". imgflo-server should set up the graph such that this input image is already blitted into "canvas" when it is received. Opening the image etc inside the graph and blitting to another canvas should not be neccesary. Also, what the hell is the wait a bit component doing in there? It smell like a race condition....

automata commented 9 years ago

@jonnor so in other words, I should suppose canvas will have the image to process, right? So we wouldn't need url anymore?

About the "wait a bit" component (i.e. core/RepeatDelayed), it ensures we will have a canvas to draw (with the proper dimension) before drawing the image per se. Without the delay it will draw on a canvas with default dimensions (received from imgflo-server). We can change noflo-canvas to change it's current canvas dimension if drawImage command has a bigger image than the current canvas, but I don't know if it is always desired.

jonnor commented 9 years ago

@automata canvas should have the image to process, however it currently does not. It needs to be implemented by someone ;) And until that we can't really use these graphs...

re "wait a bit": when does the canvas instance appear? If it is on next iteration of main loop, it should be a core/RepeatAsync (as the timeout does not matter). If it is at "some other time", a timeout is still not the right solution. It will be racy, because there is no guarantee that the event will happen within the timeout.

imgflo graphs should not change the size of images during processing unless explicitly told to.

jonnor commented 9 years ago

@automata See the "insta" graph I pushed, that is how it should work. Server should set up all the other (common) parts of the graph.

jonnor commented 9 years ago

@automata Implemented support for providing the input data to canvas port now. See commit https://github.com/jonnor/imgflo-server/commit/5a46cc471972fa5e1f746b33c2ff944b89bd397a

jonnor commented 9 years ago

Closing this one in favor of https://github.com/jonnor/imgflo-server/issues/10, height+width must be respected, but currently is not