ECW and GeoTIFF export bugs in Globalmapper v18

andrewc

Technical Information
-----------------------------------------------------------------
Product: Global Mapper
Version: 18
OS: Windows7-64
Issue Category: Exporting and Printing
Problem Description:

Dear Globalmapper support

We have recently upgraded to a 2 seat network version of Globalmapper 18 (build 101416). We have started trying to use it, but have encountered a number of issues as follows:

1) Exporting to GeoTIFF results in the followng error:

Error writing GeoTIFF file H:\A.......................\ECWMosaic\noCatalog_transparent\clip_3band.tif
Compression scheme 0 scanline encoding is not implemented
TIFFOverlay.cpp - 114
Version: v18.0.1 (64-bit)
Build Time: Oct 14 2016 12:20:37
Last Op: File: Dlgv32Doc_Export.cpp : 12438

Stack Trace:
00000001402560BC (global_mapper)
00000001402578BE (global_mapper)
0000000140618857 (global_mapper)
00000001406195BC (global_mapper)
0000000140B712F5 (global_mapper)
0000000140D44276 (global_mapper)
0000000140D4DFAB (global_mapper)
0000000140D43C9E (global_mapper)
0000000140908F6F (global_mapper)
000000014023807B (global_mapper)
000000014023997D (global_mapper)
0000000140236461 (global_mapper)
00000001400E03A8 (global_mapper)
00000001400E7317 (global_mapper)
000007FECBAC17BE (mfc110)
... (50 Additional Stack Items Hidden)

Windows 7 Professional (64-bit) Memory: 54,006,648,832 of 68,658,917,376 available, GDI Usage: 500 GDI (Peak 606), 180 User (Peak 362)

We have tried exporting to the extents of the loaded imagery, to the view extent and to a polygon and we get the same error each time.

2) Exporting to ECW or JPEG2000 (and probably also GeoTIFF) with a selected (irregular) polygon as the export extent results in an ECW mosaic that is clipped to the extents of the bounding rectangle of the polygon instead of the actual polygon boundary. The result is the same with transparent background option switched on or off. 

3) Exporting to ECW or JPEG2000 with transparent background option switched on results in an image where the band order is not right when you load the resulting image into ERViewer. Instead of an RGB image, we get a blue/green image where the band order is 3,2,1 instead of 1,2,3.  We dont have ArcGIS but we would suspect that if you loaded the image into ArcGIS it would display the same way.

We are really frustrated by these errors as they are all a basic requirement of the software and worked perfectly in our previous desktop Version 16 software. 

Any assistance in sorting these issues out would be appreciated.

Regards
Andrew Coleman

OldChrisGISguy

I am running into the same issue exporting GeoTiff.

Error writing GeoTIFF file \GIS\.......Concepts.tif

Compression scheme 0 scanline encoding is not implemented

TIFFOverlay.cpp - 114

Version: v18.0.1 (64-bit)

Build Time: Oct 14 2016 12:20:37

Last Op: File: Dlgv32Doc_Export.cpp : 12438

Stack Trace:

00000001402560BC (global_mapper)

00000001402578BE (global_mapper)

0000000140618857 (global_mapper)

00000001406195BC (global_mapper)

0000000140B712F5 (global_mapper)

0000000140D44276 (global_mapper)

0000000140D4DFAB (global_mapper)

0000000140D43C9E (global_mapper)

0000000140907657 (global_mapper)

0000000140237FF7 (global_mapper)

000000014023997D (global_mapper)

0000000140236461 (global_mapper)

00000001400E03A8 (global_mapper)

00000001400E7317 (global_mapper)

00007FFDA6BC17BE (mfc110)

... (46 Additional Stack Items Hidden)

Windows 10 Pro (64-bit) Memory: 26,188,550,144 of 34,314,412,032 available, GDI Usage: 523 GDI (Peak 632), 140 User (Peak 253)

WarrenGAT

Error writing GeoTIFF file C: \xxxxxxxxxxxxxxxxxxx\test2.tif

Compression scheme 0 scanline encoding is not implemented

TIFFOverlay.cpp - 114

Version: v18.0.1 (64-bit)

Build Time: Oct 14 2016 12:20:37

Last Op: File: Dlgv32View.cpp : 681

Stack Trace:

00000001402560BC (global_mapper)

