MapInfo Pro

I'm trying to use previously registered images from historic maps that aren't displaying properly within v17!? Wanted to see if anyone else had come across this issue, or if there is an option I'm not aware of that I need to select.

Attached are examples of the images form v17 & v15 (32bit). There is a clear distortion with v17, but I can't work out why it's happened. Both images have been taken when the same image is open in both versions simultaneously.

I'm hoping there is a simple fix as I don't want to have to reregister several thousands of rasters! Does this issue have anything to do with the .GHX or .PPRC files that are created when opening the raster image in v17?!

It looks like a bug in the TIFF driver. Can you post one of these files so I can take a look at it? Alternatively just email one to me or send me a link - sam.roberts@pb.com

In the meantime you can disable support for TIFF files in the new raster handler (via Preferences) and it will fall back to the old TIFF driver used in version 15.

@Sam Roberts​ I've attached the TIF and the associated files (just in case). Hopefully it will tell you whats happened. If this means having to make changes on our side, so be it. I would rather keep these up to date for future versions as the majority of what we use will be historic raster images like this (as long as it doesn't involve having to recreate the individual images!).

I have created an issue in our bug tracking database for this (MIRAST-16423). I will make a minimal change to the native TIFF driver code to fix the issue in this particular case.

The problem arises because TIFF files can change the order in which bits are stored in a byte. The designers of the TIFF format did this to make sure it is as difficult as possible to correctly read the files.

Our driver knows about this and reverses the bit order when required. In this case, the bits do need reversing (this TIFF file is unusual in a number of ways). However, this results in the wrong outcome and re-reading the TIFF library documentation carefully implies that we should not have to manually reverse the bits because the library function we call is doing it for us. But we added the code to reverse the bits because other customers files were not working, so there must be scenarios in which the TIFF library does not do the right thing and we need to do it in our driver. Clearly, this is not one of those scenarios. The question for me is - what are the scenarios in which our driver has to intervene? This will require research.

In the meantime I will make a change that makes it work for your files, assuming they all have the same structure as the one you supplied. This will go into the version 17 patch for December release.

That's great thanks Sam. I'm happy to send other samples if required, alternatively is there anything I can be on the lookout for to make sure this will provide the correct fix in 17.0.2?