Terry,
On Monday, September 23, 2013 6:35:47 AM UTC+2, Tduell wrote:
> I thought I'd have a look at hugin bug #679094
> "nona won't stitch mixed 8 bit and 16 bit
> TIFF".
Neither Enblend nor Enfuse accept "mixed
input". E.g.
enfuse: input image "remapped-0001.tif" has pixel type UINT16,
enfuse: but previous images have pixel type UINT8
> Comment #3 on this bug (2009-10-01), notes
> "...the problem is solved in the new
> enblend. Probably not a big effort to 'copy &
> past' the code from there to nona".
Maybe the author of comment #3 confused
it with an actual improvement in Enblend and
Enfuse, which has to do with pixel depth, but
addresses a different problem. New Enblend and
Enfuse always keep the bit depth as high as
possible for any combination of input and output
bit depths, whether default output bit depth or
user-requested output bit depth (option `--depth').
> I have been searching through the enblend
> revisions and thus far not found anything.
There is nothing. In fact we
intentionally reject
(a) different channel numbers,
i.e. black-and-white and color,
(b) differing bit depths, and finally
(c) different (ICC) color profiles.
Check out files "enblend.cc" and "enfuse.cc" and
grep for the comment
// Second and later images
The restrictions all serve either to avoid a
combinatorial explosion of the code or to force
a reasonable decision upon the user. For
example, we do not want to decide whether to
prefer an AdobeRGB profile to an AppleRGB one or
to transform (which rendering intent, BTW?) to e.g.
WideGamutRGB, which is "larger" than both. I
suspect that we could drop some of these
restrictions more easily than others.
> Can anyone who knows their way around the
> enblend code, or has a good memory, point me
> to the revision in question, or where, in the
> source, I should start looking?
In file "assemble.h" you'll find
function import(). It will give you a first
hint as it is solely templated by output types.
The variance of input formats has already been
partially absorbed.
template <typename DestIterator, typename DestAccessor,
typename AlphaIterator, typename AlphaAccessor>
void
import(const vigra::ImageImportInfo& info,
const std::pair<DestIterator, DestAccessor>& image,
const std::pair<AlphaIterator, AlphaAccessor>& alpha)
Until then ImageMagick(1) or GraphicsMagic(1) are our
dear friends as Bruno suggested in comment #1.
HTH,
Chris
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/5b4fa29a-191e-43a9-8cbd-672b22bb8133%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
