Go Flow

Bruce Silver put together a summary of The Real Issues with XPDL, BPEL, and BPMN where he explained better than I could that the aspect of portability that is more valuable depends on what you’re trying to do. He correctly points out that “XPDL captures the diagram, while BPEL captures the process semantics.”

Bruce brings BPMN into the discussion as potentially the standard that is possibly the most important. There have been a number of discussions recently of the relation of these three standards, including Jason Stamper in Computer Business Review and Jon Pyke in EBizQ.

Before going any further, there is one thing that must be straightened out. XPDL 2.0 captures every aspect of any BPMN diagram. It is a complete representation of all element and all attributes of BPMN. A couple of the people were involved in both BPMN and XPDL specifications, and single guiding principle for the 2.0 release is that there should be a well defined way to store every property mentioned by the BPMN specification. My descriptions of XPDL often focus on the X & Y coordinates, and the shape of the lines, because this is an obvious differentiator from BPEL, but it does not stop there. XPDL also represents the attributes that specify a web service call, or the event definitions, and every other attribute mentioned in the BPMN specification. XPDL also extends this with additional ability to express process semantics that was developed over the years in WPDL and XPDL 1.0 by the collection of workflow/BPM vendors attempting to define exactly the important semantics to exchange.

XPDL is a strict superset of BPMN. This means that everything and anything that can be expressed in BPMN, can be captured by XPDL. The complete process diagram, including any and all process semantics expressed by that diagram.

Bruce has criticized XPDL for inability to take an executable process from one vendor product, and bring it to another vendor product, and guarantee is it understood. He is right. There is no guarantee that a process drawn in one product, saved in XPDL, will be immediately executable in another product. This is not because XPDL fails to capture the semantics, but instead a failure to (1) be able to unambiguously capture those semantics in standard BPMN, as well as (2) a failure of the receiving tool to understand the same semantics that the sending tool transmitted.

To the extent that BPMN can represent the complete process design, XPDL can transfer that complete process definition, including all the semantics of that process. To the extent that BPMN is ambiguous and misunderstood by another tool, XPDL is similarly likly to fail. This is because the XPDL is essentially a one-to-one representation of the BPMN.

Let me use an analogy again. Another standard that is very important is the Unicode standard of characters and character encoding. I can write English all day long and be completely assured that every expression is 100% captured and stored in a Unicode file (let’s ignore markup for the moment). I would say that Unicode is a great success at allowing people to communicate, and it carries the complete semantics of every expression. Others would point out the obvious flaw in my thinking: only 1 person in 10 speaks English, and thus 90% of the world can not read my posts (well, there are probably another 30 to 40% that could muddle by enough to make sense of it, but you get what I mean…). A French person can use Unicode as well, and be completely assured that their expression will be preserved with Unicode, including all the semantics. Zut alors! While Unicode guarantees that the expression is completely preserved, it does not guarantee that all readers will be able to understand the expression.

BPMN gives us a vocabulary to describe business processes, in the same way that a dictionary gives us words. But please note: the underlying meaning is not in the words, but in how those words are put together. There are a number of different dialects of BPMN out there. Two tools that use the same dialect of BPMN, can easily exchange processes via XPDL.

Let me give you an example. Lets say there was a product called “Vulcan Mind-Meld” which used BPMN to express the diagrams that have meaning to this product. BPMN defines what each of the symbols mean, but the real meaning, the real semantics comes from the way that the symbols are composed together. Mind-Meld would guide you as you draw this diagram, making sure that you do not put anything together in a way that is nonsensical. The author of this diagram is making an expression that has meaning in Mind-Meld. Here is a possible diagram which is consistent with the BPMN specification:

What does this mean? I frankly don’t know. I tried hard to make an ambiguous diagram that still obeyed all the BPMN rules. This is not to imply that there is any flaw in BPMN, but simply that with any language you can follow the rules, and make something that is meaningless to some readers. But stick with me for the moment.

We can argue about whether Mind-Meld should allow this expression, the main point I want to make here is that Mind-Meld can save this diagram to XPDL and read it back in again with complete fidelity. All the attributes of the elements are preserved. None of the semantics would be lost. Another product called “Klingon Kommand & Kontrol” would be able to read that XPDL file. It would have all the nodes, and all the attributes of those nodes. It could reproduce the diagram. Its ability to understand the meaning of the diagram depends upon it interpreting the combinations of BPMN symbols in the same way that Mind-Meld did.

