"post" in dltk.queueTrial specs?

[yamins81]

Ha, there is a "pre" option in the dltk.queueTrial spec, which allows you to do stuff before the image drawing. Would you be OK with my adding a "post" operation as well? A reason to do this is if I want to draw stuff using canvas on top of the image (e.g. during training phase). Of course, I can also define a second canvas element that is superimposed on the image, but with a higher z-index, and which is setup in the "pre" operation, but the "post" might be nicer conceptually. What do you think?

[hahong]

How would you implement post? Could you elaborate more? When i designed the function I thought pre combined with callback would be enough. Remember that pre is called only at the transition between components. -H

Sent from my iPhone

On Saturday, August 30, 2014, Dan Yamins notifications@github.com wrote:

Ha, there is a "pre" option in the dltk.queueTrial spec, which allows you to do stuff before the image drawing. Would you be OK with my adding a "post" operation as well? A reason to do this is if I want to draw stuff using canvas on top of the image (e.g. during training phase). What do you think?

— Reply to this email directly or view it on GitHub https://github.com/dicarlolab/mturkutils/issues/11.

[yamins81]

Well, I would call post right after the render step in queueTrial. Suppose I wanted to draw something in the canvas of the test image, on top of the image? Without a post operation, that either has to come after the image is loaded (e.g. copy contexts) is called, or I have to use a second canvas element sitting on top of the one with the image draw onto it.

[hahong]

Oh I see. I think that's a good use case. Please go for it, and let me know if you finished implementing that. -H

Sent from my iPhone

On Sat, Aug 30, 2014 at 5:32 PM, Dan Yamins notifications@github.com wrote:

Well, I would call post right after the render step in queueTrial. Suppose I wanted to draw something in the canvas of the test image, on top of the image? Without a post operation, that either has to come after the image is loaded (e.g. copy contexts) is called, or I have to use a second canvas element sitting on top of the one with the image draw onto it.

— Reply to this email directly or view it on GitHub https://github.com/dicarlolab/mturkutils/issues/11#issuecomment-53971125 .

[yamins81]

I suppose here would be another way to do it, with 4 steps in the queue trial spec:

1. do ISI1
2. load the images via a step in the trial specs, but with a duration of 0
3. in the next step, do the intervention on top of the images via the 'pre' operation, but with no image drawing, but the required duration (e.g. 100 ms)
4. then do ISI2

I think this might work, because there's no "clearing" of the onscreen context, right? The images in the the onscreen context will persist during step 3.

But probably having "post" is cleaner, right?

[hahong]

Yes, post is cleaner. Even if you specify a duration of 0, one frame will be spent in the procedure in the current framework, probably causing a flickering. I think post is a better approach to it. -H

Sent from my iPhone

On Sat, Aug 30, 2014 at 5:47 PM, Dan Yamins notifications@github.com wrote:

I suppose here would be another way to do it, with 4 steps in the queue trial spec:

1. do ISI1
2. load the images via a step in the trial specs, but with a duration of 0
3. in the next step, do the intervention on top of the images via the 'pre' operation, but with no image drawing, but the required duration
4. then do ISI2

I think this might work, because there's no "clearing" of the onscreen context, right? The images in the the onscreen context will persist during step 3.

But probably having "post" is cleaner, right?

— Reply to this email directly or view it on GitHub https://github.com/dicarlolab/mturkutils/issues/11#issuecomment-53971482 .

[hahong]

Seems resolved.