> One thing that will greatly simplify PTmender is to encapsulate access
> to the pixels via a macro or a function. Unfortunately PTmender (and
> this is inherited from PTstitcher) uses a pointer to the area of
> interest and then increment this pointer as needed. This approach has
> one two majors problems: it requires a lot of memory for large
> panoramas (such as 360-180 in which most areas are black), and it
> promotes cloning of code (one for each resolution/type).
>...If we think in terms of
> memory usage this extra cost will probably be worth it if we avoid
> memory swapping. I think it is worth pursuing, but I'd like to hear
> opinions, alternatives before we make major changes.
The main pixel remapping routine (MyTransform) works on arbitrarily sized
regions of each input image. As such, it is very memory efficient. As you
note, the routines to do the blending, masking, alpha channel creation (and
perhaps feathering) are less efficient, requiring each remapped image to be
held in memory. I agree that there are probably more efficient ways to do
these things. Because the TIFF files used by Pano Tools are written in strips,
they can be quite easily processed one row at a time. However, at least some
of the routines in PTStitcher/PTMender operate one column at a time (see
ComputeStitchingMask8bits, for example). To read a TIFF file one column at a
time will involve an awful lot of disk I/O.
In any case, I'm not sure how important it is to enhance all these routines.
For me, at least, and I suspect many others, tiff_m output is really the most
important format as it can be fed into Enblend or other blending software.
And, this is the simplest format to generate. It is already working. So, I
agree with your conclusion that adding feathering and support for other formats
might be nice, and would be required for a complete replacement for PTStitcher,
but probably not crucial.
> Max> covered by each input file) for other formats as well.
> Max> For example, PTMender could use tiff_m as the intermediate
> Max> format for flattened JPG output. The code
> This is actually the way it currently works. PTmender creates first
> tiff_m and then flattens them for either PSD or JPG output (or other
> It actually needs to be done in all the steps. This is the actual
> process to generate a JPG:
> * Create TIFF_m of the mapped photographs (creates one TIFF per image)
> * Compute Stitching Masks (creates two TIFFs per image, deletes 2
> tiffs/per image, including the ones from
> the previous step)
> * Feather (creates one TIFF per image, deletes one
> from previous step)
> * Flatten (deletes all previous TIFFs, generates one)
> At this point we have only one TIFF
> * Convert this TIFF to whatever format is required (like JPG), delete
> original TIFF if no longer required.
Right. What I had meant to say that it would be possible to modify PTMender to
use cropped TIFFs as the intermediate format, rather than full-size TIFFs.
It should be possible to rework the functions above to work with cropped TIFF
files and just "pad" the intermediate cropped TIFF files as needed. For
example, the other "important" formats (from my point of view, of course) are
flattened JPG and layered PSD. When writing flattened JPG files this would be
during the blending stage (BlendLayers8Bit), and for layered PSD format this
would be in the functions that write the PSD file (writeChannelData in file.c
would be the most likely candidate).
I believe that working with cropped TIFF_m as the intermediate format would
produce the most "bang for the buck" in terms of improving speed, reducing
memory and storage requirements and would probably solve 90% of all the
problems people have with crashes in PTStitcher (frequently as a result of
running out of memory when trying to generate layered PSD files).
You asked in another thread if "it be possible
to modify Enblend to output different layers (when no color correction
is requested)". I've written my own blending software based on the same multi-
resolution splining algorithm used in Enblend, and can say that the answer is
no. The multi-resolution splining algorithm doesn't adjust the colors or
brightness in individual layers...it decomposes overlapping images into
frequency bands, blends those, and then reconstitutes a final image by adding
the blended frequency bands. As such, there isn't really any adjustment to the
original layers. the Burt/Adelson paper explains all of this quite nicely.
Having said this, I find that it is usually possible to produce a blended
output image, and if there is a need for correction, I just layer the unblended
layers on top of the blended output in Photoshop and manually fix any problem
Lastly...thanks for all the hard work on PTMender. After years of being
"stuck" with PTStitcher.exe, but no corresponding source code, it is a real
pleasure to be able to work on this project. If Helmut Dersch is reading, I
hope he is able to take some satisfaction from the continued evolution of his