Hello Josh,

Pano2Movie only uses one core. This mostly because of limitations in the development environment that it's written in, and re-writing it in something else would cost more in time than the potential increase in sales. :-(

Ian

Ian:

Just found your software. I suppose regular update posts to MacUpdate.com would have made your application more visible to people like yours truly? : )

The Mac community has an awful lot of professionals (like me). Almost al of us use as many processors as we can afford. This is especially for those who might shoot VR/Panos, and who would use them in this fashion. I understand the time commitment is not something to be taken lightly, but you would be in a class all your own, in terms of stand-alone tech.

Your comment about your work brining this to MP support, vs.potential sales increases, may be incorrect. I've been on the Mac (exclusively) for 25 years now. Iv'e owned more than 50 machines myself. I've seen 'em come and go. One of the biggest mistakes people often make in this community is to judge sales based on the whole community of users, and to ignore fact that professionals (who use this sort of technology), may make up a smaller percentage, but we do spend 10-100 times more money than the average consumer.

Certainly the limitation of the utilization of only a single processor is a real issue for people like me. I am the kind of person that might be be producing many of these sorts of sequences per day, and waiting around is not an option.

Another suggestion – since you're already an Aperture developer – is to port this to Aperture as well. Although your application is not the only thing out there to take VR Panos to movies, a port to an Aperture plugin would place it as the only (current) option of its kind within the Aperture environment.

So, my suggestions:

1) Develop and announce MP support (you'd get another listing in MacUpdate, which means more buyers)

2) Develop an Aperture plugin . . . before someone else does.

If you decide to take either course, let me know and I'll buy a license immediately just to show support. (I am likely to buy one anyway, but I'll certainly tell a good half dozen people who will follow my lead. This is how it works in this community)

I am also an excellent beta resource, and have been testing various wares since 1968 . . . starting with Adobe PS version 0.86b!

BTW, another suggestion: 3) Add support for Pano-to-movie using HDRI panos (the film industry of which I am a part – would really take to that for advanced pseudo-3D matte moves)

Best of luck, Dorian

Hello Dorian,

Thanks for the post!

The main issue is that I'm only a part-time developer - I'm primarily a photographer who started writing software tools to help me out. As a self-taught programmer http://runrev.com is what I use to develop Pano2Movie and Aperture Assistant.

Runrev is a fantastic environment to program in, but it has some hard limitations and multi-processor support is one of them.

At this point in time, adding MP support (or an Aperture plug-in) wouldn't be a case of writing some new code, it would require moving to a totally different development environment and learning new programming languages - and C/C++/Obj-C which would be required for an Aperture plug-in take months to learn to the degree that I'd need. Plus anything in Obj-C is Mac-specific, when most of the Pano2Movie customers are Windows-based.

Pano2Movie is in sore need of some updating, but it'll have to wait until Aperture Assistant has been re-written to work with Aperture 3, this means that August is likely to be the soonest I can look at Pano2Movie. :-( The positive side is that I may be able to replace Pano2Movie's reliance on QTVR playback and instead use a 3D environment to show the panoramas and generate frames - this is the section which is slow and single-processor-bound due to the slowness/poor anti-aliasing of QTVR display within QuickTime. Turning the image sequence into a QT movie isn't so bad, and as you may have spotted the QT compression stage is actually multi-processor-aware as it's done using a third-party add-on.

Ian

P.S. HDR panos - presumably this would involve bringing in an HDR source image, what kind of output file would that require? Something tone-mapped or would you be needing to keep the full range?

Ian

Ian:

I think that the flow' for this work could remain in the domain if using already mapped images (I use the new Photomatix plug-in for Aperture), and simply select or stack these, and then employ your application as plug-in. I can't think of many environments (with the exception of 3D animation, where HDRI images are used) where Panos and HDRI come together (as in the importation of a single large spherical image as an image map) in one place. Of course this is certainly another example of a potential market where the first solution might remain the top solution. After all, name recognition and happy users means potential future sales.