Is "color cycling" possible in GDI+ with WinForms? I'd like the modify one or more colors in the palette of an on screen surface so that whenever the surface is repainted, GDI+ will use the modified colors.
Rather than perform the transformation manually pixel-by-pixel, I hope to use GDI+'s capability to render surfaces using indexed colors. (8bpp indexed color?)
Is there a (fast) way to do this?
NOTE: I don't want to modify the colors globally throughout the application UI. Rather, I only need to cycle colors on one particular control surface.
AFAIK, this is tied to 8bpp video mode (256 simultaneous colors from a palette of several million). Since almost nobody runs in that mode these days, you wouldn't be able to do hardware palette-based color cycling.
Depending upon what you're trying to do, there may be simple way to achieve this. Can you provide more detail?
Related
I'm looking for a way to have images on invisible form that allow alpha transparency and allow to place and use buttons/labels etc.
I've tried this Transparent background on winforms?, layered window and many more, nothing fully successful. I've ended up with such failures http://imgur.com/a/t6nmF
Transparency key only makes one color transparent, which doesn't work on images that have smooth color gradients on the edges.
First of all, are you certain that your image has a transparent background?
Layered window is exactly what you should use to achieve the desired effect. Since you don't give much details, I don't know what's wrong with your implementation. Try to use the PerPixelAlphaForm from the following article: Per Pixel Alpha Blend in C#. When used correctly, it will work (even though the article is really old).
I'm trying to draw something like the transparent-indicating background when you use Photoshop or other image processing software.
Like I said in the title, I'm using HatchBrush, and the large checker board style is not large enough for me. Beyond that, I would rather like to be able to control how large each tile is based on current zoom factor or other stuff in my environment.
I have also written the code to draw a lot of filled rectangles, but this was way too slow for some reason (this allows me to control tile size though).
I have not tried Texture Brush yet, but to have a texture means I can not change the colors on the fly easily, so I would rather avoid that unless run out of options.
Is there any ways that I can configure HatchBrush or do something more basic but efficient?
I found the answer when looking at WPF. A solution was on their tutorial with brushes.
https://msdn.microsoft.com/en-us/library/aa970904%28v=vs.110%29.aspx
Is it good practise to build my UI with minimal images and define things like shapes/paths etc in the XAML?
If so, what are the advantages of this approach and/or other approaches?
In my opinion, having been creating UIs in WPF for the past 7 years, yes it is good practice in general. However, it depends entirely on the aesthetic you want to provide. Static images add to your application size but can be easily cached making them performant. They're a little inflexible as an image will distort the second you try to stretch it's dimensions. Images are fine if you don't need it to be dynamically sized.
However, you'll find that defining your UI entirely with markup can be a lot more complicated and can stray from your pixel-perfect mockups at various sizes. Gradients produced in WPF are inferior quality, you'll see visible banding if the gradient spans too far.
Performance doesn't play much of a role unless you intend to use a lot of DropShadowEffects (do not use legacy BitmapEffects). Stick to the lightweight elements (such as FrameworkElement) when templating controls.
By the way, there's a fantastic and recently free icon studio called Syncfusion Metro Studio 1 which is a fairly extensive icon pack that allows you to customize the size, background, foreground, & padding, then it lets you choose if you'd like to save it as an image or export it as a XAML path. The benefit of using XAML paths are that they will be perfectly scalable and you can dynamically change the fill color, could be set by the user even. Something that is possible with images using a custom color overlay shader but very resource intensive.
Here's the scenario:
I am using Visual Studio 2008 with .NET framework 3.5. I am using C#. And for database I am using MySQL. I have a picturebox on a form and 10-12 buttons (each with some image manipulation function). On clicking one of the buttons openfiledialog box is shown up where the user can select the specific file to provide to the program. On clicking another button the program should perform the actions as explained below.
I have an image of a circuit. Suppose this is the image which is provided to the program. e.g.
What I intend to do is that - the program should hypothetically label the circuit as follows:
and then it should separate the image and store the information in a database.
Is there any way to do that. Can anyway tell me the approach to do that? Any help or suggestions please.
Thanks.
In image processing, the problem of finding the 'parts' of the circuit is known as connected component labeling. If you are using C#, I believe that you can use EmguCV (a wrapper to the OpenCV library) to solve the first part of the problem. To do that, you have to consider that the white pixels are the background and that the black pixels are objects.
Now that you have the separated traces, the problem is reduced to finding and labeling the white dots. Again, you can solve it by connected component labeling, but now the objects are represented by white pixels and the background are the black pixels.
At least for your example case, a very simple algorithm would work.
Find a black pixel from the image
Using a flood-fill algorithm, find all the pixels connected to it, and separate it. That's one of your traces.
Working with the separated trace, find a white pixel and use a flood-fill algorithm to find all the pixels connected to it. If you run to the edge of the image, it's not a hole. If you don't, it might be a hole, or a loop in the trace. Use a threshold for the hole size to determine if it's a terminal hole or a loop.
Label the hole and remove it from consideration. Repeat until there are no more unprocessed white pixels.
Remove the whole trace from consideration, and jump to 1.
When there are no more black pixels in consideration in step 1, you're done.
You should probably get pretty far with a basic image editing library that has a flood-fill function, a function to separate a certain color into a new image, and a function to replace colors (the last two are trivial to implement, and there are plenty of flood-fill algorithms available online). You can use different colors to mark different things, for instance, color everything "no in consideration" red. It also makes for an interesting visualization if you look at it in real time!
I know it's recommended to convert images to XAML as they become blurred when changing the dpi.
What about standard ICO files which actually are really BMP files?
I need to use these in a toolbar. Do I need to convert all to XAML?
Is there a better way?
What about a similar feature in HTML called sprites where it's one big image but you get items via positions?
Essencially you work with static images when no scaling is needed, and you work with Vector Images when you want to perform all sorts of scaling. This is the rule of thumb for most WPF and Silverlight applications.
However you can't directly convert a static image to a Vector Image (what you call XAML), and most times it will require a designer to do some work on the Vector Image.
Working with vector images makes the rendering process heavier, the more vectors, the slower the rendering pass. It also makes it slower to instanciate a particular Visual Tree, when you add it to something already on screen. This can be overcome if you call RenderToBitmap and cache the sizes of the Vector Images you want to use, but this requires aditional custom code.
Working with static images allows for much faster renders. However upsizing will cause pixelization and downsizing may cause artifacts on the image. When you work with static images PNG is considered to be the prefered format, you have full control over the compression, you have alpha key and it's an indexed format which makes it fairly small in size.
I always convert all images to XAML where it's possible. I think it's good rule.