It is worth noting that a single image file really cannot contain as much detail as the original CC3+ map, unless it is a very small map.

This is just a limit of images, really. While you can certainly export an image large enough that you can do zooms in it, you can't get the same quality as inside CC3+ itself.

If you are interested in very large exports, you can have a look at the large exports annual, it contains scripts that help you do what Sue suggests, export in pieces and stitch together, but as she says, you still quickly runs into issues with the image formats themselves.

I have done a 200000 x 200000 pixel export using this technique, but the image file is basically unusable, no programs actually manage to open that file. The only thing I could do with it was creating a zoomable web view (Go to https://atlas.monsen.cc/Maps/City%20Of%20Sanctuary and hit the "Zoomable Image" button). It is quite impressive, but of limited use.

I don't think TRACED can handle that image. Too much details beyond the landmass itself, like that border, all the text, all those tiny islands, city symbols extending beyond the coastline.

You'll probably have an easier time just tracing it visually (manually) using the landmass drawing tool.

When you are exporting for VTT use and plan to use grids, make sure to always export using the rectangular section option. For example, if you look at your screenshot above, you'll notice that you have a border outside your map that is part of your image.

CC3+ isn't a "grid mapper", so export sizes are for the entire drawing, not just the gridded areas, so when you export the image in a size of 2000x2000, that border is going to eat part of that size, not leaving a full 100px for each grid square. But if you use rectangular section when you export and make sure to only export the map itself (use snaps on when defining the area to ensure precision) you should get the right size.

It is also important to set the export size correct in both dimensions.

Yes. I just looked at the api data to see what travellermap actually sent.

Just changing the number on the top doesn't work unfortunately, as the code that created the import explicitly sets a color for every border, and it uses 15 if it gets (what it considers) an invalid color from travellermap.

What you need to change are the color values:

#COLORS
#======
color names = red:2|blue:9|olivedrab:12|orange:8|yellow:4|purple:7|green:13|lightgreen:1|lightblue:9|pink:187|brown:11|cyan:5|hotpink:6|lime:118|darkred:165|darkkhaki:130|gray:14|slategray:67|darkslategray:66|white:15|indigo:58

This section is also what makes Darian and Sword Worlds the same color. Travellermap sends color blue for one of them and lightblue for the other, and if you look at the config, those are both set to be color 9.

You can also get it to use those html colors just by inserting them into the list, like I did here, this should cause the white sections on Spineward Marches to come out as yellow:

color names = red:2|#e32736:135|blue:9|olivedrab:12|orange:8|yellow:4|purple:7|green:13|lightgreen:1|lightblue:9|pink:187|brown:11|cyan:5|hotpink:6|lime:118|darkred:165|darkkhaki:130|gray:14|slategray:67|darkslategray:66|white:15|indigo:58

The way we handle these colors was written before travellermap started putting those html color codes in there, so I am afraid this is a manual process for now to identify and insert appropriate replacement, the importer would need an update to be able to parse those automatically. Personally, I would probably just do some quick manual color changes on those entities after loading the map. While having everything correct out of the gate is obviously preferable, the main work is in drawing the sectors after all.

Also note one thing about the import dialog. It caches the setting sin memory when you load the file, so if you make tweaks to the config file with CC3+ open and want to test the new settings, you need to click the change export settings button and browse for the file again, even if the dialog indicates it is already the right file.