I already searched the web and stack overflow for answers to this (seemingly simple) question, however could't find the answer:
I am in the progress of writing a cellular automaton in MATLAB. I am using an n*m matrix with values between 0 and 15, from which I make an image using a colormap with 5 grey values (between 0 and 1). See the following code snippet to clarify this:
WIDTH = 100;
HEIGHT = 100;
fields = randi(16,HEIGHT,WIDTH)-1;
% here the grey values 0, 0.25, 0.5, 0.75 and 1 are mapped to the values 1 to 16
cmRow = [1;0.75;0.75;0.5;0.75;0.5;0.5;0.25;0.75;0.5;0.5;0.25;0.5;0.25;0.25;0];
specialGray = [cmRow, cmRow, cmRow];
colormap(specialGray);
image(fields)
Well my problem is, that there is no 0th row in the colormap that MATLAB would use, if a value 0 occurs. As a result, there is always one color missing.
Just using values from 1 to 16 instead of from 0 to 15 is unfortunately not an option, as I heavily rely on these values later in the script.
Is there something obvious, I am missing? Do you have any ideas how to tackle this issue?
Thank you very much!
Best regards,
René
The image function knows two type of color mapping: direct' (the default) and 'scaled'. If you use 'scaled', you can set the scale for the color with thecaxis` function. Thus, the following code should do the trick (but you can of course also transform the values as suggested by Oleg):
image(fields,'CDataMapping','scaled');
colormap(specialGray);
caxis([0 15]);
Related
I've been having some very strange lighting behaviour in Unreal 4. In short, here's what I mean:
Fig 1, First, without any normal mapping on the bricks.
Fig 2, Now with a normal map applied, generated based on the same black-and-white brick texture.
Fig 3, The base pixel normals of the objects in question.
Fig 4, The generated normals which get applied.
Fig 5, The material node setup which produces the issue, as shown in Fig 2
As you can see, the issue occurs when using the generated HeightToNormalSmooth node. As shown, this is not an issue relating to object normals (see Fig 3) or to a badly exported normal map (as there isn't one in the traditional sense), nor is it an issue with the HeightToNormalSmooth node itself (Fig 4 shows that it generates the correct bump normals).
To be clear, the issue here is the fact that using a normal texture at all (this issue occurs across all my materials) causes the positive Y facing faces of an object to turn completely black (or it seems, to become purely reflections-based, as increasing roughness on the material causes the black faces to become less 'shiny' looking).
This is really strange, I've tested with multiple different skylight setups, sun directions, and yet this always happens (even when lit directly), but only on +Y aligned faces.
If anyone can offer insight that would be greatly appreciated.
You're subtracting what looks like 1 from the input that then goes into multiply by 1, if I'm correct. This will, in most cases, make any image return black. This is because in UE4 and many other programs, colors in an image are determined by decimals of Red Green and Blue. These decimals fall in a range of 0 to 1. This means if I wanted to make red, I could use these values- R = 1 G = 0 B = 0. This matters because if R = 0 G = 0 B = 0, the result is black. When you use a multiply node in your example, what you are doing is having UE4 take each pixel of the image you fed into the node (if it was white, R = 1 G = 1 B = 1) and multiply its R, G, and B values by that number. Since zero multiplied by a number equals zero, all the pixels in the image are being set to have values of R = 0, G = 0, and B = 0. thus, all zeros, and you get black.
I also noticed you then multiplied it by one, which in most cases won't do a whole lot, since you're just multiplying the input by 1. If your input is 0, (black), multiplying it by one won't change it, cause 0 * 1 still equals 0.
To fix your issue, try changing the value you subtract from your input to be something smaller than one, say a decimal, such as 0.6 or 0.5
So I've discovered why this was an issue. Turns out there's a little option in the material settings called 'Tangent Space Normal'. This is on by default ('for convenience'), disabling this appears to completely fix the issue with the generated normal maps produced by HeightToNormalSmooth.
I have two different experiments (one is a “change blindness task” and the other one is an “optokinetic stimulation of dots”) both written in psychtoolbox.
I want to combine these two task while running (i.e., to superimpose change blindness task on the OKS paradigm). I would be so thankful if you can let me know about possible ways to combine these two experiment? Or any sources that can be of help to learn how can I approach this.
Best regards,
Parishad
This is hard to answer without any code provided by you. You should probably look at the examples here: http://peterscarfe.com/ptbtutorials.html
I'm still going to try to answer, but again, without code from you, this might or might not be helpful.
In psychtoolbox you draw stimuli first off screen and then you 'Flip' what has been drawn off screen to be displayed on the monitor. First you set up the display window like this:
screenNumber = max(Screen('Screens'));
[w, wRect] = PsychImaging('OpenWindow', screenNumber, [0 0 0]);
Now you have a fully black monitor. If you want to show something else (here a red dot with a size of 20 pixels at the center of the screen), you have to draw it on the upcoming frame and then 'Flip', like this:
[screenXpixels, screenYpixels] = Screen('WindowSize', w);
Screen('DrawDots', w, [screenXpixels/2, screenYpixels/2], 20, [1 0 0], [], 2);
Screen('Flip', w)
Your experiments probably have loops that draw the stimuli and flip to them at the appropriate times within each trial. You will have to figure out what things from which loop to put into a combined loop, so they are drawn at the same time and then flipped together. Good luck.
It may be a good way to define two separate screens and handle both tasks simultaneously:
[windowPtrBig, rectBig] = Screen('OpenWindow', max(Screen('screens')), [256 256 256]);
[windowPtrSmall, rectSmall] = Screen('OpenWindow', max(Screen('screens')), [256 256 256 ], [0 100 1000 1000]);
To get closer to the appropriate answer, the code is needed.
I have used the following code to obtain a border of the image and also remove the shadow under the image.The image is a grayscale image.
The code is:
x = imread('image.jpg');
sobel_h = [-1 0 1;-2 0 2;-1 0 1];
sobel_v = [-1 0 1;-2 0 2;-1 0 1]';
x_sobel_h = conv2(x,sobel_h,'same');
x_sobel_v = conv2(x,sobel_v,'same');
x_sobel_c = sqrt((x_sobel_h).^2+(x_sobel_v).^2);
x_sobel_c=uint8(x_sobel_c);
figure,imshow(x_sobel_c);
z=x_sobel_c;
z(z~=0 & z<=150)=0;
z(z>0)=255;
figure,imshow(z);
I found this code on Matlab File Exchange.It is simple and works well with some images but the shadow remains in some images.
The shadow can be removed if I change z<=150 to a higher value.But depending on the image, this value needs to be changed.Does anyone know some other thresholding method to remove the shadow in different images? If anyone can point me to any kind of reference material, I would be grateful.Thank you
As mentioned in the comments, there will be no magic bullet for removing the shadows.
The closest you will probably be able to come is to use a dynamic method to determine the optimal threshold for each image. For example, Otsu's method is implemented in MATLAB, through the commands graythresh and multithresh (the former defines one threshold to divide the image into 2 classes, the latter allows you to specify the number of thresholds).
My question is related to the following AutoHotkey function (you may find it here):
ImageSearch, OutputVarX, OutputVarY, X1, Y1, X2, Y2, ImageFile
According to its purpose, this function searches a region of the screen for an image.
As of the ImageFile input, an optional parameter is allowed:
*n (variation): Specify for n a number between 0 and 255 (inclusive) to indicate the allowed number of shades of variation in either direction for the intensity of the red, green, and blue components of each pixel's color. For example, *2 would allow two shades of variation. This parameter is helpful if the coloring of the image varies slightly or if ImageFile uses a format such as GIF or JPG that does not accurately represent an image on the screen. If you specify 255 shades of variation, all colors will match. The default is 0 shades.
So far, I've always been forced to "calibrate" that parameter making several trials until the chosen image was found: a too high value would return ErrorLevel = 0 all the time, while a too low one would always return ErrorLevel = 1, and of course both of them are not what you would expect from your script.
My question is: what's the most accurate and efficient way to find the "correct" value of *n, that is, the smallest value of *n that makes ImageSearch to not fail during the search with very high confidence (99% or greater)?
Let a possible attempt to find the following images on screen:
Consider the following case: these are not images that appear or disappear: they simply amend their brightness (what attached above is the "dark" version); this means that a too high *n value would of course make the script to always find them, even if their brightness is high.
According to my trials, a value of *n spanning from 100 to 125 is quite good, but I cannot be sure about that if I don't know a way to accurately calibrate that value.
I've tried to make something such as this script
i = 1
Loop
{
ImageSearch, OutputVarX, OutputVarY, 177, 645, 1150, 686, *%i% C:\...\MyImage.png
i := i + 1
;MsgBox, %i%
if (ErrorLevel = 0)
{
MsgBox, %i%
break
}
}
Return
but this does not seem to work.
I made a function that does this about 2 years ago
I called it VariemClick
I made it to find multiple done buildings in a flash game.
Why? Because in the beginning, the image variation I used, found the image in the flash game, but it only worked one time or a few times and then the next time nothing, so I tried to just set up the used variation, only to have it not find the first image, so I needed some way to first, use a low variation and then a little more and so on, but if it got two high, it just found anything, so in with a max variation.
Now the function will start low and then keep setting the allowed variation up and down within the set min/max value given until a set number of tries and then give you a list with info about the images found and the used variation.
Find it here: http://www.autohotkey.com/board/topic/79607-variemclick-findnclick-images-multiple-times-in-flash-games/
During MATLAB-sessions,get(0,'screensize') first gives the correct resolution. Later on, the answer will become [0 0 1 1] though. This behaviour will only stop when I restart matlab, it is then the correct value again.
This error always happens when I run a specific part of our programme. It appears to happen after this specific line of code:
set(0,'PointerLocation',[.4*GUI.scrsz(3),.5*GUI.scrsz(4)],'units','normalized');
Even though I managed to isolate the error I can´t to figure out the reason for this behaviour. I am using MATLAB R2010b on Windows 7 64bit.
Please note that I´m not an advanced user of MATLAB, so please forgive me if i overlooked something obvious.Thanks in advance for your help.
The reason is that you set 'units' to 'normalized'. And your screen starts naturally in a corner -> [0 0 ... and fills the whole screen -> ... 1 1] (The first pair defines the position and the second pair height and width)
So the values are correct, just not showing the pixels anymore.
Just set it back to set(0,'units','pixels') after you finished the task before, which needed the normalized units. Or store your screensize at the beginning of your script in a variable to use it later on.
With get(0,...) you are getting default properties and with set(0,...) you change them, thats why it's normal again after restart, because Matlab is setting all values to default with every start, which is in your case 'units','pixels'.