Re: [PanoTools-devel] Re:PTMender updates

[Jim W. <jwa...@ph...>]

On Tue, May 16, 2006 11:19 pm, Max Lyons said:
> 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.

If memory serves me correctly many functions have already been rewritten from column to
row processing.  PTMender should follow and change to row.


> 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.

We do need a flattened result for the low res quick preview before committing to final
result.  For this case I rather no feathering and blending but having the seams in the
center of the overlap so I can better see the alignment.  So still need to create masks
and flatten.  If we can create a fast method to create feathering that may or may not
blend very well.  Leave the smooth blending to Enblend.


> 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).

Using cropped TIFF end to end would be a tremendous help in speed and memory.

The crashes with PTStitcher that I investigated were the result of a memory allocation
that happened in pano12.dll and then was freed in PTStitcher.  If both are compiled with
the same libraries there would not be a problem.  But that can not always be controlled.
 What I propose is to add a function to pano12.dll to free memory that it allocated. 
The function in question was the one that reads the script file and passed back a
pointer to a char array.  There may be others.  This is the one thing I was hoping to
add even since a replacement to PTStitcher was started.


Jim Watters