This is the essence of Bruce’s concern: he would like Mind-Meld product to interpret the BPMN expression into a “universal process meaning”, and then communicate that meaning to the Komand & Kontrol product in such a way that it can not be misunderstood. That is kind of the Holy Grail of process modeling, there is only one problem: this is very very very difficult.

We could wish for the same thing in the Unicode analogy: that the English expression could be somehow digested, understood, and represented in a language independent way, such that any reader would be guaranteed to receive the meaning. Thus I would write an expression in English, it would be digested and decoded, and then would be displayed in French to the French reader, German to the German readers, and surfer-lingo in parts of Santa Cruz. This, of course, is very very difficult.

But if you think about it, why would you save and exchange anything other than the diagram that the author composed? The original diagram is the expression of the author. How that expression be converted into anything that carries more meaning than the original diagram? If the meaning in BPMN is unambiguous, then every tool that reads it will interpret it in the same way.

If I was to write in English, why would I store and exchange anything other than the English that I wrote? If a French reader wants a translation, it can be translated from English to French at that time. If there was an intermediate structure that could represent the meaning of the English, it is not clear that it would be better than the English that was written originally.

It works the same with BPMN/XPDL. If you want to transfer a process definition from one product to another product, it makes the most sense to transfer the original diagram that the designer drew. This contains the best representation of what the designer intended. Then, if a translation is needed from one dialect to another, it can be done at that time.

This was a conscious choice in the design of XPDL. XPDL represents the process diagram in a one-to-one manner, more or less directly what the process designer drew, and not an abstraction of it. This does not mean that the semantics are dropped on the floor — they are there in the diagram just as the designer put them there. Each product, however, must interpret the BPMN to get the meaning from it.

Back to the Vulcan Mind-Meld example: can this diagram be represented using BPEL and read back in again? Most likely not. Again, this is not a flaw of BPEL. The strength of BPEL is that all of its elements are rigorously defined. This increases the liklihood that it is understood by all readers. But it also decreases the flexibility. I might be wrong: if someone would like to post the BPEL representation of the Mind-Meld process, I think we all would be very much interested in seeing it. The XPDL, on the otherhand is easy to make.

BPDM, the future metamodel from OMG, promises to be the “universal process meaning” for process products that can represent any process, including Vulcan Mind-Meld. Every product will interpret the BPMN diagram, and express the meaning of that diagram in BPDM. This would be a huge benefit to us all. We don’t know how well this works since it is not available yet. But in any case, it is not clear to me that this representation would be more faithful than the original BPMN diagram. It seems that the OMG folks expect different products to interpret the BPMN in different ways! With this assumption, then how are we humans supposed to know what a BPMN diagram means by looking at it? The whole point of BPMN is that it should be an unambiguous representation of the process, so that when people see it, they interpret the meaning, and when products read it, they get the same meaning from it. I am with Bruce on this: BPMN is the most important standard for unification. That is the goal of BPMN, we are not there today, but we have a path that may lead there.

Until the advent of XPDL 2.0, there has not been a way to transfer BPMN diagrams from product to product. Each product was isolated and developed dialects of BPMN the way that isolated people developed different spoken languages. Now that we have a way to transfer these diagrams, it is very likely that groups of products that work similarly will tend to use BPMN in the same way, and that shared dialects will emerge.

This trend is enabled because XPDL can represent any BPMN diagram.

Why can’t all products interpret the BPMN in the same way? This is another of Bruce’s concerns. Why can’t there be a single dialect of BPMN? Please stay tuned for my next post.

I got a comment on my last post which so obviously misses the point so much of the discussion around these standards, that I half suspect this Anonymous post was a practical joke from a colleague for the amusement of watching me get defensive.  However, lets assume that the poster was sincere, and respond to anyone who might hold a similar point of view.

Arguing that BPEL is “more” or “better” than XPDL is like arguing that red is “more” or “better” than blue.  Like arguing that apples are “more” or “better” than oranges.  Like arguing that a race-car is more or less useful than a jeep.

