• Subscribe

    Subscribe to This Week In Panospace by eMail.
    Subscribe in a reader
  • License

    Creative Commons License
    This work is © 2008-2012
    by Yuval Levy
    and licensed under a
    Creative Commons License.
  • Entries

    October 2008
    M T W T F S S
    « Sep   Nov »
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
  • Archives

The Most Beautiful Smile In The World

You will forgive me if I state so bluntly that to me this is the most beautiful smile in the world. It was worth it to spend some money on a really good camcorder.

Unfortunately, support of the AVCHD movie file format is still mostly lacking in Linux. For simple playback, none of the usual media players available in Ubuntu seems to work at the time of writing. For editing, there are workarounds, but I end up fiddling too long with conversions and not enough with the actual editing. Video editing is a time intensive task. You want the most comfortable, intuitive, easy and fast to use software. Real time editing must be fluid when cutting and fading. Rendering of the final movie can happen overnight, so speed is not critical there.

I did not like the software that came with the camcorder. I’ve tried a few budget products and the most usable one I found was from SONY. Quite hard to swallow given my intense allergy to the brand and its proprietary shenanigans. But in the end, pragmatism wins, especially when time flies and the parents overseas want to see the offspring growing.

Hugin Usage: Poll

WordPress.com has this new feature, polls, and I was eager to try it out. So here is a poll.

The poll functionality is nice. Basic integration into WordPress is flawless, but will take the whole colum width. Wrapping the poll tag in a styled div tag, with style float:left;padding:3px, makes the visual integration more pleasant, as in this post.

I’ll let the poll run for a few weeks. I am eager to see what happens when a poll close. I might as well start a new poll for that, because the question in this poll is kind of an open ended one.

Windows Installer

Three weeks after the release of Hugin 0.7.0 a binary installer is available on Sourceforge. Why such a delay?

Somebody with the necessary skills only needs a few hours for the task, and somebody with the will to learn them maybe a couple of (part time) days more. I offered to coach whoever steps up to the challenge, but I refused to do it myself because I believe in proper succession planning and in the need to groom the next generation of contributors.

Succession planning means making provisions for the future. For what will happens after we’ve left. Because we all leave, sooner or later.

For an Open Source project to survive beyond the current generation of contributors, the project needs two things: know-how transfer and a pool of new potential contributors to step up to the task.

Know-how transfer comes from the people who currently hold the know-how. It comes in the form of documentation. In Hugin’s case, I’ve made a push over the past year and with the help of many community contributors we got the build process documented, also for Windows. And for the installer, I’ve committed the instructions into SVN. We are ready for know how transfer. Are you ready?

Potential contributors… that’s you! Yes you, don’t turn your head the other way. The tools required are available as a free download, and the instructions are simple enough for any literate person that can type on a keyboard, click on a mouse, and has access to a PC with 2GB RAM – about what it takes to stitch a full spherical panorama. There are no excuses. If you feel the windows installer was delayed, look in the mirror.

In the end, two people that were already contributing to the project stepped up to the task. I could transfer the know-how to Tom Sharpless and Guido Kohlmeyer. Eventually Guido’s installer made it to the official repository.

I am disappointed. Of more than 35.000 Windows users who have downloaded and installed my hugin installers from this site over the past ten months nobody had the decency to step in and contribute something back to the project?

What Goes Around Comes Around

Zoran Mesec joined the hugin community in 2007. He applied to our Google Summer of Code initiative and went on to successfully complete matchpoint. The code is still experimental and is distributed with hugin.

In 2008, Zoran gave back a little of the mentoring and love that he received from the community. He mentored Marko Kuder, a fellow university student, on the batch processor project. And he joined other community activities as well, using the Mrotator U panoramic head sponsored by Agnos Engineering for his Summer of Code participation to contribute to the World Wide Panorama for the first time.

Zoran, together with long time panotools maintainer and community contributor Bruno Postle will represent our team at the Google Summer of Code mentor summit.

I enjoyed the experience a lot last year. I hope the panorama from last year will be repeated this year and become a tradition.

Exposures Stacks

Stacking…

An exposure stack is a series of completely overlapping images at different exposures to capture a wider dynamic range beyond the limit of the sampling sensor.

Ideally they are fully overlapping (e.g. shot from a tripod) and the subject is static. For less than ideal conditions, hugin’s align_image_stack can correct for small perspective changes (e.g. hand held shots) and deghosting software such as the experimental hugin_hdrmerge from Jing Jin’s Google Summer of Code 2007 project can partially correct for scene movement.

There are a number of ways to merge a stack into a single image:

  • Exposure Blending: many photographers load the stacked images into layers and use masks to manually reveal details from the appropriate layer, in Photoshop, Gimp, or any image editor that supports layers This is often used for manual deghosting as well.
  • Exposure Fusion: For almost a year now photographers had access to completely automated exposure fusion with Andrew Mihal’s Enfuse.
  • HDR/Tonemapping with tools like Qtpfsgui or Photomatix has been around for some years. While the merging of an HDR image under ideal conditions is straight forward, the tone mapping step can be computationally intensive and require human judgment/intervention, which makes the process more time consuming than exposure fusion.

… and Stitching…

Stitching is the two steps process of aligning partially overlapping images in space and blending them into a single, bigger picture.

Combined!

The combination of stitching and stacking is now done inside hugin automatically. Select the desired type of output (enfused panorama for exposure fusion, or HDR panorama) and let the magic happen. Sometimes the artist wants more control over the process, e.g. to mask out which of two overlapping images will show in the stitched panorama.

There are basically two ways to control manually the rendering of a stacked panorama: stack and stitch, or stitch and stack. The result is nearly the same:

Stitching and Stacking…

In the past, the general recommendation was to stitch first. This was before Pablo d’Angelo implemented photometric adjustment in hugin and before Andrew Mihal gave us with enfuse an easy exposure blending tool.

The rationale:

  • keep the color balance constant
  • optimize alignment
  • set the stage for manual deghosting across blending seams

Keeping color space constant is no longer an issue, thanks to hugin’s photometric adjustment and end-to-end HDR stitching. Enfuse is anyway not affected as it choice of pixel weight is independent of color balance. And for optimal alignment, in most cases the results of align_image_stack are better than the alternatives. Masking / deghosting can be indeed easier on a stitched panorama.

Stitching first presents the artists with a few pitfalls / disadvantages:

  • The stitched layers must be aligned. The classic way to achieve this is to stitch a single layer and then use it as a template to stitch the rest.
  • Blending seams within each layer may be different, resulting in visible artefacts.
  • A stitching before stacking process is generally slower than a stacking before stitching process.
  • Not all tools can handle seams in the stack – specifically enfuse and enblend do not handle well nadir and zenit seams (and the top and bottom edge of an equirectangular image are just that). Qtpfsgui does not handle well the 360° deam (the left and right edge of a 360° image).

Or Stacking and Stitching?

So we can stack and stitch. Running the stacks through the stacking process can be automated, for example with Erik Krause’s droplets (for Windows only) that pass an entire folder or a selection of images through hugin_align_image_stack and enfuse, or with hugin_hdrmerge if we want to stack HDR.

In many cases, stacking before stitching will yield acceptable results, even if the smaller image surface will allow for a smaller number of levels while blending / fusing. It will sure yield a shorter processing time.

Conclusion

As a VR artist, both processes have their place in my toolbox. I use stacking and stitching when I know I want simple, photorealistic results. Then I stack the images with enfuse (align_image_stack optional) before stitching. When I want to play with the tone mapping, I either stitch first then compose to HDR, or I let Hugin compose the HDR right from the input images in a single step. Deghosting and Masking can be applied on the input images, on the stacks, and on the stitches, as needed.

Hugin 0.7.0 released!

Hugin 0.7.0 has been finally released! This brings to an end a long development cycle of two years. Hopefully the next one wont be that long. The download page of this site has been updated.

There may still be bug fixes in the 0.7 series. As far as I am concerned, the little spare time I have will be devoted to the next 0.8 series whose goal is to integrate the Google Summer of Code 2008 projects. News will follow here in due time.

World Wide Panorama – Color

The latest World Wide Panorama event is online. Over 200 interpretations on the subject of Color, worldwide.

The organizers had to cope with some change lately and more change will come as they set up a foundation to continue the endeavor after professor G. Don Bain’s retirement from Berkeley.

My entry is a plain simple family panorama, colorfully processed in qtpfsgui. I’ll expand on the process in coming articles on this blog. Click on the image below to interact with it full screen. Unfortunately the WWP site still lacks a feedback / comments facility. Post your comments here. Love it or hate it, I’d like to read from you.

The entry can also be seen in its intended context. on the World Wide Panorama site. You’ll find that the panorama in the entry is smaller than most. Here is why.

At the time of writing the World Wide Panorama makes provisions for two sizes. The limits have been gracefully expanded lately to accommodate for the technological evolution – at least for part of it. Both formats are still geared at desktop and laptop PCs, with ever growing display resolution and bandwidth. The allowance for full-screen panoramas has been gracefully increased to 5MB, while the one for what the WWP site calls “standard size” has been increased to up to 1MB.

Technically, 1MB is a little bit tight for my process. It isOK for my “standard size” panoramas from traditional images. But tone mapped panoramas from stacked images have more detail and compress less – my file was 1.3MB and did not pass the upload limit.

Moreover, many tone mapping operators (TMO) including the one used for this entry produce different results at different output size. Scaling the results using conventional scaling algorithms does not do justice to them. Producing the required size would have meant manual work for which I don’t have much time at the moment.

I might consider adding an intermediate size in my process later on. The trade-off is more computing and storage needs. I am not sure about my interest in supporting such an intermediate format, though. I am a fervent believer that interactive panoramas are best viewed full screen. I’ll do less than full screen if a customer asks for, but when I am exhibiting my artwork, I want it full screen.

5MB is a good size for full screen panoramas to be displayed on current high resolution computer displays and FullHD TV (1920 horizontal pixels).

1MB is too small for that and too big for the mobile web where display size is more typically 640px and less, and where bandwidth is still at a premium, making 1MB too much.

Since the WWP entry requires a “standard size” VR with less than 1MB (recommended 700Kb) weight, I’ve used my cellphone size to complete the entry.

Qtpfsgui needs you

Qtpfsgui is Giuseppe Rota’s brainchild. It is a graphic user interface (GUI) to pfstools( PFS), a set of powerful HDR/Tonemapping tools developed and maintained as an Open Source project by Grzegorz Krawczyk and Rafal Mantiuk, using the Qt Toolkit (QT).

The acronyms explain the tongue-breaking name for the software. Giuseppe is still looking for alternative name proposals. But more than that, he is looking for HELP!

When he started the project, he was still a student with enough time at hand. Now he is a busy professional and the software needs a new maintainer. And it needs any contribution it can get.

I started writing tutorials for the different pfstools tone mapping operators (TMO) that QTpfsgui makes available, but bumped into serious difficulties. With small images, things were right most of the time. But with large images pushing the limits the results sometimes did not look right. I filed a few bug reports. I dug deeper and found out that the PFS tools are actually working as expected when called from the command line. What can cause such an interaction between the GUI code and the functional code which in itself works? and what can be done?