We have a Silverlight application that shows text over video. Both the text and video can be considered variables. Sometimes we might have a dark video, sometimes a bright video, sometimes a video that has sections of both.
Think of credits at the end of a movie. We want to ensure the end user can always read the text being show over the video. The text is always an overlay on top of the video.
The simple solution is to two show the text twice once in white and once in black with a small offset. This almost works but actually looks a little rough, and takes away from the user experience.
Ideally we would have the text with slight semitransparent glow around the edges. So if the text were white there would be a black glow right around the edges.
Is there a way to do this? Or is there an equal or better work-around?
I've done this with the DropShadow pixel shader effect in Silverlight 3. It works nicely, but since the pixel shaders aren't executed on the hardware, it can have a pretty heavy impact on the performance of the application.
If you wanted to get ambitious, you could write your own pixel shader. Silverlight 3 supports HLSL Shaders.
You could try displaying it with a contrasting outline, rather than just a "drop shadow" like you get if you display it once with a small offset. To do this, display it four times in one color, then a fifth time with a contrasting color, centered over the four previous copies. The four first ones should be offset one pixel up, right, down and left of the center.
The net effect should be an outline. Of course, perhaps this too looks "rough", since it's computer-generated and thus not perfect with respect to issues like kerning, spacing between characters, and so on. But it's quick to try, at least.
In general, automatically finding good contrasting colors when the background is video sounds a bit difficult. In the worst case, the video contains text just like the one you want to display. The correct solution in that case is hard to imagine.
Sounds similar to the problem of ensuring subtitles are always readable in films/TV. The most robust, but not necessarily most elegant solution, is to have a coloured background rectangle for the text which is either opaque or has a low transparency value - often grey or black with good contrasting foreground colour.
Related
Sorry for the vague title, I have no idea how to really ask this question to be honest so I'll describe what I'm trying to do
I'm attempting to make an app where users can change the colors of different parts of a car. They can change the door for instance to a green as shown, or any other color they wish. They would then be able to change the color of the hood, or the roof, etc.
I've thought about having seperate images for each component and then lining them up to match. However this seems practically impossible when it comes to different screen sizes and scales. I also thought about making a blanket white image, and then creating views over the top with the selected color.
Does anyone have any ideas how I could possibly approach this?
Thankyou
I dont know about the performance of this. But, how about, an overlay of the different parts of the car, but using the same size of the whole car. For example, you have the image of the whole car, and erase all but the door. In other image, you erase all but the hood. If you lay one image above another, it will make the whole car, and the size of the screen will not affect you, because all the images will have the same size.
Then you can use the tint style to change the color of each layer.
Other questions on SE address how to speed up nested UI control resizing, but- what if there aren't any controls?
As you drag the edge of a WPF window, even a main window with no content, black bars flicker briefly during the drag. This produces a crummy feel- one that I don't want to inflict on customers:
It does get slower and heavier with a full UI on top of it as well. This doesn't even get into how ugly it looks when resizing using the top or left edges. Windows Forms- even with the heaviest UI I've built- never looks this bad right off the bat.
What can be done to make WPF window resizing performance comparable to win forms?
(I have Windows 7 x64 and a triple monitor system on an AT Radeon HD 7470.)
You could update your graphic card and try it out again but that wont change anything. The reason is pretty simple. We all get to see this sometimes based how fast/slow our computer is. Sometimes it runs smooth because we do not have many visuals to draw. The reason is no proper background color is found in graphic card at that moment in redrawing process. Your drivers are fine, and its not just because you use Wpf. Other techniques use the same mechanism behind redrawing.
The first thing WPF will do is clear out the dirty region that is going to redraw. The purpose of dirty regions is to reduce the amount of pixels sent to the output merger stage of the GPU pipeline. Here is where we see the black color. Window itself at that point has no background color or its background color is set to transparent and so to us the GPU draws the black background. Things run async in wpf which is good so.
To fix this you could set a fix color such as "White" to the Window. Then the WPF system will clean out the dirty region but fill it automatically with white color instead of black. This usually helps.
Match the window color or the color of top most layer. Dont let GPU use black and you should do fine. Btw Wpf is faster than WinForm so dont worry.
The look is crummy indeed, especially when using the top or left border.
Which exact problem your screen shot is showing depends on how long your app is taking to render as well as a couple of background related settings that you might be able to tweak to get better resize. Plus part of the ugly resize is specific to Aero.
While I can't address the specific crazy slowness of WPF redraw, I can at least give some insight on why you see black, where that is coming from, and whether you can change to a less annoying fill-in color.
It turns out there are multiple different sources of the black and the bad resize behavior from different Windows versions that combine together. Please see this Q&A which explains what is going on and provides advice for what to do (again, not specific to making WPF faster but just seeing what you can do given the speed you have):
How to smooth ugly jitter/flicker/jumping when resizing windows, especially dragging left/top border (Win 7-10; bg, bitblt and DWM)?
I've got a paint program I've been working on, and I've started to tackle opacity. I'm at a point now where I compare the background color to the brush color, average the two based on their alphas, and then set a new pixel. I just need to cache a portion of what I'm drawing off to the side so that it doesn't continuously sample what is continuously changing while the mouse is down. I figured I would fix this by throwing 50 pixels into a stack or queue that starts changing pixels on screen once it's full and completely empties all it's contents onto the screen on mouse up. What I'd like to know is what would be more efficient, two stacks (one of coordinates and one of colors) or one stack of strings that I parse into coordinates and colors.
TLDR: What's more efficient, two stacks of different data types, or one string stack that I parse into two data types.
Your question seems longer and more confusing than it needs to be, but I think what you're asking is:
I'm designing a paint program. If the user is painting 50%-opaque black pixels on a white background, I want them to show up as gray. My problem is that if the user draws a curve that crosses itself, or just leaves the mouse cursor in the same place for a while, the repeated pixels become darker and darker: 50% black, then 75%, then 87.5%... I don't want this. As long as the mouse button is down, no pixel should be "painted" twice, no matter how many times the curve crosses itself.
This question answers itself. The only way to keep pixels from being painted twice is to keep track of which pixels have been painted since the last time the mouse button was up. Replace
image[mouse.x][mouse.y] = alpha_average(image[mouse.x][mouse.y], current_color, current_alpha);
with
if (not already_painted[mouse.x][mouse.y]) {
image[mouse.x][mouse.y] = alpha_average(image[mouse.x][mouse.y], current_color, current_alpha);
already_painted[mouse.x][mouse.y] = true;
}
handle(mouse_up) {
already_painted[*][*] = false;
}
Problem solved, right?
But to answer another implied question: If you're trying to choose between a bunch of parallel arrays and a bunch of data stuffed into strings, you're probably doing it wrong. All Unity3D languages (Python, C#, Javascript) support struct/class/dict types and tuples, either of which would be a better idea than parallel arrays or everything-is-a-string-ism.
I have a sequence of images taken from a camera. The images consists of hand and surroundings. I need to remove everything except the hand.
I am new to Image processing. Would anyone help me in regard with the above Question. I am comfortable using C and Matlab.
A really simple approach if you have a stationary background and a moving hand (and quite a few images!) is simply to take the average of the set of images away from each image. If nothing else, it's a gentle introduction to Matlab.
The name of the problem you are trying to solve is "Image Segmentation". The Wikipedia page here: wiki is a good start.
If lighting consistency isn't a problem for you, I'd suggest starting with simple RGB thresholding and see how far that gets you before trying anything more complicated.
Have a look at OpenCV, a FOSS library for computer vision applications. Specifically, see the Video Surveillance module. For a walk through of background subtraction in MATLAB, see this EETimes article.
Can you specify what kind of images you have. Is the background moving or static? For a static background it is a bit straightforward. You simply need to subtract the incoming image from the background image. You can use some morphological operations to make it look better. They all depend on the quality of images that you have. If you have moving background I would suggest you go for color based segmentation. Convert the image to YCbCr then threshold appropriately. I know there are some papers available on it(However I dont have time to locate them). I suggest reading them first. Here is one link which might help you. Read the skin segmentation part.
http://www.stanford.edu/class/ee368/Project_03/Project/reports/ee368group08.pdf
background subtraction is simple to implement (estimate background as average of all frames, then subtract each frame from background and threshold resulting absolute difference) but unfortunately only works well if 1. camera has manual gain and exposure 2. lighting conditions do not change 3.background is stationary. 4. the background is visible for much longer than the foreground.
given your description i assume these are not the case - so what you can use - as already pointed out - is colour as a means of segmenting foreground from background. as it's a hand you are trying to isolate best bet is to learn the hand colour. opencv provides some means of doing this. if you want to do this yourself you just get the colour of some of the hand pixels (you would need to specify this manually for at least one frame) and convert them to HUE (which encapsulates the colour in a brightness independen way. skin colour has a very constant hue) and then make a HUE histogram. compare this to the rest of the pixels and then decided if the hue is simmilar enough.
This is a question regarding a very simple construction - I have the following XAML:
<Viewbox Height="100" Stretch="Uniform">
<TextBlock FontFamily="Georgia">My Cool Text</TextBlock>
</Viewbox>
This is quite simple to understand. Yet when I start the program I get strange blurry text (there are no bitmap effects anywhere in my project).
(left side - the designer view in VS2010, right side - the running application)
Does anyone have ANY suggestions about why this is happening??
While Jefim has correctly answered his own question, I wanted to explain why you get this behaviour when using this particular set of features. Jefim suggests that this is a bug in WPF, but it's not. The problem arises as a result of asking for WPF to do something impossible. It has to pick a compromise when you've asked for this impossible thing, and the result is what you see above.
The explanation is a bit long for a comment, which is why I'm putting it in a separate answer.
This example uses two mutually contradictory features of WPF. Those features are:
The ability to render visuals consistently at any scale
The ability to render text in the same way GDI32 renders text
You can't use both features at once. GDI32 renders text in a way that cannot be scaled consistently: if a particular piece of text at a certain font size happens to be 200 pixels wide, if you multiply the font size by 3, and render the same text in the same font family at that new font size, in GDI32 it probably won't be 600 pixels - it'll be close, but it will typically not be quite right.
GDI32 messes with the shapes and widths of characters in order to enhance the clarity and sharpness of the text. Specifically, it bends letters out of shape so that their features align better with the pixels on your screen. And where necessary, it will adjust the width of individual characters to be an exact number of pixels wide. Since this letter bending is all based around actual pixels, it bends text in different ways at different font sizes.
While that gives you nice sharp looking text, it looks absolutely horrible if you try to change the scale gradually. If you try to animate the font size of some text rendered in this fashion, the thing will seem to shimmer and shudder, because the adjustments made in the name of clarity end up being slightly different at each font size. Even if you're not animating, it can still produce poor results - if you have a single typeface shown at a number of sizes, it can look quite different at each size; if your application has a zoom feature, the character of the text can seem to change significantly as you zoom in and out. (And so can the layout. If you use Microsoft Word, you may have noticed that you sometimes get odd-looking extra wide spaces between certain words. This is the result of Word fighting with GDI32 - Word attempts to keep the on-screen layout as close as possible to how things will look when printing, which means it sometimes clashes with GDI32's grid fitting.)
So WPF offers a different approach to text rendering: it can render text in a way that is as faithful as possible to the original design of the font. This distorts the text less, and it means that you don't get discontinuities as you scale.
The downside is that the text looks blurry, compared to how text rendered by GDI32 looks. (The distortions made by GDI32 are all aimed at improving clarity.)
So in WPF 4.0, Microsoft added the ability to render text in the way GDI32 would. That's what TextOptions.TextFormattingMode="Display" does.
By turning on that option, you are saying "I don't need consistent scaling, and I'd prefer clarity, so generate the same pixels you would have done in GDI32." If you then go on to apply scaling, having told WPF you didn't need scalability, you get crappy results. WPF carefully generated a bitmap representation of the text exactly to your specifications, and you then told it to render that text at a different scale. And so it looks like what it is: a scaled bitmap of some text that was generated for a different resolution.
You could argue that WPF could do something different here: if you apply a scale transform in GDI32 you'd see different behaviour - you'd see the inconsistency at different scales described earlier. If you really want that effect in WPF you can get it by modifying the font size directly. But WPF doesn't prioritise getting that same effect - its goals are to make it possible to get GDI32-style crisp text when you really need it, and to provide consistent scaling by default.
And what you're running into here is the "consistent scaling". Turning on GDI32-style text rendering doesn't break consistent scaling: applying a scale factor (either directly, via a ScaleTransform or indirectly via a Viewbox) will change the dimensions of the visual by exactly the specified scale factor. If it were to re-generate the text visuals by grid fitting to the newly scaled size, the text would come out at a different width. That would actually cause the Viewbox problems: it applies a scale factor based on the content's natural size, designed to make it fit the available space. But if it re-did the grid fit after scaling, that would actually change the width. Because of the inconsistencies inherent in how GDI32 text rendering works, it might not even be possible for the ViewBox to find a suitable scale - it's possible to come up with a piece of text which, when rendered in a particular font, will never come out at 200 pixels wide. For some font sizes, the rounding inherent in grid fitting might bump the size down to, say, 198, and it might stick at that as you make tiny increments in the font size, until you go past some threshold at which point it might jump to 202 pixels.
For a Viewbox attempting to force the text to fit into exactly 200 pixels, that would be a problem. But Viewbox doesn't work that way - it uses WPF's consistent scaling, downstream of the point at which you chose the font size to which GDI32-style text rendering is working. So Viewbox will always be able to do what it is designed to do, but that is task that's fundamentally incompatible with GDI32-style text rendering.
So in short, WPF renders the text for the font size you requested, and then scales the result.
So you have to pick just one feature - you can't have both because that's simply impossible. Either don't attempt to render text in a context in which an arbitrary scale factor may be applied (e.g. Viewbox) or don't turn on GDI32-style text rendering. Otherwise, you get that weird pixelated text that you've encountered.
Ok, bug found. My Window style has the following setter:
<Setter Property="TextOptions.TextFormattingMode" Value="Display"/>
If I set it back to "Ideal" (which is the default value) then it renders the text inside the viewbox correctly. I would say that this is a bug inside WPF. Basically, if you try this:
<Viewbox Height="100" Stretch="Uniform" TextOptions.TextFormattingMode="Display">
<TextBlock FontFamily="Georgia">My Cool Text</TextBlock>
</Viewbox>
You will get the same result as in my initial picture.