Consider an analogy of two file formats: one for documents (e.g. Microsoft Word) and one for presentations (e.g. Microsoft PowerPoint).  If you look at a list of “brochure points” these different product categories might seem very similar: they both support fonts and word-wrapping, they both support pagination, they both have the ability to draw graphics, they both can do tables, they both can display full screen, they both have spell checking, they both support hidden comments, and so on.  Yet you might assemble a room full of people;  on one side would be the technical writers, journalist, novelists who would point out how the document format is clearly superior and more useful to them, and they would be right.  These writers might say that they have the presentation software, but just use it to make graphics to paste into the documents, and overall the document format is of primary importance.  Yet on the other side of the room is a bunch of presenters, lecturers, teachers, and (dare I say it) politicians.  This side claims that is the presentation format that is far more useful and powerful;  while they keep the document processor around to read files they occasionally find on the Internet, they really only need the presentation package to do their work.  If such a debate were considered seriously, it could go on forever getting more and more detailed about the fine points of word-wrapping, spell-checking, animation, pagination, etc.

Hopefully this analogy makes it clear just how silly such a debate would be.  There is no war between document processors and presentation graphics packages.  Yes, there is a certain overlap, but the only thing that the debaters are proving is that they have different goals for what the software should do.  There is no reason to believe that adoption of a document format will necessarily cause the exclusion of a presentation graphics format.  They are different things used for different purposes.

Just to make things perfectly clear, I never said that BPEL was less important than XPDL.  I never said that BPEL would in any way be replaced or supplanted by XPDL.  BPEL is an important standard that does what it does, but utterly fails to what XPDL does, because it is simply a completely different thing.  There is no war between XPDL and BPEL.

For example, draw a process diagram, lay the nodes and lines in particular positions, write it out to BPEL, and read it back in.  It is impossible to get the same diagram back in because BPEL simply has no way to preserve node positions and line positions.  Arguing that you don’t NEED the lines and positions to be preserved brings us with circular logic back to our starting point: BPEL and XPDL are designed to satisfy different needs.  XPDL, on the other hand, represents the graphics of the process, and when you read it again you end up with the same diagram.

Let me illustrates the differences between these different standards in a more concrete way.  I will have to use a very simple diagram, and a simplifications of the BPEL and XPDL output, so bear with me.  Consider the following BPMN diagram:

What do you see?  On the surface, you see six shapes: two circles, two diamonds, and two rounded rectangles.  You also see six lines (with bends in them) that connect the shapes.  Those lines have arrows to show the direction of flow.  If you understand the symbols in BPMN, then you understand that this diagram is showing that after the process starts, there are two activities: Activity1 and Activity2, which execute at the same time.  The process will complete only after both activities are complete.  See how there are two ways of thinking about the picture, one is very superficial and includes the specific shapes, the other attempts to include only the underlying meaning.  This is similar to the distinction between BPEL and XPDL.

BPEL attempts to capture only what the execution engine needs to know: the two activities and the fact that they need to be run in parallel.  In BPEL, if you want to activities to run at the same time, you nest the activities inside of a <flow> tag.  The flow tag says that everything inside of it will be executed in parallel.  A highly simplified BPEL output might look like this:

In a certain sense, this is all that an execution engine needsto know.  The two invoke activities will be launched in parallel, and the process will not complete until both invoke activities are complete.  But if you try to read this back into the process modeler, you will find that you can construct something that looks very much like the original (because the AND gateways can be added in because they are logically required, and the arrows between them are logically required) but you can not guarantee that the diagram will be the same because the graphical information is simply not there in the file.  Note that BPEL has no way to directly represent a line in the diagram, and it does not need to, since lines are not executed, they simply show the relationships of things.

The XPDL representation would be decidedly different.  XPDL represent the process model, not simply what is needed to execute the process.  It will have six activity tags to represent each of the nodes (in XPDL the term “activity” encompasses all of the BPMN nodes: activities, gateways, and events) and it will have six “transition” tags, one for each line.  The graphical coordinates for the nodes can all be saved, and the points for the lines, including details of precisely where the lines bend and where they touch the nodes, is included in the Transition tag.  A simplified version might look like this:

Above is a direct representation of the process diagram, not the abstracted meaning behind the diagram.  It should be obvious to everyone that you can read the XPDL file, and recoverthe exact same diagram that you saved.  XPDL is a direct one-for-one representation of the BPMN diagram, and all the additional attributes associated with the diagram.  BPEL, on the other hand, is a one-way transformation; the translation is a “lossy” translation because it does not contain all the details of the diagram.  It was never designed to do this, so there is nothing wrongwith this, it simply is something that BPEL does not do.

