new release 3.2.2 and 3.3 won't render raster

[Joe LeMonnier]

It will render only in draft mode. When switched to proof or final quality:
1 screen goes white
2 gear appears in corner
3 timer appears
4 Geocart renders borders and vector if any.

I'm using Mac OS Mojave

Surprised I didn't see this sooner but I haven't been using rasters for a while.

I've tried this with both 3.2.2 and 3.3

[Atarimaster]

Hmm, works fine on El Capitan so I guess it must be connected to Mojave somehow.

[Joe LeMonnier]

I tried on another computer and it (3.3) doesn't work on High Sierra either.

The downloads page won't load the older versions (3.1 or 3.2.2) so I'm kinda stuck with the draft quality for now.

[daan]

Hello Joe.

I’m not sure what to tell you. We test on Mojave. Proof and final quality both render on the 5K iMac we test on. There must be more to the problem than just Mojave, so we should communicate by e-mail to make progress.

I will send you a link to an older version.

Regards,
— daan

[Joe LeMonnier]

Try it with a 16-bit image.

Download this HUGE one


https://www.ngdc.noaa.gov/mgg/global/re ... nced_tiff/

IT SHOULD recreate the bug when you try to render in proof or final.

[Atarimaster]

I just tried to render a map using that image (on Equirectangular projection, standard parallels 35°, size 1120.8 x 684.48 points at 300 dpi, final quality).
Geocart takes a few minutes on my comparatively slow computer, just like it always does on maps that size and resolution, so obviously it is busy rendering the raster database, but when it’s finished, there’s no raster image visible (but the vector databases are).
It works fine with a different image of the same size, namely the Natural Earth Hypso ("large size" file).

The image you link to is a 16-bit grayscale image, so I converted it to a 16-bit RGB image – and this one was rendered.

My conclusion so far:
Geocart has a problem with 16-bit grayscale images, at least when using proof or final quality (because I can confirm that it works with draft quality).
As a workaround, you can convert it to 16-bit RGB.

This is the converted (zipped) 16-bit RGB image I used:
https://map-projections.net/download_te ... GB.tif.zip

It’s a 400 MB file (approx.) so I’d like to remove it from my server soon – please tell me when you’ve downloaded it or don’t need it at all.

Hope this helps,
Tobias

[Joe LeMonnier]

I was easily able to convert my data to RGB. Though the files are now 3 times their original size they work fine, if a bit slower.

My largest files are TIFF and exceed the 4-gigabyte limit but they will work as large format PSD.

[daan]

I am able to confirm these findings:
• The problem is 16-bit grayscale TIFF
• The problem is not specific to Mojave
• The problem does not happen on my in-house “debug build”, which (a) makes it hard to debug; and (b) likely means that this is a “code generation” error, rather than a programming error.

If this is a code generation error, then, in order to fix it, I will have to isolate the piece of code that is problematic and probably turn off optimization flags around it. That probably means slower execution for that code, possibly affecting all color models.

Grr.
— daan

[Atarimaster]

Ummm, pardon me for asking, but is this really worth the effort (and the possible repercussions)?
I mean, the problem is easily solved by converting to 16-Bit RGB, and an LZW-packed RGB TIFF file is about the same size as an unpacked grayscale file…

[daan]

Ummm, pardon me for asking, but is this really worth the effort (and the possible repercussions)?

Mostly it is a matter of civic duty. I need to isolate the problem, and if it turns out to be a compiler bug, I need to report it. I would not put out an urgent fix for this; I would just roll it into the next regular release. If doing that would degrade performance noticeably for all color models, then it is possible I would not do it at all until the bug gets fixed.

Cheers.
— daan