The Windows Port Continues…
In spite of my current workload and the holiday season, I was finally able to get most of my Imaging library ported to Windows XP. I was able to read and write a BMP file using a plug-in. I tried to use a TIFF plug-in, but it failed in a strange way. More work is necessary.
Update:
I discovered the problem. My OSFileHandle resource code used to support a global reference counting mechanism so that, when a FileHandle is assigned to another FileHandle, where both would now point to the same opened file via the same shared OSFileHandle, a race condition, where the destruction of either of the FileHandles would cause the second destructor to crash, could be avoided. Instead of reimplementing such a scheme, a scheme that was hardly foolproof, I instead implemented a poor man’s reference counting mechanism. Essentially, the FileHandle now has a bool member called isShadow. If a FileHandle is used to open a file, then isShadow is false. If a FileHandle is assigned from another FileHandle, then that second FileHandle is a shadow, isShadow is set to true. When a shadow FileHandle is destroyed, it does not close the file. Only the original FileHandle can do that.
Admittedly, it’s a bit of a hack. For what it’s worth, FileHandles should not be assigned and/or shared because of the aforementioned race condition. In a multitasking program, the condition becomes even more likely. However, my TiffReader class contains a FileHandle member for convenience purposes. TiffReader is constructed via an already opened FileHandle and this handle is copied and used internally for all TIFF file I/O. In this case, a shadow reference is good enough.
So, after solving that particular problem, I rediscovered the original reason behind my rewrite of PixelFormat and PaletteFormat et al. I read in a TIFF file and wrote out a BMP file. And, lo and behold, the red and blue channels were reversed. This occurred because my TIFF reader reads data in RGB order and BMP requires BGR order. With the rewrite in place, however, my BMP plug-in was able to detect the RGB8i (i = interleaved) instead of the expected RGB8ri (ri = reverse interleaved) and called img.StoreXformPlaneData(handle, 0, 0xABCCBA) instead of img.StorePlaneData(handle).
What is StoreXformPlaneData()? Well, that function takes each image scan line (or pixel row) and rearranges the data based on some integer value. The hexadecimal representation of that value is a clue as to how it works. 0xABCCBA is the value to switch the 1st and 3rd values in a trinary color format pixel. With that transform in place, I was able to correctly convert the TIFF file to a BMP file.