00000001402578BE (global_mapper)

0000000140618857 (global_mapper)

00000001406195BC (global_mapper)

0000000140B712F5 (global_mapper)

0000000140D44276 (global_mapper)

0000000140D4DFAB (global_mapper)

0000000140D43C9E (global_mapper)

000000014090BB96 (global_mapper)

00000001400DAE83 (global_mapper)

00000001400E7414 (global_mapper)

00007FFC8DB517BE (mfc110)

00007FFC8DB51A36 (mfc110)

00007FFC8DB8B5EA (mfc110)

00007FFC8DBE0A26 (mfc110)

... (44 Additional Stack Items Hidden)

Windows 10 Pro (64-bit) Memory: 23,214,215,168 of 34,308,186,112 available, GDI Usage: 643 GDI (Peak 936), 146 User (Peak 255)

bmg_bob

Hello,

The GeoTIFF export bug was fixed in the Oct 17 minor update of Global Mapper 18.  It was discovered shortly after we posted the Oct 14 update, and the fix was released a couple of days later.

Cheers,
Bob

WarrenGAT

I have re-downloaded and re-installed GM-18 today, the download link does say Oct.17th, however when installed, I still see v18.0.1 (b101416) Oct 14 2016.  I've tried "check for updates" and it says no new updates available.  Please advise....

Mykle

I downloaded the daily build an hour ago, and it displays as expected:
Global Mapper v18.0.2 (b102716) [64-bit] - REGISTERED

This version is available at:
http://data.bluemarblegeo.com/downloads/global-mapper/dailybuilds/

bmg_bob

WarrenGAT said:

I have re-downloaded and re-installed GM-18 today, the download link does say Oct.17th, however when installed, I still see v18.0.1 (b101416) Oct 14 2016.  I've tried "check for updates" and it says no new updates available.  Please advise....

Did the new version fix the problem? Typically, the build time on the About... box is early in the morning, but the one you are showing is after noon, so it would have been posted after a change was made. If the problem is not fixed, you should get the latest daily build, as @Mykle suggests.  I will find out why the date on the download page does not match the installer.  The "Check for Updates..." function will not indicate a new version is available until 18.1 is released next year.

Cheers,
Bob

WarrenGAT

Seems to be working now, yes thanks.

naugustin

I just tried to export elevation GeoTiff tiles and get this message:

Error writing GeoTIFF file Z:\Desktop\VEMA_QGIS-Project\HighResBathymetry_SO237-Bonatti_60m_WGS84_A_15.tif

Bits/sample must be 1 for Group 3/4 encoding/decoding

TIFFOverlay.cpp - 114

Version: v18.0.2 (64-bit)

Build Time: Nov  2 2016 01:30:27

Last Op: File: Dlgv32Doc_Export.cpp : 12453

Stack Trace:

000000014026C2FC (global_mapper)

000000014026DAFE (global_mapper)

0000000140635987 (global_mapper)

00000001406366EC (global_mapper)

0000000140B93135 (global_mapper)

0000000140D66396 (global_mapper)

0000000140D60722 (global_mapper)

0000000140D65CEC (global_mapper)

000000014092D6E6 (global_mapper)

00000001400DD313 (global_mapper)

00000001400E9934 (global_mapper)

00007FFC1D9C17BE (mfc110)

00007FFC1D9C1A36 (mfc110)

00007FFC1D9FB5EA (mfc110)

00007FFC1DA50A26 (mfc110)

... (44 Additional Stack Items Hidden)

Windows 10 Pro (64-bit) Memory: 9,609,097,216 of 12,884,414,464 available, GDI Usage: 401 GDI (Peak 530), 153 User (Peak 288)

Anything I can do?
Cheers, Nico

bmg_bob

Hello Nico,

Strange.  That bug should be fixed in the version you are using.  Perhaps you are using a different workflow that causes the crash.

First, I recommend trying the most recent daily build . Simply download the appropriate installer and run it to install the latest build.

If that does not resolve the problem, I recommend that you send an e-mail with a detailed description your workflow and the results, along with a copy of sample data that will reproduce the problem, to Blue Marble Geographics support (geohelp@bluemarblegeo.com).  This will ensure that the support team sees the problem and can provide you with a timely response.  Thank you.

Cheers,
Bob