Enblend cannot blend images with different bit-depth.

[Tim David]

enblend: input image "test0002.tif" has pixel type UINT16,
enblend: but previous images have pixel type UINT8
make: *** [test.png] Error 1

Current version 2010.2.0.d8ce0ba947cc (downloaded today) no previous versions installed. (Help>About >System is not a valid menu option)
Windows 7 Pro 32 Bit

stitching of two images worked OK, but when the third was added get the error.

[Yuv (yuv)]

Thank you for reporting the error. From the error message it seems that your previous images are 8bits and the one you're trying to add is 16bits.

The solution for you is to either upsample the 8bits pitures to 16bits or to downsample the 16bits picture to 8bit.

I'm converting this to a feature request for enblend to blend images of different color depths.

[Christoph Spiel (cspiel)]

First if all, this is one of the most stupid and thus misleading
bug-report titles I've seen for a long time! What about:
"Cannot blend images with different bit depth"?

- The input image's bit depth is so deeply encoded in both Enblend
  and Enfuse that it would be very hard to extend their functionality
  to accepting images with different bit depths.

- Above, Yuv already has outlined a possible workaround.

- Changeset d8a85b28263f extends the documentation with
  "Input Image Requirements". There, the problem of different
  bit depths is explained.

[Tim David (talltim)]

Thanks for the polite comment. At the time of logging I didn't know it was caused by different bit depth so it would have been a bit hard to title it so. The images being blended are temporary images so I don't actually see that it is misleading a title.
As you say, Yuv has outlined a workaround and I have used it. Yuv and you have decided its not important to fix, and I don't have a problem with that, although possibly the error message could be made more friendly.
Actually, after I logged I saw that it was a duplicate of a previous bug report, so I could understand if you picked me up on that, but you haven't. I had searched before logging, but obviously didn't use the right terms.

[rew (r-e-wolff)]

Question:

Downscaling would lose data, upscaling the 8-bit image to 16-bit would be the right thing to do.

The little I have been able to look at the code, wouldn't it be possible to easily upscale the images that have a lower bit-depth? Just allocate a new image object of the right size, and copy over all the pixels? (there are two cases. The current one is 16-bit, and the previous ones are 16-bit. In that case you'd have to upscale the current working set. Or if we're already working in 16-bit we'd have to "upgrade" the image as it is loaded....) If upgrading the "working set" is difficult, a quick scan over the images to determine their bid-depth would require only the case of loading 8bit data into a 16-bit ('higer bid-depth') datastructure....

[Yuv (yuv)]

@Tim: I did not "decide that it is not important to fix". What I did is set it to "Wishlist" because it is a feature request (i.e. requires adding new functionality) and not a bug: the code behaves as intended.

@Christoph: Thank you for explaining to laymen like me how the image's bit depth is encoded in Enblend and Enfuse and how hard it would be to add the requested new functionality into the tools. Also extending the documentation, explaining to users what the input image requirements are is a good step in the right direction.

My apology for not updating the report summary when triaging it. Calling it "stupid" is not helpful.

@Rogier: have you considered the consequences of both up and down scaling in terms of artifacts and other unintended consequences? You are welcome to fiddle with the code and provide a patch that upscales the images prior to processing if needed. Personally I would:

1. make the error message more user-friendly, by adding a suggested resolution, i.e.

enblend: input image "test0002.tif" has pixel type UINT16,
enblend: but previous images have pixel type UINT8
enblend: convert all input images to the same bit depth with a tool like ImageMagick and try again.

2. contribute a wrapper shell script. Unfortunately my script would not help Windows users since it would be a shell script. The commands to use are:

 identify -verbose ${SOURCE_IMG} | grep Depth:
...
 convert ${SOURCE_IMG} -depth 16 ${TMP_IMG}
...
 enblend -o result ${TMP_IMG}

3. Because most images fed into Enblend do fulfill the input image requirements outlined in the documentation, I would *not* add the dependency on ImageMagick to the Enblend distribution, hence the script would just be a "contributed" thing, not part of Enblend itself.

I don't really have the need to do this for myself, but if there is enough request I can see if I find a little moment of spare time to put together such a script.

[Bruno Postle (brunopostle)]

There is a nona -p parameter that can be used to specify the bitdepth of the output.

If this still works as advertised, then it should be possible for Hugin to identify that the project has a mixture of 8bit and 16bit photos and force 16bit output for all the images that are then fed into enblend.