Saying that  ”BPEL is more portable than XPDL” simply tells me that all you care to communicate is the execution meaning of the process.  It tells me that you do not care about, and possibly have never tried to transfer a process diagram of any complexity.  If all you need to do is to communicate process execution semantics, then by all means continue to use BPEL - there is no reason to think you should be using XPDL for this.  They are, after all, completely different standards designed for completely different things.  However, your experience with interoperability is not commonplace.  John Evdemon, co-chairman for the WSBPEL working group at OASIS, asked the attendees of last year’s BPM ThinkTank whether anyone was using BPEL for interoperability between products.  When nobody raised their hands, he used this as evidence to support the claim that “the portability of executable BPEL will be low to non-existent“.  It is a strong claim, and the head of the working group should have as much experience as anyone in the subject.  But if it works for you, that is great. 

I personally believe that eventually BPEL will offer great value to all of us, and I support its adoption for the things that it is capable of doing.   At the same time, so does XPDL, which is capable of exchanging of process definition diagrams between products.  The broad support of the XPDL standard today, with more than 60 products using it, is a sure sign that it will not die any time soon.  I only hope that this post has helped make it clear for all those die-hards out there that adoption of XPDL does not mean that BPEL is on the decline nor does the adoption of BPEL cause the demise of XPDL.  They are simply different things, like apples and oranges.

A lot of you know I am a big proponent of XPDL, the XML Process Definition Language. Not only because of the tremendous amount of good work that went into it, but also I see it being successfully used on a daily basis. It solves a real problem, and is available today. I am, apparently not the only one who feels this way.

In the last few weeks we have been investigating software that supports XPDL to try and get a definitive list, so we combined lists from several sources. The result surprised even me: we were able to identify over 60 different products that claim support for XPDL available today. Check the list at the WfMC site as well as my own list. Scan down the list of names, there are many important companies on the list:

• Large corporations: Adobe, Advantys, Appian, BEA(Fuego), EMC, Fujitsu, IDS Scheer, Infor, Interwoven, Global 360, IBM(FileNet), Oracle, Software AG, TIBCO, Unisys, Vignette to name a few of the bigger ones. It is also worth noticing that implementation is not limited to large corporations.
• Open source process editors such as Enhydra JaWE open source process editor and IT Pearls open source plug in for Visio which read and write XPDL.
• Open source process engines that execute XPDL directly, including Enhydra Shark, WfMOpen, Open Business Engine, Bonita, Workflow::WfMC, jawFlow, Pentaho, and others.
• Commercial process design tools like Cubetto Toolset, Jenz & Partner, Eclair Group Lynx.
• Specialized process tools, for example consider SimProcess which is a stand alone process simulation product. Or Zynium’s Byzio product, which can convert any unprepared Visio dirgram into an XPDL file for transferral to other tools.
• Adoption seems to be spread all over the world, including Rodan, HOGA.PL, R-DATA & Polsoft in Poland, Metoda S.p.A in Italy, Together in Austria, numerous companies in France, Germany, England, US, NEC Data & Fujitsu in Japan, Monosys in China, and many other parts of the world.
• Across the technological landscape, many of these are written in Java but there is also strong representation in the .Net world with Ascentn and Aspose both offering .Net products that support XPDL, as well as Perl, C++, and other language offerings.

There is another way to get an idea for the breadth of adoption. Consider Gartner’s Magic Quadrant for BPMS vendors for 2006. In the top three quadrants, there are 11 vendors listed. (Actually 12, but IBM and FileNet merged late last year after the MQ was released.) Here is the alphabetical linup of the top 11 vendors and whether they support XPDL:

• Adobe: YES
• Appian: YES
• BEA (Fuego): YES
• Fujitsu: YES
• Global 360: YES
• IBM (FileNet): YES
• Lombardi: ?
• Metastorm: ?
• Pegasystems: YES
• Savvion: ?
• TIBCO: YES

8 of the 11 top BPMS vendors clearly support the standard, and the other three might, I simply don’t know at this time. Is it fair at this point to consider the standard a success?

Here is the really strange thing, nobody seems to know this! Just two weeks ago yet another article was written in Computer Business Review where Tony Baer makes the following claims:

“Until now, workflow has been fairly virgin territory, given the failure of XPDL, an XML standard developed by the Workflow Management Coalition to attain critical mass support much beyond the classic document workflow crowd.”

