19.4.08

Computation.

All of the images Im making rely heavily on post capture processing to turn them into what i want. These computational overheads add significantly to the time it takes to create an image but represent more than anything what Im trying to achieve. The current workflow runs something like this;

1. Convert the camera .raws into small .jpgs using the generic settings within Adobe Camera Raw.
2. Organize the images into their row, then layer. The row is all the images from one set of full movements in one axis. The layer is how many images to create on whole image in focus
3. Feed the layers into one of a few image stacking programs. This part can take some time. As each image can need a fair bit of optimization. save this output.
4. Feed these outputs into either Photoshop Photo-merge or Autopano Pro. If the images/data are decent then photoshop can stitch out a test image in a few hours but any major gaps or serious mall alignments lead to a massive increase in compute time.

Autopano offers the fastest most controllable output but responds really badly to images sets with missing images by warping the entire image. But when all the data is there, it produces great outputs. Photomerge is stupidly slow but seems to be able to ignore missing images. Mostly the missing images are a result of my lack luster capture process - this should/will improve greatly with the use of a scanning back. I also tried Realviz Stitcher,I used this extensively for early panoramic experiments where it performs brilliantly but when faced with images that cover a large planar field of view it fails. I’m not really sure why but in the face of autopano i gave up trying to optimize it.
This is the last test I intend to do with a DSLR as the capture unit. It highlights nearly every problem! The lack of any uniformity reveals the fact that it was created with small images over a long period of time. In this case when I started it was a rainy day and by the time I had finished it was sunny. This has been less pronounced in previous images as they have been shot in environments with mainly continuous lighting. Although most of this could be edited out, I feel that that is outside of this project. Most of the image is 'in focus' but there are chunks and gaps. These relate to the repeatability issue and are exacerbated by small movements in the camera (of all the things the floor bowed under the weight of the camera). The dark square effect is caused by the minimal amount of image available to overlap. This test also revealed an entirely new problem that only really occurs with stacked images. This problem arises from an optical effect. By 'shifting' the back standard of the 4x5 camera I move the sensor over the lens projection. At the extreme end of a movement there is more image being projected but the sensor cannot move anymore. In these situations I 'shift' the front standard to move the image over the sensor. In the case of early composites this has never manifested itself as a problem as the image has been at a single focal plane. But with the images being stacked, these slight changes become parallax errors that make it impossible to overlay multiple focused images accurately. This phenomena was greatly enhanced by the fact that what I was focusing on was very close. It might well be possible to get away with it in an image if the plane of focus is shallower. This will reduce the total number of images used to make a composite, unless I can find a way to extend the rear movement. I should have really known about this before it happened as it was a major problem in my early panoramics. That said, I really like this failure image. It embodies a lot of what im trying to say.
The software I have settled on to perform the image stacking is Helicon Focus. Although i have tested a few, this program offers a good range of possibilities in manipulating the image. Also it supports a batch render function (only under Windows, unfortunately). This use of the software really stretches the algorithms used to blend the layers of different focal planes, mainly as its all optimized for macro work. Obviously if all this testing works, i go back to the .raw's and give them a full workover and repeat the process with greater attention to the details.

No comments: