This project is read-only.

GridColorScheme not working on int data types

May 6, 2015 at 3:37 PM
Edited May 6, 2015 at 3:37 PM
I've recently upgraded from 4.8.3 to 4.9.0. The code that I had previously to display a grid using a GridColorScheme has stopped working on integer (unsigned 8 bit) but if I convert the tif to a float (32) it will work.

A stripped down version of my code:
Dim img As New MapWinGIS.Image
        Dim fname_float32 As String = "Z:\asb\HavasuNWR\DSS_Tools\HavasuDSS\InitialData\DefaultSessionDirectoryWorkingCopy\Outputs\Segments\Topock_1\topock1_ycra_breeding_138.600_compressed_float.tif"
        Dim fname_unsignedint8 As String = "Z:\asb\HavasuNWR\DSS_Tools\HavasuDSS\InitialData\DefaultSessionDirectoryWorkingCopy\Outputs\Segments\Topock_1\topock1_ycra_breeding_138.600_compressed.tif"
        img.Open(fname_float32, MapWinGIS.ImageType.USE_FILE_EXTENSION, False, )

        img.UseTransparencyColor = True
        'imgInfo.image.TransparencyColor = Convert.ToUInt32(RGB(0, 0, 0))
        img.UpsamplingMode = MapWinGIS.tkInterpolationMode.imNone
        img.DownsamplingMode = MapWinGIS.tkInterpolationMode.imNone
        img.AllowHillshade = False

        Dim colorScheme As New MapWinGIS.GridColorScheme
        Dim r As UInt32 = Convert.ToUInt32(RGB(255, 0, 0))
        Dim g As UInt32 = Convert.ToUInt32(RGB(0, 255, 0))

        Dim breakr As New MapWinGIS.GridColorBreak
        breakr.LowValue = -1
        breakr.HighValue = 50
        breakr.LowColor = r
        breakr.HighColor = r
        breakr.Caption = "red"

        Dim breakg As New MapWinGIS.GridColorBreak
        breakg.LowValue = 51
        breakg.HighValue = 999999
        breakg.LowColor = g
        breakg.HighColor = g
        breakg.Caption = "red"


        Dim img_handle As Integer
        img_handle = AxMap2.AddLayer(img, True)
if I point to the int version of the file I get:

If I point to the float version of the file I get:

May 7, 2015 at 9:35 AM
If you can provide me a sample file, I can check how the current version is handling it and try to resolve possible problems.

May 7, 2015 at 7:50 PM
Hello Sergei,

I've been trying to figure out what exactly is causing some layers to disregard the colorscheme and haven't come up with anything definitive. I was able to get a different byte type raster to display by calculating statistics on it, but that didn't work for my original byte type raster.

So in the attached zip...

landcover.tif is a byte type raster that uses the colorscheme
topock1_ycra_breeding_138.600.tif is a byte type without stats that fails to use it.
topock1_ycra_breeding_138.600_wstats.tif is a byte type with stats that fails to use it

and topock1_ycra_breeding_138.600_32bfloat.tif is the same layer converted to a float that does display correctly.

If the attachment gets stripped I also moved a copy here:

Thanks for any insight!
May 8, 2015 at 3:00 PM
FYI, I reverted back to 4.8.6 to test this issue and these same layers display fine on that version of MapWinGIS
May 8, 2015 at 7:46 PM
I tested your files with the version. I observe the same behavior. The problem is with the selection of the rendering routine. If the following clause is true:
if (_dataType == GDT_Byte && _imgType != ADF_FILE && _dfMax > 15)
it will choose single band greyscale rendering and will ignore the color scheme. If data type is other than GDT_Byte (int or float), it will honor the color scheme. It appears that this selection logic was different in version 4.8.6.

Starting from version 4.9.1 it's possible to override this behavior by setting:
img.AllowGridRendering = tkGridRendering.grForceForAllFormats; 
It works with and the grid is rendered with color scheme. I'm not sure if there is a workaround available in v4.9.0. In general I'd recommend not to use this version, since it's quite old and it's difficult for us to support it. Either stick with the one that is working for you or upgrade to the latest version.

May 8, 2015 at 8:00 PM
P.S. Most likely I'll restore the old behavior for this type of files (GDT_BYTE single band), as it wasn't done on purpose (just difficult to test every type of file). If color scheme is present it's reasonable to expect that it will be used without some type of "forcing". But since there is a workaround, it can wait till the next 4.9.4 version.
May 8, 2015 at 8:28 PM
That's great! Thanks for looking into it.

I was mistaken in the version I was using it was actually 4.9.2 which is the latest with 64 bit binaries available.

For the time being I think I'll stick with the 4.8.6 versions as I've had great success with it in the past and was experiencing several other problems when I tried to upgrade to 4.9.2. These problems include the above symbology issue, no available 64x binaries, difficulties getting my project to run against the available 4.9.2 binaries, maps zooming oddly when a form resized and another symbology issue that wasn't present in the previous 4.8 version. I'd be happy to submit details about each of these if it would be helpful but it might be difficult for me to recreate as I've just switched back to the 4.8 version of the ocx.

I am very excited to make the upgrade to the latest version and will revisit the switch at a latter date.

And just in case you're curious about how I've been using your library there's an article with some screenshots at:
and the application's user manual at:

Thanks for providing the community such a fantastic tool!
May 9, 2015 at 10:55 AM
Thanks for sharing these links. Regarding x64 version - it should be available soon, Paul is working on this I believe. I can provide help with other issues when you decide to upgrade. Presumably zooming issue can be solved by setting AxMap.ZoomBehavior and AxMap.MapResizeBehavior. Not sure about other ones. The next major revision of MapWinGIS will be in a few months when we release MapWindow 5. There will be a number of improvements. Perhaps you'd like to upgrade then to avoid spending the effort twice. We don't plan any breaking API changes, but for the existing app some amount of tuning may still be needed.