Im using PIXI.js for create snow animation, but cant understand how to change speed of particular, or all animation speed?
codepen.io/venegrad/pen/RwLQmWR
I need to reduce speed on 3 or 4
This answer is based on the codepen.io link that you provided.
The code uses the first 2 variables for the speed of the snow animation:
const UPPER_LIMIT_Y = 1
const UPPER_LIMIT_X = 1
The UPPER_LIMIT_Y affects the vertical movement while the UPPER_LIMIT_X affects the sideways movement of the snow drops. If you want to change how fast the snow falls, you can reduce the UPPER_LIMIT_Y and UPPER_LIMIT_X into values between 0 and 1 (ex: 0.5). I suggest you temporarily change the variable COLOR at line 7 to 0x000000 to make the snowdrops more visible while testing the speed changes.
Related
I am looking for a real time image processing to measure the velocity and output it to another control system.
I have attached an image of a yellow stripe. This has markings on the surface that I would like to automatically detect and use for calculation. In the first step the material moves only in one direction. Here for example to the right. For me only the horizontal part of the movement is of interest, so quasi only the velocity along an x-axis. But the material moves relatively fast. At maximum speed in 28 ms the current mark (spike) is at the position of the one in front of it.
The idea is to use a Raspberry Pi 4 with a camera at the maximum of 120 fps. So every 8.3 ms a picture is generated and should make it possible to clearly detect the movement of the marks.
My questions are:
Is it possible to process the images and detaction that fast to get the velocity in nearly real time? And which algorithem should I use for this configuration? Because it would be best if I could use two or three markers per image and average the velocity of them.
And I would like to use the velocity as an input signal for another system. What is the easiest and fastest way to send the information directly to another control system?
Problem
I'm trying to use opencv2 to detect PlayStation Move Motion Controllers in still images. In an attempt to increase the contrast between the orbs and the backgrounds, I decided to modify the input image to automatically scale the brightness level between the image's mean level and 96 above for each channel, then when converting to grayscale, taking the maximum value instead of the default transform, since some orbs are saturated but not "bright".
However, my best attempts at adjusting the parameters seems to not work well, detecting circles that aren't there over the obvious ones.
What can I do to improve the accuracy of the detection? What other improvements or algorithms do you think I could use?
Samples
In order of best to worst:
2 Wands, 1 Wand detected (showing all 2 detected circles)
2 Wands, 1 Wand detected with many nonexistent circles (showing top 4 circles)
1 Wand (against a dark background), 6 total circles, the lowest-ranked of which is the correct one (showing all 6 circles)
1 Wand (against a dark background), 44 total circles detected, none of which are that Wand (showing all 44 circles)
I am using this function call:
cv2.HoughCircles(img_gray,cv2.HOUGH_GRADIENT,
dp=1, minDist=24, param1=90, param2=25,
minRadius=2, maxRadius=48)
All images are resized and cropped to 640x480 (the resolution of the PS3 Eye). No blur is performed.
I think hough circles is the wrong approach for you, as you are not really looking for circles. You are looking for circular areas with strong intensity. Use e.g. blob detection instead, I linked a guide:
https://www.learnopencv.com/blob-detection-using-opencv-python-c/
In the blob detection, you need to set the parameters to get a proper high-intensity circular area.
as the other user said, hough circles arent the best approach here because hough circles look for perfect circles only. whereas your target is "circular" but not a circle (due to motion blur, light bleed/reflection, noise etc)
I suggest converting the image to HSV then filtering by hue/color and intensities to get a binary threshold instead of using grayscale directly (that will help remove background & noise and limit the search area)
then using findContours() (faster than blob detection), check for contours of high circularity and expected size/area range and maybe even solidity.
area = cv2.contourArea(contour)
perimeter = cv2.arcLength(contour,True)
circularity = 4*np.pi*area / (perimeter**2)
solidity = area/cv2.contourArea(cv2.convexHull(contour))
your biggest problem will be the orb contour merging with the background due to low contrast. so maybe some adaptive threshold could help
I'm trying to design a Userform in Excel 2010, and I'm coming across a very annoying stumbling block where as I'm trying to move things around, resize them and align them so the form looks appealing.
Unfortunately, different mechanisms are snapping to differently sized grids. For example, drawing a box onto the grid snaps it to multiples of 6, which is the default option found in the Tools> Options> General> Grid units. Resizing these objects snaps it to a seemingly arbitrary grid size that seems to be approximately 7.2 units.
I need these units to match up so I'm not constantly fighting myself getting these grids to function. I don't care what the actual number ends up being, I just need them to be the same. While I'm able to change the grid size, it must be a whole number, which the arbitrary grid is not.
Problem us your units Points <-> Pixels
6 Points * 4/3 points per pixel =>> 8 Pixels .. all good
A nice integer of pixels
Your approx 7.2 I suspect was 7.3333333
Maybe say 11 Points Set gets changed as
* 4/3 => 14.6666 pix Rounded to 15 pix
by 3/4 Pts/pix +> 11.33333
Points as single .. Pixels as integer may be the problem in the math
I have some images and I want to extract the exact color of them. Is it possible to find out which kelvin temperature were used by camera in auto white balance mode? I read this link below for that is for two years ago but by that answer in Wikipedia I couldn't calculate AWB parameter.
This is a part of my thesis and I really need to find a way to estimate the kelvin temperature that camera applied on the images. my images are almost one color and I want to know the real color of that.
Thanks.
Link:
How to get camera exact white balance parameters value when it is in auto mode?
Probably the top, industry standard tool is ExifTool by Phil Harvey.
Phil is very good about keeping up with the new cameras and is admirably conscientious about tracking down reported problems.
D:\pic\pedernales.river\nef\p5\>exiftool.exe -ColorTemperature -Tint *t.tif
Color Temperature : 3750
Tint : -10
And if you are dealing with RAW data, there are 2 pre-Bayer interpolation tags of interest (actually the ~same numbers A=B*256)
WB_GRBGLevels => 256 413 353 256
WB_RBLevels => 1.61328125 1.37890625 1 1
http://www.sno.phy.queensu.ca/~phil/exiftool/
There is also a very slick GUI that wraps by BogdanH it if you need it.
http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=2750.0
And an indispensable Perl Module: cpan install Image::ExifTool
There is also a telepathic interface, but I can't remember where I put it. ;)
BrianP
exif exiftool Image::ExifTool
I'm working on a 2D game using SDL. One thing that keeps bothering me is that all objects jiggle a bit in relation to each other when the camera is moving slowly.
This is because SDL doesn't support sub pixel positioning, I have to use integers for positioning things on screen.
Here's a quick example of the problem, in case it's not obvious yet. Say I have a side scrolling game where every entity has only an x position:
Entity positions:
friend.x = 0.1
foe.x = 0.3
What's rendered:
friend.x = 0
foe.x = 0
Now let's say the camera is moved to the left by 0.2:
Entity positions:
friend.x = 0.1 + 0.2 = 0.3
foe.x = 0.3 + 0.2 = 0.5
What's rendered:
friend.x = 0
foe.x = 1
There, it jiggles. Both should have moved minimally, but what's rendered is that friend didn't move at all, and foe jumped a whole pixel to the right. When the camera moves another 0.2 to the left, friend will do the jump and foe will stay still. Unfortunately it's actually quite noticeable in practice at low speeds.
The easiest way to mitigate this seemed to be to work with integer positions internally, but I can't really get that to work for my game, just doesn't play well with the physics. I've tried various rounding methods in desperation, but that doesn't seem to change anything in practice. There's still always this jump point when rounding.
So, is there anything I can do to reduce the jiggling? Assuming I'm stuck with both floating point positions and having to work with integers when rendering?
SDL isn't to blame - monitor don't support subpixel positions because, hey, pixel definition. In some rare cases you can use pixel components (dots) separately, but this requires knowledge of actual monitor (different colour orders for different monitors, like RGB, BGR, vertical RGB, etc.); this is how subpixel font antialising works. But font is just one colour, on actual image it would produce insane results.
Only adequate solution I see is increasing resolution. Either resolution of monitor, or by rendering image into higher resolution render target and then downsampling it back to monitor resolution with some filtering.