“…XPDL got too specific, and began traipsing on the agenda of vendors like IBM, Oracle, and SAP. They dismissed XPDL as being dated due to its document workflow orientation.”

What strange comments! A quick review of the list of supporters make it clear that classifying this list as “classic document workflow” is very much off the mark. How unusual that IBM and Oracle are listed as non-supporters, when in fact they do have products supporting XPDL. Where does this conclusion about being ‘document oriented’ come from? Mr Baer is not alone in being confused by all the mis-information produced by corporate marketing literature, but I would expect a journalist to research more thoroughly than the product brochures.

The biggest misperception in the marketplace is that BPEL and XPDL are in some kind of a war. I have already covered elsewhere how this is silly, so I won’t duplicate it here. I think Jon Pyke’s response makes it clear how these very different standards serve very different purposes.

Yet, in conclusion, I would like to express my gratitude to Mr Baer. It was his article, after all, that prompted us to get off our duffs and update the list of products that support XPDL. As I said before, more than 60 products supporting XPDL surprised even us. I believe we have reached the tipping point.

Hey Bruce! I am your biggest fan. When you make a comment, on workflow, or on photography, I really take it to heart. Your comment sowed the seeds of doubt about whether HDR photography is worth the trouble. Afterall, as a hobbiest I have not really spent much time manually manipulating RAW format pictures. My camera (Canon G6) has a 10 bit per pixel sensor, which gets then compressed to 8 bits per pixel in the JPG. That is potentially 10 f-stops (EV) of dynamic range. Somewhere I found a web page listing the G6 as having a luminosity range of 1:650, which is between 9 and 10 EV. I hear better cameras can get 10 to 11 EV. Maybe, as you say, that is enough. Clearly combining pictures taken +2 EV, and -2 EV could potentially potentially add 3 or 4, giving the total range around 13 or 14 EV. How do I know whether I need the extra range?

How important is this dynamic range, anyway? The human eye records an instantaneous dynamic range of 1:30,000, a range of 1:200,000 if you allow a couple of seconds for the iris adjust, and 1:1,000,000 if you wait 20 minutes for the eyes to adjust to darkness. All of these make the 1:1000 of a camera seem tiny. But how much do you really need?

I set out to take a some photographs to see whether I really need to purchase the Photomatix software, or whether this is just a fad promoted by photo perfectionists. The first picture was a tree in the courtyard of the Fujitsu campus in Sunnyvale. I recorded the pictures in RAW format, and took a large number of different exposures, each about 1 EV apart. I then compared two results: the first is from combining all the different exposures into a single HDR image, and then tone mapped that back to a JPG. The second was by taking a single RAW image, the one at the “correct” exposure, converting that to HDR, and tonemapping with the exact same setting.  (I am too lazy to link this photo, sorry.)

First thing I have to say is that the results with the RAW image were dramatically more stunning than doing the manipulation from the JPG generated by the camera. I will certainly do more of this in the future.  I have to say, on this first photo, the results of the single exposure, and multiple exposure were essentially the same! The colors were great, the picture clear, and the dark and highlights were without problem. What I found out is that this first photo did not need the high dynamic range. I think that will be the case in many pictures, just as Bruce suggested.

The second picture, however, convinced me to get the software. This is a picture of a fountain in the sun which is very bright, but includes the dark side of a tree, as well as a lot of dark details on the building in the background. I took a total of 7 different exposure settings in RAW format. (Since then I have found that it is unnecessary to take so many, but this is how I learned that.) Again, I processed two examples: the combined HDR, and an HDR made from the single best exposure. I was careful to use the exact same tome mapping for the output. This is a little unfair because you might do the tone mapping a little different for the single exposure, to bring out the blue in the sky a bit more, but I wanted to be able to exactly compare the results.

First of all, here are the two photographs, reduced to fit on the page. The first is the single exposure, which the second is the photo made from combining 7 exposures. Please see the links at the bottom of the blog entry for links to the full size (7.1 Megapixel) images.

Most of the picture appear the same at this scale. You notice mostly that the sky is bluer in the combined exposure photo, because the single exposure tended to wash out the color a bit because the sky was a little over exposed. But the trees, the grass, the fountain, the buildings look pretty much the same.

The fountain is in the sun, and it is very bright. The biggest difference between these images is seen when you look closely at the fountain:

