My article on doing digital panoramas using PTAssembler and PanoTools is now up at the Luminous Landscape photography site.  If you haven't seen it before, this site is a wonderful resource for anyone interested in serious photography.  I'd like to thank Michael Reichmann, the proprietor, for giving me a chance to contribute.

For some earlier entries and photos check out this, this, this and this.

As an intersting aside, the Idaho State Capitol building photo (from here) is an example of what happens if you don't set the reference image and point correctly.  This is very similar to using a large amount of horizontal shift to the right.

If you have any questions on the article, let me know and I'll try to answer them here.  There are a ton of resources out there on doing this stuff, so my main advice is to just jump in and give it a try.

Raymond, ever the source of interesting info, details how to extend the context menu in IE.  This was the first feature that I coded up at MS after I joined back in 97.  This came in late in the IE4 product cycle.  It is cool to see that it still comes up once in a while.  The original idea was to allow a dictionary program to let you right click on a word to get a definition.  It turns out to be much more powerful than that.

My entry pointing to our WinHEC slides resulted in links from quite a few sites and a ton of hits.  Top among these was an article on Slashdot.  Also notable are links from OSNews and Brad Wardell (joeuser.com).  In the last year my blog has gotten 20k hits (not counting RSS reads).  In the last day it has gotten something like 25k hits.  I'm sure that most of those 25k people won't be back to read this entry, but I'll respond anyway.

I appreciate the attention and I've been trying to keep up with all of the comments.  Here are some notes and responses:

• First off, I can't answer every question.  I have no desire to get in to a flame war over specific details or comparisons.
• Avalon's relationship to Direct3D:  I tried to make this clear in the slides, but it is worth repeating.  We are building a managed presentation and UI layer on top of Direct3D.  While we will be exposing a 3D API, it is meant to round out the UI story and integrate well with our 2D API.  If you are doing super complex 3D stuff (FPS games), or want access to the latest and greatest Direct3D features, Direct3D is the way to go.  If you want to mix a little 3D in with your 2D, Avalon's 3D APIs will let you do that in a painless way.
• Do we really need the eye candy?: This has been a popular topic ever since we started planning and talking about Avalon.  I'm planning on posting something on this later to start the discussion.  My short take: I think that providing more capability in the platform is a good thing that will make Windows a more attractive place to write applications.  I think that it will also allow our stock user experience (Aero and the shell team) and application developers to push the limits and interact with users in fundamentally better ways.  However, with power comes responsibility.  We are working on a set of guidelines (these are the Aero user interface guidelines) to help application authors use this stuff in a consistent way.
• The 3D bar graph demo is useless: I admit, this example is useless as is.  In a real application there will be a lot more UI about picking what data you want to look at and how you want to look at it.  The position and view of the 3D graph would probably be controlled by the mouse so that you can rotate things around to see hidden data.  There would probably be different types of graphs that you would switch between.  However, this was meant as a demo application that we threw together in a couple of days.  While the application is a demo, the platform that it is running on is real.  There should be nothing stopping someone from building a more industrial strength really usable version of this.
• We are behind the ball on 64 bit:  While Windows had been compiling and shipping (well, in beta to be clear) on 64 bit for quite a while (we handed out ia64 and x64 versions of Longhorn at WinHEC and via MSDN) the real call to action here was to IHVs.  Remember this was the Windows Hardware Engineering Conference.  IHVs have limited resources wrt writing drivers and we want to encourage them to write and maintain 64 bit drivers.  This was one of the big pushes for the conference as a whole.  We don't want 64 bit uptake to be slowed down by lack of driver support.
• The longhorn requirements are crazy: I don't know where the requirements listed here came from, but I haven't seen that list.  Obviously we won't see that on a laptop!  There are a couple of things to note here. 
  • First, we will run in software and on lower end machines.  Things may run slower, but it will run. 
  • Second, we are going to offer multiple experiences based on hardware capabilities and user preferences.  This ranges from a classic view, to Aero to Aero Glass. 
  • Third, the current minimum requirement for Aero Glass is a DX9 class card with 64MB of video memory.  More video memory will be required for higher resolutions or multiple monitors.  We also require the GPU to support PS 2.0 and have a LDDM (Longhorn Device Driver Model) driver.
  • Fourth, as for processor requirements, most of the time when we have, in the past, required a certain speed processor it has been because that speed has been an indicator of the rest of the components in the machine (bus speed, hard driver speed, memory speed, processor instruction support, etc.)  The idea has been to use that one number as a heuristic for the "generation" of the machine.  Hell, I've run Win2k3 server on a 400MHz celeron. 
  • Lastly, we are really concerned about battery life and are working hard to come up with a scalable user experience for times when battery life is more important than running the GPU at full throttle.  I believe that there are a bunch of slides in Kerry's talk on that.
• (my favorite) "dipshits still can't code html/css?": I never claimed to be an artist, but the CSS in question was my attempt to get a little bit funky with the style of my site.  It is on purpose.  I assume that it will work in most browsers but, honestly, I only tested it with IE and Pocket IE.  I posted a response to this on slashdot but apparently someone thought I wasn't me.  Too funny!
• The whole Apple transparent window thing:  I don't read or comment on patents.  However, transparent windows have been around for quite a while.  In the windows world, these things were introduced in W2K with layered window support.  Other OSs may have had something similar earlier.
• Longhorn is just vaporware.  I'll believe it when it ships in 2017:  I'm not crazy enough to comment on ship dates.  I'll leave that to the PR people and the execs.  However, we are showing off real code.  We've publicly shipped two builds of Longhorn (the PDC and the recent WinHEC build) along with SDKs.  Not everything is done yet and it is rough around the edges, but this isn't just slideware.
• Innovation:  Innovation is such a loaded word.  Hell, MS probably did more to make it loaded than anyone else :).  However, I never used the word on my blog and I don't know where the guy who posted this to OSNews.com got it.  It really touched off a flamewar there which basically comes down to your definition of innovation.  Leaving that aside...  I think that Avalon, and Longhorn in general, puts a lot of very interesting features together in an integrated API that will benefit developers and end users in very exciting ways.  Use your own definition of innovative to parse that last sentence.

