enfuse sees a "grayscale" image where there is not

[Yuv]

I am processing three exposures of a large panorama. This is in the area where the scene is brightest and so the highest exposure is completely white. When blindly fusing each stack, the stacks with the white images return the error message:

$ enfuse --contrast-weight=1 --output=_MG_7849_hq-_MG_7851_hq.jpg _MG_7849_hq.JPG _MG_7850_hq.JPG _MG_7851_hq.JPG
enfuse: info: input image "_MG_7849_hq.JPG" does not have an alpha channel;
enfuse: info: assuming all pixels should contribute to the final image
enfuse: info: input image "_MG_7850_hq.JPG" does not have an alpha channel;
enfuse: info: assuming all pixels should contribute to the final image
enfuse: info: input image "_MG_7851_hq.JPG" does not have an alpha channel;
enfuse: info: assuming all pixels should contribute to the final image
enfuse: input image "_MG_7851_hq.JPG" is grayscale
enfuse: but previous images are color

expected behavior: fuse the images (and let the weightings take care of the over exposure)

[Bruno Postle (brunopostle)]

In your testcase _MG_7851_hq.JPG really is grayscale and the other two are RGB, so the error message is correct.

Were these images processed by ImageMagick? This is one of the annoyances of ImageMagick, it will collapse the data to a different format if it thinks it can save space - I have never been able to turn this behaviour off.

I think it would be nice if enblend was able to dynamically deal with this situation and do the right thing automatically, though this isn't a problem for Hugin which will always supply a unified format to enblend.

[Yuv (yuv)]

On May 8, 2011 04:29:43 PM Bruno Postle wrote:
> In your testcase _MG_7851_hq.JPG really is grayscale and the other two
> are RGB, so the error message is correct.

*blush*. I thought there was no such thing as grayscale with jpeg compression.

> Were these images processed by ImageMagick?

yes, ImageMagick is the culprit in the chain. And this same image that caused
what i mistakenly reported to bug 717944, and that crashes both cpfind and
panomatic. I'll do some more investigations and file a report on those
crashes later.

> This is one of the
> annoyances of ImageMagick, it will collapse the data to a different
> format if it thinks it can save space - I have never been able to turn
> this behaviour off.

I found that with PNG it can be forced with something like PNG32:output.png
but have not used it yet, and in this case I was using JPEG.