The difference here is dramatic! The fountain was bright enough that it was completely overexposed in the single exposure shot. The multiple exposure shot, however, used information from the darker pictures to get a clearer impression of the fountain.

How about the dark places? Maybe the original single exposure picture was simply overexposed. This also shows a dramatic difference:

Notice how speckled the rafters appear in the single exposure image. This is noise that is appearing at the dark end of the luminosity range. The multiple exposure image is dramatically cleaner, because the image information for this part of the picture was taken from photos that were otherwise over exposed. Notice in the multiple exposure image you can see some wood grain in the front most board, and how much clearer the details in the vines in the background are.

What this demonstrates is that for this picture, the single exposure could not capture both the bright areas, and the dark areas at the same time, but the image made from combining multiple exposures did this beautifully. That was enough for me, and I purchased Photomatix this morning.

I took these pictures with 1 EV spacing, requiring 5 or 7 images. In hindsight, it should be fine to use 2 EV spacing, and in general 3 exposures will probably do. This will be much more convenient since the camera will do exposure bracketing with 3 photos, spaced 2 EV settings apart, so that all the pictures can be taken without touching the camera, which will reduce the chance of shifting the camera direction. This should be fine for all but the most extreme shots.

If you would like to compare the complete photographs, here are links. Please keep in mind they are big, so you probably want to right-click-save-as to avoid downloading multiple times.

• Single Exposure, 7.0 MB JPG
• Multiple Exposure, 6.1 MB JPG

The combined HDR image was 23.8 MB, and each of the 7 RAW images were 8.8 MB. These pictures were taken on March 15 2007, at about 3:30 in the afternoon, on the Fujitsu campus in Sunnyvale.

A few days ago I found out about High Dynamic Range (HDR) photographs. A short search on the web will bring you lots of information, but somehow I have been living just fine completely oblivious to HDR.

The threory behind HDR is that film (and digital cameras) have a particular dynamic range that they are sensitive to. Light intensity values that fall outside of this range, tend to get smashed together and “washed out”. Yo can see this easily if you take a picture of someone with the sky behind them, but set the exposure so that you can see their face. The sky will often appear completely white and lack any detail. Similarly, if you take a picture of a room, often the windows will appear completely washed out without being able to see what was outside. The same thing happens on the dark end of the intensity spectrum: dark details will completely disappear into the rest of the black areas.

Since cameras are limited, the way to get a HDR image is to take three (or more) images with varying exposure. You take one that is approximately “right” and you take one that is obviously overexposed, and another obviously underexposed. The interesting thing is that these over and under exposed pictures contain additional details that are not present in the “right” picture. Today, March 11, was a bright and sunny day and we decided we had nothing better to do than take a Sunday drive through the countryside. I took a number of such “multiple exposure” photos.

When I home, I downloaded the free trial version of Photomatix from a company called HDR Soft just to try out this HDR process. Does it really work? Does it make photos that are “better” than normal photos. You can be the judge below.

From my point of view, it is “interesting”. An adjective I normally avoid because of its ambiguity. There is no doubt that you can see more in the picture. There are more details. The colors seem to jump out at you, and I have to admit that when I was standing at the original scene, the color were overwhelming. In some sense the result matches an emotional impression. At the same time, the HDR images look fake and unreal. They look like “art” and not “reality”. Is it just that I am so used to seeing photographs with the limitations that normal photography brings?

To appreciate the process, you need to see the three original photos, and then the combined results. Please note, the result is somewhat grainy, which I assume is because I compressed the originals to JPG before combining. The guides say to use RAW of TIFF mode in the camera, and it makes sense because the JPG smoothing will in certain ways distort the actual colors of the pixels, and then when you compare them across three pictures, there ma be some problems. Next time I will try will RAW mode to avoid problems.

Here are the original three pictures.

These are read into Photomatix and combined into a single HDR image. The image looks funny on the screen until you apply a Tone Mapping. The result is an image that can be saved as a JPG file. IT looks like this:

What do you think? THe free version of the software puts the “watermarks” on the photo, so please ignore those until I decide whether this is a worthwhile process. It is certainly an amazing transformation of the photo. You can see the detail in the wooden siding of the barn, while at the same time the sky appears blue. Sometimes I think the colors are a bit too saturated, but then it was a beautiful day which was constantly impressing the eyes with color.

Here is another picture of some houses in Aromas, California:

And here is the combined photo, which clearly shows the sky at the same time as the trees.

Comments?