Well, hopefully that runs the gamut.  I probably missed some stuff, but I have to get some real work done today.

The slides from the WinHEC sessions are posted up at ms.com.  We had 4 sessions that were Avalon specific:

• Greg Schecter: Avalon Graphics Stack Overview [682 KB]
• Joe Beda (me): Avalon Graphics - 2D, 3D, Imaging and Composition [284 KB]
• Kerry Hammil: Graphics on the Windows Desktop [496 KB]
• David Brown: Avalon Text [1.05 MB]

Since most people who read this weren't there and couldn't ask questions, don't be afraid to ask questions here.  I'll either answer them here or try to get an answer for you.

While reading these slides, keep in mind that we were targeting hardware people.  This was really about letting IHVs know what they can do to prepare for what is coming in Longhorn and Avalon.

Dan has started a blog where he will be talking Avalon 3D.  He is one of the devs that is currently working on this part of Avalon.  Even though the Avalon 3D stuff is still early (we aren't feature complete yet) he plans on talking through what you can do with the WinHEC build.

Check it out!

Ha! I get linked from a comment and I see a spike in traffic.  Slashdot is the flow machine.  In any case, there are some misstatements in that comment that I'd like to answer.  First, I'm not "the guy from Microsoft behind Avalon."  Rather I'm one on a large team of developers.  My particular area is the graphics APIs.  Avalon is much more than just graphics.

Second, managed code is a different beast that unmanaged code.  While it can make programmers more productive and I totally think that it is the way of the future, a developer can write bad code in any language.  While right now I don't think that anyone would claim that managed code is faster than unmanaged code, the difference is generally not that great.  I've heard of some research that suggests that future JITs may be able to apply run time directed optimizations and recompilation that could make managed code faster.  But that world isn't here yet.

In the parlance of our time: "Just my 2 cents"

I'm done with my part of helping make WinHEC a success.  My talk went off pretty well and we got some great questions and comments.  I also worked the booth and showed industry and press people what Longhorn can do.  The big news for the WinHEC release is that we now have a start to our 3D APIs.  We had a couple of examples that show mixing 3D and 2D in a seamless way.  I tried to go out of my way to make sure that everyone knew that Avalon was much more than just graphics.  We are a full UI platoform that includes controls, styling, databinding, etc.

The main demo I was showing was a simulated "blood sugar tracker."  It essentially has a 3D bar graph in the background that slowly rotates.  Layered on that are semi-transparent buttons.  There is also a details panel that can come up that is semi-transparent and has another 3D scene hosted inside of it.  We have a vector graphic doctor icon in the corner that you can zoom in on to see that it is rasterized at the device resolution.  The really impressive thing here is that our demo team (a dev and a designer) took 2-3 days to turn this from an email idea into reality.  Robert and Nathan did a great job of showing the power of Avalon.  Here is a screen shot:

I should have posted this earlier, but better late than never.  I'm going to be speaking at WinHEC.  It'll be session TW04006: Avalon Graphics - 2D, 3D, Imaging and Composition.  If you are there and are interested in Avalon come check it out.  I'll be going in to some detail on what happens between when a developer calls an API and we call Direct3D.  If you aren't going to be there, wish me luck.  The room holds 700 people (I think) and I've never talked in front of that many people before.

I'll also be hanging out in the tech lounge and be at our "Ask the Experts" session.

Here in Windows (and in other groups around the company) we have a system that is generally called stress.  Different groups have different implementations, but the idea is always the same.  You develop a test suite that hammers you system and then have everyone install it and run it overnight.  The idea is that this way we can catch those hard to repro issues that only our customers see.

When you get one of these errors, what do you do with it?  Generally there is a team of people who have the thankless job of coming in early, finding all the machines that have broken in to the debugger, logging the failures in a database and having the system send mail to various people to investigate.  The actual debugging is done via the NT command line debugger (cdb) redirected over the network via the remote.exe utility.  It is up to this team to figure out which issues have already been caught and fixed (but perhaps aren't in the build yet) and what issues are new and need to be investigated.  These guys cover a lot of code so the generally don't have the knowledge to figure out what developer should be looking at any particular problem.  That falls to the rotating list of people who are on "stress duty."  The shell team calls it "dev of the day."  We've learned by hard experience that if you send these types of things to a big mailing list, they either get ignored or the same sorry glutton for punishment picks up all of the issues.

I happen to be on stress duty this week.  My job is to handle, in as expedient a fashion as possible, any incoming issues.  I have to do my best to exercise my debugging skills and try to figure out what is going on.  BTW, Raymond Chen is one of the undisputed masters of the cdb kung-fu.  If I can figure out what is going on myself, I can file a bug on the issue and let the person whose machine I'm debugging reclaim their machine.  If the problem is in code that I don't know well it is my job to reassign the issue to someone who does know the code well. 

Beyond handling incoming stress breaks in the morning, I also have to be responsive to all sorts of other issues that might get dropped on the floor.  This includes other random crashes people might have during the day along with helping out to resolve any build breaks.  (We try super hard to make sure that build breaks don't happen, but with something the size of Windows it still sometimes happens.)

Do other companies have systems like this set up?  I'd be interested to hear what works for you.

Over on Channel9, there was an interesting question about the history of how my team in Avalon decide to split our component between managed and unmanaged code.