I'm going to be doing a project on a Raspberry Pi where I display an image through a projector. The image is a rectangle that exactly twice as long as it is wide. Since I'm displaying via the projector, that means the side furthest from the project will end up being narrower than the closer side, so I need to expand that side of the image.
Can someone point me in the right direction of how I'd implement that please? I don't even know what the right terminology is to good it and look into the math I'd need to do.
What you're asking for is called "keystone correction," I believe. Many video projectors can do this automatically, so it's worth checking before writing a pile of code :)
Here's how to do this using the ImageMagick convert utility. You need to know the size of the image to start with. For the sake of discussion, let's assume it's 889 x 746. Also, let's assume we want the image to be "thinner" at the bottom than the top, by 60 pixels, and that the "thinning" is symmetrical about the vertical centre-line.
So let's call the top-left pixel (1,1), the top-right (889,1), the bottom left (1,746) and the bottom-right (889,746). The top-left and top-right pixels stay where they are; the bottom-left "moves" from (1,746) to (61,746). The bottom-right moves to (829,746), because 889-60 is 829 -- this is a move to the left.
The convert -distort perspective command requires the coordinates of four pixels, their pre-move and post-move values. It then calculates how to move all the other pixels, such that straight lines in the original remain straight. So, taking the calculated values above, we need:
convert in.png -virtual-pixel transparent -distort perspective \
'1,1 1,1 \
889,1 889,1 \
1,746 60,746 \
889,746 829,746' \
out.png
Of course, the spacing isn't essential: it's just to show how the numbers line up with the calculated values above.
Naturally, you'll need to adjust the numbers to suit your image size, and the degree of correction you need. ImageMagick is avilable for Raspberry Pi, and it's easy enough to embed a call to convert in application code.
Related
I have a square image with a ragged edge: the transparent pixels outside the image "weave" in and out towards the image center, within some unknown range. This range may be different for each side.
Is there an algorithm that would crop the image to the largest size possible with no transparent pixels remaining? I can think of an iterative one: start with a small cropping square in the center. If no transparent pixels are detected, start again but enlarge the cropping square by 1 pixel. Then repeat. Once you detect transparent pixels after cropping, go back one step and save the result.
There is an obvious algorithm that comes to mind:
Find y* = min_y {(x,y) : P(x,y) is transparent }, where P(x,y) is the pixel at coord (x,y) then crop the image [0,y*] (assuming the image starts at zero at the bottom, and that transparent pixels always happen at the top of the image.)
Note that this algorithm has serious downsides, if y* happens to be very close to 0 because of an errant transparent pixel, you will end up cropping almost your entire image.
If you want a more robust solution, I believe you will have to frame this problem as an optimization problem and solve it, allowing for some errant transparent pixels to be masked instead of cropped. The algorithm that would do well for you would be an energy-based formulation which could be solved using graph-cuts. For example, see the GrabCut algorithm.
If you know your requirements and how bad your data can get you can make a judgment call for how involved you want to make your solution, but at this point I would highly recommend clarifying the requirements of your solution as well as how bad your data can get.
I have a system that removes the colour white (give or take a few shades), from an image and replaces it with an alpha channel. (The image is taken from the users phone camera, and tries to remove selected colouring)
This leaves harsh edges most of the time, and I want to know if it is possible to add some type of anti-aliasing on top.
The system works by taking in the image, and searching through each pixel data. If the pixel is white (or close), it will replace it with an alpha colour.
So I guess my question is, how do I make the edges less harsh. Thanks.
Anti aliasing is not what you are looking for. This takes care of effects caused by the limited resolution of your image. However, your problem is not related to resolution, you would still have it with infinite resolution.
What you need to do is when you find a white pixel, increase the transparency of the pixel itself and the pixels around it.
You can just include the four pixels immediately above, below, left or right of your white pixel, or you an choose any other shape, e.g. all pixels which lie inside a circle of given radius around the white pixel.
Also you can choose a function which determines how transparency is distributed over that shape. You can make everything half-transparent or you can decrease the effect towards the edges of that shape (though I don't think that this will be necessary).
Thus each pixel will receive transparency from several pixels around them. The resulting transparency must be computed from all these contributions. Simply multiplying them probably won't do, because you will have a hard time ever reaching alpha=0. You may however, interpret (255-alpha) as a measure of transparency, add all contributing transparencies and then convert back into alpha. Something like max (0, 255 - (255-a1) + (255-a2) ...).
It will be difficult to do this in-place, i.e. with just ony copy of the image. You might need an intermediate "image", where each pixel is associated with all transparency contributions from the pixels around it.
I'm developing a custom control. One of the requirements is to draw lines. Although this works, I noticed that my 1 pixel wide lines do not really look like 1 pixel wide lines - I know, they're not really pixels but you know what I mean. They look more like two or three pixels wide. This becomes very apparent when I draw a dashed line with a 1 pixel dash and a 2 pixel gap. The 1 pixel dashes actually look like tiny lines in stead of dots.
I've read the Cocoa Drawing documentation and although Apple mentions the setLineWidth method, changing the line width to values smaller than 1.0 will only make the line look more vague and not thinner.
So, I suspect there's something else influencing the way my lines look.
Any ideas?
Bezier paths are drawn centered on their path, so if you draw a 1 pixel wide path along the X-coordinate, the line actually draws along Y-coordinates { -0.5, 0.5 } The solution is usually to offset the coordinate by 0.5 so that the line is not drawn in the sub pixel boundaries. You should be able to shift your bounding box by 0.5 to get sharper drawing behavior.
Francis McGrew already gave the right answer, but since I did a presentation on this once, I thought I'd add some pictures.
The problem here is that coordinates in Quartz lie at the intersections between pixels. This is fine when filling a rectangle, because every pixel that lies inside the coordinates gets filled. But lines are technically (mathematically!) invisible. To draw them, Quartz has to actually draw a rectangle with the given line width. This rectangle is centered over the coordinates:
So when you ask Quartz to stroke a rectangle with integral coordinates, it has the problem that it can only draw whole pixels. But here you see that we have half pixels. So what it does is it averages the color. For a 50% black (the line color) and 50% white (the background) line, it simply draws each pixel in grey:
This is where your washed-out drawings come from. The fix is now obvious: Don't draw between pixels, and you achieve that by moving your points by half a pixel, so your coordinate is centered over the desired pixel:
Now of course just offsetting may not be what you wanted. Because if you compare the filled variant to the stroked one, the stroke is one pixel larger towards the lower right. If you're e.g. clipping to the rectangle, this will cut off the lower right:
Since people usually expect the rectangle to stroke inside the specified rectangle, what you usually do is that you offset by 0.5 towards the center, so the lower right effectively moves up one pixel. Alternately, many drawing apps offset by 0.5 away from the center, to avoid overlap between the border and the fill (which can look odd when you're drawing with transparency).
Note that this only holds true for 1x screens. 2x Retina screens actually exhibit this problem differently, because each of the pixels below is actually drawn by 4 Retina pixels, which means they can actually draw the half-pixels. However, you still have the same problem if you want a sharp 0.5pt line. Also, since Apple may in the future introduce other Retina screens where e.g. every pixel is made up of 9 Retina pixels (3x), or whatever, you should really not rely on this. Instead, there are now API calls to convert rectangles to "backing aligned", which does this for you, no matter whether you're running 1x, 2x, or a fictitious 3x.
PS - Since I went to the hassle of writing this all up, I've put this up on my web site: http://orangejuiceliberationfront.com/are-your-rectangles-blurry-pale-and-have-rounded-corners/ where I'll update and revise this description and add more images.
The answer is (buried) in the Apple Docs:
"To avoid antialiasing when you draw a one-point-wide horizontal or vertical line, if the line is an odd number of pixels in width, you must offset the position by 0.5 points to either side of a whole-numbered position"
Hidden in Drawing and Printing Guide for iOS: iOS Drawing Concepts, though nothing that specific to be found in the current, standard (OS X) Cocoa Drawing Guide..
As for the effects of invoking setDefaultLineWidth: the docs also state that:
"A width of 0 is interpreted as the thinnest line that can be rendered on a particular device. The actual rendered line width may vary from the specified width by as much as 2 device pixels, depending on the position of the line with respect to the pixel grid and the current anti-aliasing settings. The width of the line may also be affected by scaling factors specified in the current transformation matrix of the active graphics context."
I found some info suggesting that this is caused by anti aliasing. Turning anti aliasing off temporarily is easy:
[[NSGraphicsContext currentContext] setShouldAntialias: NO];
This gives a crisp, 1 pixel line. After drawing just switch it on again.
I tried the solution suggested by Francis McGrew by offsetting the x coordinate with 0.5, however that did not make any difference to the appearance of my line.
EDIT:
To be more specific, I changed x and y coordinates individually and together with an offset of 0.5.
EDIT 2:
I must have done something wrong, as changing the coordinates with an offset of 0.5 actually does work. The end result is better than the one obtained by switching off the anti aliasing so I'll make Francis MsGrew's answer the accepted answer.
I am searching for an article or tutorial that explains how one can draw primitive shapes (mainly simple lines) with a (neon) glow effect on them in the graphical output of a computer program. I do not want to do some sophisticated stuff like for example in modern first pirson shooters or alike. I am more in a search for a simple solution, like the lines in that picture: http://tjl.co/blog/wp-content/uploads/2009/05/NeonStripes.jpg -- but of course drawn by a computer program in my case.
The whole thing should run on a modern smart phone, so the hardware is a bit limited.
I do know a bit about OpenGL, but not too much, so unfortunately I am a bit lost here. Did some research on Google ("glow effect algoritm" and similar), but found either highly complex stuff for 3D games, or tutorials for Photoshop & co.
So what I would really need is an in-depth article on that subject, but not on a very advanced level. I hope thats even possible... I have just started with OpenGL, did some minor graphics programming in the past, but I am a long-year programmer now, so I would understand technical papers in general.
Does anyone of you know of such an article/paper/tutorial/anything?
Thanks in advance for all good advices!
Cheers!
Matthias
Its jus a bunch of lines with different brightness/transperency. Basically, if you want a glow effect for 1px line, in a size of 20 pixels, then you draw 41 lines with width of 1 px. The middle line is with your base colour, other lines get colours that gradiently go from base color to 100% transperency (like in your example) or darkest colour variant (if you have black background, no transparency).
That is it. :)
This isn't something I've ever done, but looking at your example, the basic approach I'd use to try and recreate it would be...
Start with an algorithm for drawing a filled shape large enough to include the original shape and the glow. For example, a rectangle becomes a slightly larger rectangle, but with rounded corners. An infinitessimally-wide line becomes a thickened line with semi-circular caps. Subtract out the original shape (and fill the pixels for that normally).
For each pixel in the glow, the colour depends on the shortest distance to any part of the original shape. This normally reduces to the distance to the nearest point on a line (e.g. one edge of a rectangle).
The distance is translated to a colour value using probably Hue-Saturation-Value or a similar colour scheme, as well as reducing alpha (increasing transparency). For neon glows, you probably want constant hue, decreasing brightness, maybe increasing saturation, and decreasing alpha.
Translate the HSV/whatever colour value to RGB for output. See this question.
EDIT - I should probably have said HSL rather than HSV - in HSL, if L is at it's maximum value, the resulting colour is always white. For HSV, that's only true if saturation is also at zero. See http://en.wikipedia.org/wiki/HSL_and_HSV
The real trick is that even on a phone these days, I'd guess you probably should use hardware (shaders) for this - sorry, I don't know how that's done.
The "painters algorithm" overlaying of gradually smaller shapes that others have described here is also a possibility, but (1) possibly slower, depending on implementation issues, and (2) you may need to draw to an off-screen buffer, with some special handling for the alpha channel, then blit back to the screen to handle the transparency correctly - if you need transparency, that is.
EDIT - Silly me. An alternative approach is to apply a blur to your original shape (in greyscale), but instead of writing out the blurred pixels directly, apply the colour-transformation to each blurred pixel value.
A blur is basically a weighted moving average. Technically, a finite impulse response filter is implemented using a convolution, but the maths for that is a tad awkward and if you just want "a blur" of about the right size, draw a grayscale circle of pixels as your "weights" image.
The blur in this case basically replaces the distance-from-shape calculation.
_____________________
| |
----|---------------------|-----> line
|_____________________|
gradient block
Break up your line into small non-overlapping blocks. Use whatever graphics primitive you have to draw a tilted rectangular gradient: the center is at 100% and the outer edge is at 0%.
Don't draw it on the image yet; you want to blend it with the image. Using regular transparency will just make it look like a random pipe or pole or something (unless you draw a white line, and your background is dark).
Here are two choices of blending mode:
color dodge: [blended pixel value] = (1-[overlay's pixel value]) / [bottom pixel value]
linear dodge: [blended pixel value] = max([overlay's pixel value]+[bottom pixel value], 1)
Then draw the line above the glow.
If you want to draw a curved "neon" line, simply draw it as a sequence of superimposed "neon dots" where each "neon dot" is a small circular image with transparency going from 0% at the origin to 100% at the edge of the circle.
I'm trying to come up with a way to distort an image similar to the example here:
http://tinypic.com/r/16gn60o/7
The idea is to remove any hard lines in the original image. I would like the original image to be "about the same" not a hard swirl effect you see in some screensavers or anything like that.
Any pointers or idea would be great!
You could make a "stamp" that pushes pixels out radially. That is, precalculate a mapping (for a patch smaller than your image) that takes pixels from the center of the patch to a point a little further out, and have this displacement start at zero in the center, grow with the radius, but then get smaller as you approach the boundary of the patch so that it's zero at the edges. Then apply this deformation at random points around your image until you've covered the whole image.
Note that this will will actually sharpen the edges a bit, but make them not straight, like your example image. Note that in the example, the edges are actually more sharp and defined (see the edge of the dog's right ear for example), but just not straight, so I'm assuming this is what you mean by "hard".