On 31 Mrz., 22:18, Bart van Andel <
bavanan...@gmail.com> wrote:
> Well, I didn't exactly study the verbose output, but some time ago, I sent
> Michael Norel (the author of Smartblend) a message
He is not precisely verbose ;-) I wrote an email to him last year
asking if he couldn't maybe modify smartblend to process cropped TIFF
format, which nona outputs per default. Smartblend can take x and y
offsets if you carefully handfeed them to it explicitly, but it sure
ignores the information in the TIFF (like many other programs do as
well). It should have been easy for him. Let me quote, while we're
gossiping - here's my mail to him:
Dear Michael!
I have been using smartblend with hugin for a while, and there is one
point where I'd like to see a new feature in your program:
hugin can save the warped files which are to be blended as 'cropped
files'. This saves time and disk space. The cropped files contain the
TIFF tags XPosition and YPosition, which give the offset from (0,0) in
terms of XResolution and YResolution, so to gain the pixel offsets,
one has to multiply the (floating point) Position with the Resolution.
The resulting value is precisely what you expect as -xoff and -yoff
parameters preceding the filename. If your program could recognize
cropped TIFF files, it would become unnecessary to deliberately use
uncropped files in hugin, so that smartblend can blend them.
<...>
I went on a bit about how I worked around the limitations using a
Python wrapper, but I reckon you get my drift. Here's his reply:
Hi
The description of SB psrsms is available, so Hugin can generate this
params for SB.
Thanks.
At least he deemed me worthy of a reply. So I continued using
smartblend with a python wrapper to extract the crop values from the
TIFF and make them into smartblend xoff and yoff parameters, which
saves quite some time compared to using uncropped TIFF. I even wrote
another Python wrapper to use smartblend under wine on Linux, where
smartblend fails because it expects a MSDOS type path (like C:\x\y
\z.tiff) and can't cope with a UNIX type path gracefully, even though
this should take minimal effort.
I finally gave up on smartblend, because I found that over the last
year enblend improved it's seam placement so much that I hardly had a
problem with enblend results any more. Smartblend's static closed-
source status doesn't help much, either.
Kay