I have two values (between 0 and 255), from audio sources.
I'm trying to display two different RGB colours, a rectangle split by the middle, the colors from these two changing numbers, the colors changing as the numbers.
thank for you help, I know it's simple, but i'm really stuck.
Have a nice day.
To show a “split rectangle,” I would suggest using two panel objects side by side.
You can control the panel object’s colour using the bgcolor (or bgfillcolor) message followed by a list of four numbers, e.g.: bgcolor 1 0 0 0.5
The numbers correspond to Red, Green, Blue, and Alpha (opacity) and are all in the range of 0–1. So bgcolor 1 0 0 0.5 would set the colour of the panel to 100% red and 50% transparent.
In your case, you have values 0–255 so you need to scale those down to 0–1 and then decide how exactly you want to map them. For example, if you wanted each panel to be white when the value is 255, black when it is 0, and some shade of grey in between, you could do something like this:
value → [scale 0 255 0. 1.] → (bgcolor $1 $1 $1 1) → [panel]
Some notes:
The last two arguments of scale must be floats, otherwise it will just output integers 0 and 1.
The $1 syntax of the message box gets replaced by input. You could decide for example to only control the green part of the colour: bgcolor 0 $1 0 1.
If your value changes very frequently, you might want to limit how often it updates the colour. Most screens won’t update faster than 60 times per second, so changing the colour every millisecond for example is a waste of resources. If you’re using snapshot~ to get the value from audio, you could use an argument of 17 or higher, to limit the values to less than 60 times per second (1000ms / 60 = 16.6…). Alternatively, you could use the speedlim object to limit how often you recalculate your colour.
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'm trying to put together a simple shader with Unity' Shader graph. The material should appear white, yellow and blue - and static. However in the sample gradient, it's only displaying yellow. If I change the time input to Sine, the gradients blends through the colours. What is going wrong.
Plug an "UV" node in the gradient sampler's "time" input instead of a "Time" node.
First thing to know is that a Gradient goes from 0 to 1.
The 0 is on the left (in white) and the 1 in on the right (in yellow).
I guess that the blue is between approx. 0.25 and 0.3.
On the other hand, you use the Time, which has a constantly evolving value far above 1. Therefore, it is always on the max, meaning plain yellow.
If you use SinTime, the value alternates with a sinusoid between 0 and 1, making the color go from left to right then from right to left.
Additional information: as of today (2019.1.12) it seems that there is a bug in Shader Graph when you use Gradient on a system where the decimal separator is ","
The generated shader is created with a "," instead of "." in functions, messing up the arguments.
AutoHotkey's PixelSearch allows one to search for a pixel of a certain color in an (X1,Y1)..(X2,Y2) rectangle.
But I want to find any pixel that isn't a certain color, i.e. given a background color, I want to detect when any other color comes up in the foreground.
Is there a way to do this using the built-in PixelSearch, or other built-in functions?
If you have some control over the background color, perhaps you can use PixelSearch's variation parameter.
If your background color is black, search for a white pixel with variation 254. PixelSearch should return any pixel that isn't black.
This code searches for any pixel other than BLACK (untested)
White := 0xFFFFFF
PixelSearch OutputVarX, OutputVarY, X1, Y1, X2, Y2, %White%, 254
If your background is midtone gray (0x7F7F7F), try searching for black and white with variation 127. Again, I haven't tested this. Maybe the variation should be 126 or 63. You might have to engage in some trial and error since the behavior of the variation parameter isn't comprehensively documented.
You can use PixelGetColor to look at an individual pixel. The instruction tells you the color of the pixel at location x, y. An If command determines whether the pixel is 0x9D6346 or not.
Using PixelGetColor in a Loop allows you to test a range of pixels, one at a time by incrementing x, y or both.
And yes the proper order is BGR not RGB. A look at the help file confirmed that. :)
Something is happening to change the color. Perhaps you can look for another way to detect the change on the screen. Is the change of color due to another window or message becoming active? If so there are a number of commands you can use to determine what is appearing on the screen.
The windows spy is good at determining the names of pop up messages. Even if they have the same name as an existing window you can determine which is which by the text included or excluded.
A change of the position of a particular window may be enough to detect the change you are looking for.
Perhaps a bit more detail describing what you are trying to detect will help. It would at least, confirm we are in the same ballpark.
I cannot think of a reliable way to solve this with only built-in functionality. However, you could write it yourself with help of the external GDI+-library.
backgroundColor = 0x644E37
pToken := GDIP_StartUp()
pBitMap := GDIP_BitmapFromScreen()
while(a_index <= a_screenWidth) {
w := a_index
while(a_index <= a_screenHeight) {
h := a_index
ARGB := GDIP_GetPixel(pbitmap, w, h)
RGB := ARGBtoRGB(ARGB)
if(RGB != backgroundColor) {
msgbox, % "found pixel at " w ", " h
}
}
GDIP_DisposeImage(pBitMap)
GDIP_Shutdown(pToken)
return
ARGBtoRGB( ARGB ) {
VarSetCapacity( RGB,6,0 )
DllCall( "msvcrt.dll\sprintf", Str,RGB, Str,"%06X", UInt,ARGB<<8 )
Return "0x" RGB
}
untested
Allegedly, this gdip_bitmapFromScreen() is actually faster than pixelSearch.
source
This pixel search worked for me to find any color other than white:
Search for black (0x000000),
if pixel not found
search for red (0xFF0000),
if pixel not found
search for lime (0x00FF00),
if pixel not found
search for blue (0x0000FF),
if pixel not found, the only color is pure white.
I Set all these to have a variation of 254. A variation of 255 finds everything, including white. I used lime instead of green because the official color called green has a green value of 128, while lime has a green value of 255 (red 0, green 255, blue 0). Seems that just searching for black usually finds NOT white, but sometimes you'll need to work your way down the list. This informs me whether or not there is ANY variation of ANY color other than white, including colors so close to white that I can't see them (when on a white background).
You might have to do a little math and/or experimentation for other colors, but I don't see why this method wouldn't work. I used fast RGB mode and window coordinates. Also I found helpful information here:
https://en.wikipedia.org/wiki/Web_colors
As a relative novice I hate to do this. :)
Right out of PixelSearch in the help file.
PixelSearch, Px, Py, 200, 200, 300, 300, 0x9d6346, 3, Fast
if ErrorLevel
MsgBox, That color was not found in the specified region.
else
MsgBox, A color within 3 shades of variation was found at X%Px% Y%Py%.
Understanding of hexadecimal and how the number applies to the color is necessary.
Color is expressed as a hexadecimal number. In this case 9d6346 and is broken down into three parts. I seem to recall 9d is the value for red, 63 for green, and 46 for blue. Those three numbers can range between Hex 00 to Hex FF (Decimal 0 to 255).
Variation is expressed as a Decimal number is the amount of allowable range in the search color
9D range being 9b to 9f. 63 = 61 to 66, 46 = 44 to 69. Depending on whether the search number is taken in or not my range could be out by 1.
If all else fails Google hexadecimal
Similar possibilities with PixelGetColor followed by a variety of If statements
Be prepared for a very wide variation. Some apps intermingle several distinctly different colors to achieve a desired color.
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/
I am working on replacing certain color in image by User's selected color. I am using OpenCV for color replacement.
Here in short I have described from where I took help and what I got.
How to change a particular color in an image?
I have followed the step or taken basic idea from answer of above link. In correct answer of that link that guy told you only need to change hue for colour replacement.
after that I run into the issue similar like
color replacement in image for iphone application (i.e. It's good code for color replacement for those who are completely beginners)
from that issue I got the idea that I also need to change "Saturation" also.
Now I am running into issues like
"When my source image is too light(i.e. with high brightness) and I am replacing colour with some dark colour then colours looks light in replaced image instead of dark due to that it seems like Replaced colour does not match with colour using that we done replacement"
This happens because I am not considering the brightness in replacement. Here I am stuck what is the formula or idea to change brightness?
Suppose I am replacing the brightness of image with brightness of destination colour then It would look like flat replacemnt and image will lose it's actual shadow or edges.
Edit:
When I am considering the brightness of source(i.e. the pixel to be processed) in replacment then I am facing one issue. let me explain as per scenario of my application.
for example I am changing the colour of car(like whiteAngl explain) after that I am erasing few portion of the newly coloured car. Again I am doing recolour on erased portion but now what happended is colour done after erase and colour before erase doesn't match because both time I am getting different lightness because both time my pixel of to be processed is changed and due to that lightness of colour changed in output. How to overcome this issue
Any help will be appreciated
Without seeing the code you have tried, it's not easy to guess what you have done wrong. To show you with a concrete example how this is done let's change the ugly blue color of this car:
This short python script shows how we can change the color using the HSV color space:
import cv2
orig = cv2.imread("original.jpg")
hsv = cv2.cvtColor(orig, cv2.COLOR_BGR2HSV)
hsv[:,:,0] += 100
bgr = cv2.cvtColor(hsv, cv2.COLOR_HSV2BGR)
cv2.imwrite('changed.jpg', bgr)
and you get:
On wikipedia you see the hue is between 0 to 360 degrees but for the values in OpenCV see the documentation. You see I added 100 to hue of every pixel in the image. I guess you want to change the color of a portion of your image, but probably you get the idea from the above script.
Here is how to get the requested dark red car. First we get the red one:
The dark red one that I tried to keep the metallic feeling in it:
As I said, the equation you use to shift the light of the color depends on the material you want to have for the object. Here I came up with a quick and dirty equation to keep the metallic material of the car. This script produces the above dark red car image from the first light blue car image:
import cv2
orig = cv2.imread("original.jpg")
hls = cv2.cvtColor(orig, cv2.COLOR_BGR2HLS)
hls[:,:,0] += 80 # change color from blue to red, hue
for i in range(1,50): # 50 times reduce lightness
# select indices where lightness is greater than 0 (black) and less than very bright
# 220-i*2 is there to reduce lightness of bright pixel fewer number of times (than 50 times),
# so in the first iteration we don't reduce lightness of pixels which have lightness >= 200, in the second iteration we don't touch pixels with lightness >= 198 and so on
ind = (hls[:,:,1] > 0) & (hls[:,:,1] < (220-i*2))
# from the lightness of the selected pixels we subtract 1, using trick true=1 false=0
# so the selected pixels get darker
hls[:,:,1] -= ind
bgr = cv2.cvtColor(hls, cv2.COLOR_HLS2BGR)
cv2.imwrite('changed.jpg', bgr)
You are right : changing only the hue will not change the brightness at all (or very weakly due to some perceptual effects), and what you want is to change the brightness as well. And as you mentioned, setting the brightness to the target brightness will loose all pixel values (you will only see changes in saturation). So what's next ?
What you can do is to change the pixel's hue plus try to match the average lightness. To do that, just compute the average brightness B of all your pixels to be processed, and then multiply all your brightness values by Bt/B where Bt is the brightness of your target color.
Doing that will both match the hue (due to the first step) and the brightness due to the second step, while preserving the edges (because you only modified the average brightness).
This is a special case of histogram matching, where here, your target histogram has a single value (the target color) so only the mean can be matched in a reasonable way.
And if you're looking for a "credible source" as stated in your bounty request, I am a postdoc at Harvard and will be presenting a paper on color histogram matching at Siggraph this year ;) .