Looking for code in enblend to handle 8 bit and 16 bit images

[Terry Duell]

Hello All,
I thought I'd have a look at hugin bug #679094 "nona won't stitch mixed 8
bit and 16 bit TIFF".
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".
I have been searching through the enblend revisions and thus far not found
anything.
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?

Cheers,
--
Regards,
Terry Duell

[cspiel]

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

[Terry Duell]

Hello Chris,

On Mon, 23 Sep 2013 17:53:12 +1000, cspiel <csp...@freenet.de> wrote:

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

Thanks for the explanation, it is now clear why the suggested fix (comment
#3) hasn't been implemented.

[John Eklund]

 
On Monday, September 23, 2013 9:53:12 AM UTC+2, cspiel wrote:

Terry,

        There is nothing.  In fact we
intentionally reject

(c) different (ICC) color profiles.

On a side note - I hope they will continue to allow sets of images where some have a single ICC profile and some lack profile (assuming the profile present in some images). Some of my preprocessing washes color profiles and most metadata away and I usually stitch images that either have sRGB or lack ICC information and am fine with getting the warning message. I just hope the message is not a first step towards outlawing it altogether. That would make everything unnecessarily complicated. Just sayin'. :-)
 
/John

http://www.elmuseum.se/panorama/panorama.html?pano=gasklocka4_1.xml