XamlXaml.com

I thought it might be interesting to see how well the workflow between UI designers and developers works. With this in mind, I am putting the Infinite Image Engine UI (such as it is) up for grabs for any and all UI designers to come up with a polished user-centric design for the app. The best implementation will be selected as the UI in the final app as well as kudos given to the designer.

This is all in the spirit of fun and exploration, so be as creative as you like . To get some info on the elements that make up the interface and ideas to get you started you can view the XBAP of the interface. The source code for the interface can also be downloaded. Comments and/or questions are welcomed. Just drop a note here or email me directly at xamlXaml.com : mgemmons.

Good luck!

-MGE

My work in WPF image manipulation lately has made me question just how good an idea it is to have WPF measurements not tied to pixels, but rather device-independent-units. I understand the theoretical benefits of the design such as controls automatically being able to scale to the correct size regardless of screen resolution, but when trying to manipulate images this all becomes another layer of abstraction which makes everything more difficult. 

The primary issue is the translation between what image is being displayed on the screen and the actual image size. For example, if a bitmap is 300×300 pixels the ActualHeight and ActualWidth of the Image object (System.Windows.Controls.Image) that the bitmap is associated with could be anything…from 15×15 to 1000×1000 device-independent-units. Yet, for the purposes of image manipulation the original image size always has to be used, because even if an image is displayed at 1000×1000 device-independent-units, the actual number of pixels contained in the BitmapSource is still 300×300. Great.

So, now we are left with having to manipulate the original bitmap and resizing/scaling it up to the display size. This is probably only a minor headache when dealing with 1 original image and 1 manipulated image, but when dealing with 1 original image decomposed into 1000’s of composite images it becomes problematical.

This became apparent while working on my current project, the Infinite Image Engine. The framework takes a source image, decomposes it into hundreds or thousands of swaths of average color, and then recomposes it using a database of images matching each swath to an image of similar average color. It is fairly straightforward when the source image size displayed matches the actual image size, but decidedly not so otherwise.

The primary problem is that the most convenient image manipulation handles are found in the Image’s BitmapSource (Image.Source). This has methods to copy pixels and modify pixel values, but it is all based on the original bitmap’s pixel sizes and does not reflect the display size. This is by-design, but that doesn’t leave developers with any built-in options to manipulate on-screen images. Instead we are left to create an abstraction layer to do the translation between the display size and the original image size. While this is certainly doable, it wouldn’t be my first or even second choice for how to get things done. If we are going to be stuck with device-independent-units in WPF, and overall I think it is a good design, then the measurement should be ubiquitous throughout the system, including at the BitmapSource level.

Michael G. Emmons

I have been having issues with the DownloadCompleted and DownloadFailed events failing to fire correctly from the BitmapImage object. This is a huge issue as the asynchronous processing of images is central to many types of WPF apps. Having events failing to fire correctly will likely have a rather large negative impact on these apps.

The problem is easily recreated. Iterate through any number of BitmapImage creations, subscribe to the DownloadCompleted and DownloadFailed events, and track the number of DownloadCompleted + DownloadFailed events which fire vs the number of events subscribed to. Those numbers should always add up.

In my testing the events only fire correctly on the first full iteration. After the first iteration they will never fire again. Ever. The event subscriptions are simply going into a black hole. Verify for yourself. You can create your own app or just use my test app.

I’d be interested to hear the results of everyones testing.

-MGE

The framework is coming along nicely. In the screenshots above you can see the before and after for my test image. The after image is composed of 800 photos pulled from flickr.

I’ve been focusing on the color matching algorithms, which I’m now pretty happy with. Although in the processed image you will notice that the halo around his head does not quite match, that is the result of settting a fairly high color tolorance of 20 rather than problems with color matching. Setting to a lower tolorance will result in closer matches (and also more difficulty in finding matches).

My next focus will be to improve rendering. For example, the overall look of the composite image will be a closer match if the same replacement image is not used more than once-or at least used only a very few times and not directly next to each other. Using the same images in succession results in too much of a pattern appearing in the image, as is the case with the processed image above. Less pattern is better. Think pointillism, like Matisse’s “La Maison verte, Venice” and you will have a good idea of what I’m striving for.

It’s interesting to note just how closely the composite will often match the original image. For example, the boy’s nose in the processed image is clearly visible. His ears and hair shading are distinct as well as the shadow under his chin. Some of the feather patterns on the left wing are even rendered…although in this case the wing pattern may be an example of the resuse of images working in favor of the composite image.

That’s it for now. More to come soon!

-MGE

Apologies for the lack of recent posts. Things have been hectic with a wedding (not mine) in Hawaii recently and preparing for a trip to Italy next week. Have no fear, though-there are lots of interesting things coming up!

 -Michael G. Emmons

I have been made aware that the xbap examples are not being served up correctly. I am looking into this and should have it resolved soon.

[UPDATE] It seems that the MIME types required to serve the XBAP did not register right away, even though they were added to the configuration files. Everything should work correctly now.

If anyone has any other issues please let me know.

-MGE

Some of you may know me from my blog over at mgemmons.com. While I will still be using that space for general topics I find of interest to me and an occasional rant, xamlxaml will be focused specifically on the Microsoft .NET 3.0 Windows Presentation Foundation and XAML.

Why the move toward blogging about a specific technology? I believe WPF represents a great stride forward for software developers and architects. Our mantra has always been, “Extract the UI from the business logic, extract the UI from the business logic…” Unfortunately, while we may be much better off than we were 10 years ago, we’ve never really come close to that ideal…until WPF.

Think about it-developers generally aren’t good at creating effective user interfaces and designers generally aren’t good at coding functionality. So, in a perfect world we would have graphics designers design our user-interfaces and developers design the functionality behind that interface. We come nowhere close to that today. Oh, once in a while we may work closely with graphics designers to try to create an interface for our application, but what that really involves is the designer creating a mach-up in Illustrator or other graphics package, sending us a screenshot of that mach-up and us trying to implement it as best we can. To acerbate the situation, there isn’t a whole lot of “design” that can be developed into an application. Sure, we can change the color scheme, fonts, and how our controls are laid out…these are all important considerations in creating an effective application, but one windows application looks pretty much like every other because we have little choice about how control are rendered-how they look, how they interact with each other and the data they are associated with.

With WPF, for the first time there is the opportunity for real effective communication between the designer and the developer. A designer can create a user interface in their native tools such as Illustrator, export that to XAML and have the developer hook up the logic for the interface. Not just a mach-up for the interface, the actual interface the designer created. This is the great draw WPF has for me. To be able to integrate good design with good development can only make our applications better.

This space will be an exploration of just how we can make our applications better using WPF. I’ll pass along my ideas, insights, and plenty of WPF examples. Come along on this ride with me and let’s see what we shall see.

Michael G. Emmons