TIFF panorama problems investigated

I was surprised by the poor results I got from using TIFF images for my panoramas on Saturday, and today I did yet more investigation. I had thought that I had had two different problems: one where the control point detector is all up in the sky, and one where they appeared to be OK, but the images were rotated. I concentrated on the latter one and found yes, some of the images were rotated, but I also had this up in the sky syndrome on others, where the control points were all in the sky and in the same place on the image, not related to what was represented there:

So possibly it was the control points in the sky issue that caused problems in both panoramas. Clearly it's a bug, but whose? We have the following choices of processing options:

1. Convert the raw image to a portable format, in this case either JPEG or TIFF. I have three different programs that can do this: UFRaw, DxO Optics Pro and Olympus Viewer 2.

2. Detect the control points. Again, there are several possibilities. Normally I use panomatic, but there are also least cpfind and align_image_stack, which come as part of Hugin.

In addition, given the error messages I had seen, I considered the possibility that the EXIF data in the files could be the problem, so I tried variants without the EXIF data.

After a large number of experiments, came out with the results: this particular issue only happens with DxO with 16 bit TIFFs and panomatic. cpfind has no difficulty processing the DxO output. align_image_stack fails to find any control points at all in any of the versions I tried. I gave up on align_image_stack some time ago, mainly because of the slow processing (up to 30 minutes on this particular panorama), but this failure suggests some other problem that I don't want to investigate.

But what causes the errors? Tried again with just the two images above with the control points in the sky. Bingo! They are a perfect match:

The main page claims both average and maximum error of 0.0 pixels. This suggests to me that panomatic is finding something in the images that is identically placed in each of them. And that suggests to me something like a watermark inserted by DxO.

Other programs

The control point detectors weren't the only thing that complained about the DxO output. xv also complained bitterly and at lengthabout both 8 and 16 bit DxO output, but not about the others. nip2, on the other hand, was able to handle the images correctly with only the usual Unknown field messages.

The TIFF errors

Interestingly, none of the image converters produced TIFF files that libtiff liked. The messages themselves leave something to be desired: in particular, the line number at the end of the line appears to be the line number of the command printing it out, which isn't very useful, and the dir at the beginning is in fact the name of the directory and not of the file being processed:

DxO file:

Olympus file:

ufraw file:

It's not clear where these errors are. Amusingly, in the Readme.txt for the Olympus viewer I read:

That's the same library that's complaining here, and Sam is, of course, one of the FreeBSD developers.

Olympus also has the fewest errors, all of which are shared by DxO, and some of which are shared by ufraw (the others are possibly masked by other errors). I suspect that the Olympus errors come from the source file. The errors peculiar to DxO are:

The 8 bit version generated by DxO also generates many error messages:

They include all the errors generated by the 16 bit version, so the messages are probably irrelevant to the problems.

In summary, though, this looks like some problem in DxO that causes problems for some, but not all other programs I try to use to process it.