Hi Chris,
Is there a reason why you removed those?
We have expanded the functionality of the sinusoidal grating plugin relying on those libraries, and now that they are gone, we cannot compile the plugin with new versions of mworks.
Best
Najib
Hi Najib,
Until recently, MWorks’ stimulus drawing code used the (rather ancient) OpenGL 2.1 API. As part of porting MWorks to iOS, I updated it to use the (somewhat less ancient) OpenGL 3.3 API, which is largely compatible with the OpenGL ES 3.0 API available on iOS.
The source files in question were written against OpenGL 2.1 and wouldn’t work with the updated stimulus code. Since they were used exactly nowhere in MWorks’ core or standard plugins, I simply discarded them.
Updating your stimulus plugin to function with the current MWorks nightly build (and upcoming 0.8 release) is going to take some work. Apple has an overview document describing the changes required to move from OpenGL 2.1 to 3.3. However, if your grating plugin derives from MWorks’ stock grating, then the best starting point in probably the latest drifting grating source code.
Of course, I’m happy to provide whatever help you need to make this transition. Alternatively, if you’re interested in sharing your expanded functionality with the broader MWorks community, then we can discuss integrating your changes in to the standard grating.
Cheers,
Chris
Dear Chris,
I had hoped that it would be easy to port some of our expanded
functionality to the latest version of mworks, but I am worried that we
might have hit a wall and would appreciate any help you can provide.
The two main things we would like to achieve:
1-Give mworks the ability to set/change gamma.
2-Expand the drifting grating plugin to allow for multiple gratings that
can be added and multiplied.
I am more than happy to share our old code, but I worry that it is probably
not as documented as you would like. Is there a chance we can chat via
skype to make a plan.
I know that you have been in the process of releasing a new version of
mworks, but maybe we can at least make a plan.
Best
Najib
Hi Najib,
Probably the best approach would be for me to take a look at your old code first, as that will give me a clear idea of what needs to be done. Can you point me to it?
Thanks,
Chris
Dear Chris,
Enclosed please fine an archive that includes the changes we care about:
1-The changes that allowed us to do gamma correction are mostly in the
server and the stimulus display, I believe Romesh did his best to comment
on the code.
2-Our drifting grating plugin builds from the old plugin, it allow for
multiple gratings that can be added or multiplied and different windowing
options.
Take a look and let me know how you would like to proceed. The sooner we
can implement the easier it is for me to push the lab to adopt the new
mworks.
Best
Najib
Dear Najib and Chris,
Chris, I think I got Romesh’s modifications to your code to include the monitor gamma correction to work on version 7 of MWorks. I’ve attached the code for that, hopefully you can see where the changes were made, and incorporate them as appropriate.
Thank you so much for working on the other aspects of MWorks (drifting gratings and words out on the firmata protocol).
Best,
mariana
Hi Najib & Mariana,
Thanks for sending the code. I’ll try to take a look at it and get back to you early next week.
Cheers,
Chris
Thank you Chris, much appreciated.
Best
Najib
Hi Najib & Mariana,
I had a look at the code you sent.
The changes to support gamma control appear very straightforward, and I think we should make them (or equivalent) a standard MWorks feature. However, this won’t happen until after the impending 0.8 release. Is that OK with you?
The drifting grating changes are a bit more involved, although it still doesn’t seem like a huge job. I think it will take a couple days of my time to update the plugin, but, again, this probably won’t happen until after the 0.8 release. Are you interested in contributing these changes to MWorks, so that others in the community can use them, too? To be clear, this does not affect my willingness to work on the plugin in any way. Also, I’m not 100% sure at this point if it would even make sense to try to integrate your changes into the standard grating stimulus. I’m just wondering if you’re open to that possibility.
Cheers,
Chris
Dear Chris,
Absolutely 
Completely okay with us, the reason why we didn’t want to
share them is because I wasn’t sure that we could support them…
When do you anticipate the 0.8 release?
Best
Najib
Hi Najib,
Absolutely
share them is because I wasn’t sure that we could support them…
Great, thanks! One benefit of sharing your code is that maintaining it becomes my job
When do you anticipate the 0.8 release?
I hope to have it out sometime in the next few weeks.
Chris
Awesome.
Next few weeks is completely workable for us.
Once I have chat with Romesh, there are other plugins that are not so high
priority that I might ask your advice on.
Best
Najib
Hi Najib & Mariana,
The MWorks nightly build now includes support for setting the display gamma.
Note that I used different keys than you did in #mainScreenInfo: set_display_gamma controls whether the gamma is set or not; and red_gamma, green_gamma, and blue_gamma specify the (inverse) gamma value for each channel. You can change these settings in MWServer’s preferences window (Display → Advanced…).
Also, the gamma settings apply only when color management is disabled (which can also be done in Display → Advanced…). If your goal is linear color response (e.g. for gratings), then profiling your display and enabling color management in MWorks is a better solution than changing the display gamma. But in any case, doing both at the same time makes no sense, so MWorks doesn’t allow it.
When you have a chance, please test these changes and let me know if they meet your needs.
Thanks,
Chris
Hi Najib,
I’m trying to understand the definition of the “flattop” mask types in your drifting grating code (and which you also mentioned in another discussion). Searching the web for “flattop distribution” or “flat-top Gaussian” doesn’t yield much info. This and this are about all I could find, and neither really matches the equation in the code.
In said code, the value of the non-flat portion of the mask is the same as that of an un-normalized Gaussian mask with mean 1-2/N and standard deviation 2/(3*N), where N is 8 or 4 (for flattop/flattop8 and flattop4, respectively). The flat portion begins where the distance from the center equals the Gaussian mean.
My question: Why do you use those particular values for the mean and standard deviation? Is there some reference you can point me to that explains the reasoning behind them?
Thanks,
Chris
Hi Christopher,
Great to hear from you.
Flatop masks or raised cosine masks are lab jargon that you probably won’t
find references for online.
Similar to a guassian mask, the idea is to taper the age of the window.
Hard edges typically introduces very high frequency components that are
quite visible and the taper is meant to get rid of that.
If you us an actual gaussian to, the top of the guassian is rounded and not
flat, in other words the luminance starts dropping as soon as you leave the
center of the images.
The flattop mask is meant as work around from that, the middle of the image
will always have the same luminance and taper only starts at some point.
The steepness of the taper is then determined by the standard deviation of
a gaussian and one half of the gaussian is used to taper the edge.
Hope this is clear, if you can think of a cleaner way of achieving that, I
would love to discuss it.
On a different note, I have been meaning to contact you regarding data
analysis.
The matlab getEvents funcition is rather slow when trying to import large
files and signals like eye position that are updated often.
Is there a faster way to get around that problem?
Best
Najib
Hi Najib,
The flattop mask is meant as work around from that, the middle of the image
will always have the same luminance and taper only starts at some point.
The steepness of the taper is then determined by the standard deviation of
a gaussian and one half of the gaussian is used to taper the edge.
Yes, that’s all fine. The question is, why are the mean (i.e. the radius of the untapered central region) and the standard deviation defined by the particular expressions I mentioned? Do you just like the look of the taper they produce?
if you can think of a cleaner way of achieving that, I would love to discuss it.
I can think of a simpler and more general way of achieving it: Instead of having separate “flattop” mask types, just add another parameter for the Gaussian mask that controls what happens in the center when the mean is non-zero. That is, does it decay back toward zero, producing a ring-like mask, or does it stay at 1, producing a flat center with Gaussian outer edge (left vs. right in the attached image)?
This is what I’ll do, unless there’s a particular reason to constrain the mean and standard deviation the way your plugin does.
Thanks,
Chris
Attachment: gaussian_vs_flattop.jpeg (19.8 KB)
Hi Chris,
I am a bit confused about the image that you sent, in particular, I am not
sure why we would need the donut (left image).
I am attaching a figure that shows a cross section of the tapers that we
are trying to achieve.
The idea is that you specify the size of the mask in this case 256 pixels.
If the mask is a sharp circle, then this cross section profile would like a
rectangle. Full transparency from -128:128 and opaque elsewhere.
In the flattop8 condition the taper is on each side is 32 pixels wide 1/8
of 256 hence the flattop8 designation
In the flattop4 condition the taper is 64 pixels on each side 1/4 of 256
producing a flattop4 mask.
There are multiple ways to achieve this with minor differences. The key is
that the taper can’t be a straight line because you produce artifacts so it
has to look like a gaussian or a sinewave.
Best
Najib
Attachment: flatop4_flattop8.pdf (4.69 KB)
Hi Najib,
I am a bit confused about the image that you sent, in particular, I am not sure why we would need the donut (left image).
Sorry, I should have provided more context. I don’t imagine you (or anyone) would need the donut. I was just illustrating what the drifting grating’s mean parameter does, namely, turn the Gaussian peak into a circle, instead of a point. (Why it works this way is not at all clear.) If you modify the Gaussian mask so that the alpha is uniformly one inside the circle (thereby filling the donut hole), you get a mask that’s uniform in the center and Gaussian at the edge, which is exactly what your “flattop” masks are.
In the flattop8 condition the taper is on each side is 32 pixels wide 1/8
of 256 hence the flattop8 designation
In the flattop4 condition the taper is 64 pixels on each side 1/4 of 256 producing a flattop4 mask.
And to get these edge widths using MWorks’ grating, you would set mean to 0.75 and 0.5, respectively:
mean = 1 - 2/N
1 - 2/8 = 0.75
1 - 2/4 = 0.5
There are multiple ways to achieve this with minor differences. The key is that the taper can’t be a straight line because you produce artifacts so it has to look like a gaussian or a sinewave.
OK, got it. I’ll figure out the best way to integrate support for this in to MWorks.
Thanks,
Chris