9.0.179.1

manifold-9.0.179.1.zip

SHA256: 05c97659856f67a719a2c98eaf27510de34eb6f39430dd7a2e83d25a50c11d9e

manifold-viewer-9.0.179.1.zip

SHA256: c86f93ffab9b8c8088ade543e1a736a40637b304e9dc64e3835960a73c1db3da

sql4arc-9.0.179.1.zip

SHA256: 038779fa94906ac254ac77a1906d60a78d0831d088b3c7d34d7545d7ab012661

Changes

(Fix) Editing the legend style for a layout frame no longer resets the Position parameter in the Legend dialog to center / center, losing changes made previously.

(Fix) The Merge dialog generates the name for the new component so that it is unique in the data source of the map (was always generating the name that is unique in the currently opened MAP file even if the data source of the map was different).

(Fix) The CoordSystemOverride query function no longer fails to apply overrides to an incomplete coordinate system (eg, an empty string).

The map window supports the new Save as Image command which allows rendering the contents of the window into an image of the specified size. The image is created in the data source of the map. The default name for the image is '<window name> Image'.

Available modes:

• 'centered view at current scale' -- renders data from the center of the current view at the current scale, stops when the produced image reaches the specified size,
• 'current view' -- renders data shown in the rectangular area shown in the window with the desired level of detail,
• 'full view' -- renders data in the rectangular area that covers all layers except the base maps (the area shown on Zoom to Fit) with the desired level of detail.

The 'centered view at current scale' mode allows editing both the X and Y size of the produced image. The 'current view' and 'full view' modes only allow editing the X size and automatically set the Y size to be proportional to the dimensions of the render area. The maximum size of the produced image by either X or Y is 25 million pixels (this is not a technical limitation, but rather a sanity check).

The 'centered view at current scale' and 'current view' modes allow setting the size of the produced image to that of the current window. The 'full view' mode allows setting the size of the produced image so that it covers all layers with the current scale.

Big images are rendered in parts. Rendering an image with multiple parts adjusts label placement logic to avoid part boundaries, to protect from rendering artifacts. Labels placed on a part boundary try moving to alternative locations (and if that fails, eg, due to overlap control, they are suppressed).

Rendering an image tracks progress and reports the name of the currently rendered layer. This allows seeing which layers take a long time to render (usually, the layers that are slowest to render are web images such as Bing). Rendering can be canceled at any moment. When rendering is canceled, the system waits for database / web requests that have already been started to either complete or fail.

The Save as Image dialog includes an option to render the virtual layers. If the option is turned on, the system renders the virtual layers that are currently shown in the window (background / grid / legend / north arrow / scale bar). If the option is turned off, the system ignores the virtual layers -- in particular, the background of the produced image is made transparent. By default, the option is turned off.

The Save as Image dialog includes the Edit Query button that composes the rendering query and allows customizing or saving it.

The Save as Image dialog shows the name of the data source that the new image will be created in unless that data source is the currently opened MAP file.

The Save as Image dialog selects the produced image in the Project pane after the rendering process completes.

New query functions:

TileRender - takes a component, the rectangle to render, the render size in pixels, the tile size in pixels, a boolean value that controls whether to render the virtual layers, renders data in the specified rectangle and returns the result as a table of BGRA tiles. The component should be a map or a component that can participate in a map as a layer. The rectangle is specified in the coordinate system of the component. If the proportions of the rectangle do not match the render size, the rectangle is increased to avoid vertical or horizontal distortion (eg, attempting to render a 7000x8000 rectangle into a 200x200 image will increase the rectangle to 8000x8000 to match the proportions of the result). The coordinate system of the result is shifted to the left bottom corner of the render rectangle. If the virtual layers are rendered, their parameters are taken from the component properties. If the virtual layers are not rendered, the background is transparent, the grid, the legend, the north arrow and the scale bar are turned off.

TileRenderWindow - same as TileRender, but instead of a component, takes the name of a window and renders data in that window. If the window shows a virtual map, the parameters for the virtual layers are taken from the window.

TileRenderSingle - takes a component, the rectangle to render, the render size in pixels, a boolean value that controls whether to render the virtual layers, renders data in the specified rectangle and returns the result as a BGRA tile of the specified size. The component should be a map or a component that can participate in a map as a layer. The rectangle is specified in the coordinate system of the component. If the proportions of the rectangle do not match the render size, the rectangle is increased to avoid vertical or horizontal distortion. If the virtual layers are rendered, their parameters are taken from the component properties. If the virtual layers are not rendered, the background is transparent, the grid, the legend, the north arrow and the scale bar are turned off.

TileRenderSingleWindow - same as TileRenderSingle, but instead of a component, takes the name of a window and renders data in that window. If the window shows a virtual map, the parameters for the virtual layers are taken from the window.

TileRender / TileRenderWindow are optimized for rendering big images, eg, rendering a map into a static image using the Save as Image command. TileRenderSingle / TileRenderSingleWindow are optimized for rendering small images, eg, rendering a single tile of a map for a web request.

All TileRenderXxx query functions require the render rectangle to be non-empty. (If you are computing the render rectangle from component data, watch for cases where the rendered component is empty. The Save as Image dialog sets the render rectangle to [ 0, 0, 1, 1 ] in this case so that an empty component still renders and produces an image.)

End of list.

Nice to see the next release. Some feature ideas for discussion (Useful? Exists already?)

1. Expression for X_coordinate and Y_coordinate.

Currently need to construct the two part expressions VectorValue(GeomCoordXY([Geom], 0), 0) and VectorValue(GeomCoordXY([Geom], 0), 1) to generate the X and Y coordinates. I needed them in the Transform > Compose > Circle transformation to draw circle areas with the radius from a field. For repetition, I have the expression save in a .txt file to copy and paste.

What if there were two new expressions, X_coordinate({Geom]) and Y_coordinate([Geom]) that did the same?

2. List Geom field names on right click in expression building boxes where Geom is used?

What if a right click on <geom> in GeomCoordCount(<geom>) or similar opens a drop down box of the Geom field names? Right now, need to either manually type in [Geom] or find it in the list of Fields. Right now looking up the list of fields entails clearing the expression search box, scrolling to the top and the fields list always needs expanding again then finally clicking on the field name. While [Geom] is the most common, sometimes I have other geom fields.

3. Add more clickable buttons for common actions such as Select All.

- "Select All" button in dialog boxes. For instance when creating a map, there is the option to click little boxes and add layers to the map. Suggestion is for a clickable box that Selects All. Could move from mouse to keyboard to to this but if we're clicking anyways, perhaps a box to click to Select All?

4. Option to Open Map on creation

So perhaps an option in Tools > Options. "Open maps on creation". 100% of the time I want to see the map upon creation. Now it takes another double click to open a map I just created.

5. A warning when a table doesn't have an Index. Some expressions don't work if the table doesn't have an index. I was stymied for awhile then remembered about indexing. What if there is a warning, or suggestion to index, upon importing a layer?

Thanks. Point by point:

1 - Sure, why not. GeomCoordX / Y / Z would perhaps be better as function names.

2 - That's autocomplete. We would like to have it, yes, and we will add it sometime, but it's not a small thing (so it has to compete with other great things of similar size).

3 - All grid controls do Select All on Ctrl-A (and Select None on Shift-Ctrl-A and Invert Selection on Ctrl-I). We don't think duplicating Select All in a toolbar button would be a good idea -- first, because many grids don't have toolbars above them, and second, because when a specific grid has a toolbar above it, this toolbar is frequently filled with buttons specific to the grid, toolbar space is pretty precious. Maybe we could add Select All / Select None / Invert Selection to the context menus for grids though. The menu items would then clearly show the keyboard shortcuts, too.

4 - We aren't against the idea, but how specifically do you want it to work? Option (a) would be 'save last opened windows' into the MAP file. There will be a drawback though: just opening a MAP file and opening a window would prompt to save on close, even though you didn't make any changes to the components inside the MAP file. Option (b) would be 'save last opened windows' but save outside of the MAP file, eg, into the same place where we save favorites. This way opening a MAP file and opening a window would not prompt to save it (but will still save last opened windows). The drawback would be that this would only work in the scope of the same system + user. Option (c) would be to somehow mark the component you want to auto-open. That would work everywhere, but will perhaps be limited to a single component (if we need to open multiple components, we'll need to be able to specify in what order they should open / whether specific windows should be docked or floating, etc, this looks like too much). What specifically are you after - saving the state of your workspace (then perhaps option b would be best) or forcing a specific component to open for whoever opens your MAP file (then option c)?

5 - We have been thinking to do that, yes. We might have a better solution here, at least for MAP files. Let's get back to this question when we implement it.

Thanks Adam. For further elaboration on the points:

1. Those 3 new expressions would be very useful.

2. Global Auto-complete would be great though I understand it could be a big task to implement. For me, a nice to have however what exists now works fine (list of fields and expressions in expression building pane)

3. I used an image editor to mock up what a Select All box might look like (see Select All buttons.jpg). One more box for Select All above all the clickable boxes. However, you are right, CTRL-A, CTRL-Shiift-A, and CTRL-I work too. I use a Dvorak keyboard layout and I can do all 3 with the left hand without taking my left hand off the keyboard. (Second attachment, just noticed the attachments are in order of last-attached, top-of-list)

4. See attached image "Map opens on creation.jpg". So when Right-Click > Create > New Map > Create map, then the map opens without needing to double click on the name of the newly created map in the Project pane. This would be an option in Tools > Options. Maybe some users create maps but don't want them to pop open right away. However, I'm anxious to see what I just created. So "Create Map" creates and opens the new map component.

5. Great, looking forward to see the implementation.

Thanks Dimitri, I see now the grey background if a table does not have an Index. I hadn't noticed before.

I appreciate the ability discuss and debate feature ideas here.

Attachments:
Map opens on creation.jpg
Select All button.jpg

Oh, I understand what you mean in 4 (open map on creation) now. We will consider adding an option to open the new component after it is created to Options (or maybe to the New Xxx dialogs themselves). However, before we do this -- you can open the newly created component simply by pressing Enter after the dialog closes. After one of the New Xxx dialogs creates a component, we open the Project pane and select the created component exactly so that you can open / drag / whatever it right away.

Thanks Adam, yes pressing ENTER is sufficiently quick and does what I was wanting.

There are so many of these tips. Another was Dimitri pointing out that cells in tables without an index have a grey background.

These are great tips. Usually it takes running into a problem or long work flow for someone to point out there is already a feature for that. it's probably described in the manual but it doesn't register at the time of reading

A warning when a table doesn't have an Index.

If a table doesn't have an index, it will be read only and will have cells shown in gray background.

Nice to have the new save image tool. However, could we get a better way to judge the resulting image size. I normally think in terms of dpi when judging the balance between a good enough image versus trying to minimize file size. Generally, I think it best to set the extent and the dpi, although I'm certainly open to other ways. Ideally the software would somehow indicate what the underlying map image resolution currently happens to be, so that the dpi isn't needlessly set too high.

DPI is not a property of an image. It is only meaningful to talk about DPI in relation to a medium like paper (or screen) and the size of the image on the paper.

http://www.mppng.nl/manifold/pointlabeler

I'd like to see a readout giving the estimated uncompressed size of the image, for example, in MB. The size in pixels wide and high is convenient for many publishing purposes, like images to be used on web pages or otherwise incorporated into publications like Word documents, PhotoShop and similar.

If you want to include a map in a printed publication the direct way to do that is with a layout. Add the map as a layout frame to your composition. At the end of the day your printing software stack probably is going to determine the DPI on paper anyway.

I agree if the ultimate destination of some JPG or PNG is use in some printed work you might want to think in advance what DPI might be used. In such cases you can think, OK, I want about a 10 inch image at 300 dPI in the printed work, so the image should be about 3000 pixels wide.

For image size, are we talking about megabytes or inches / millimeters? The rendering DPI is fixed at 96 = default screen DPI in Windows. We can allow controlling it, if needed.

DPI is (are) such a PIA.

In particular, the Windows default of 96 has long been irrelevant for Windows itself, and has always been irrelevant for everything else—that is, for general-purpose image rendering, and especially, for print.

So I agree, it is essential to be able to specify target DPI for image rendering (300 is a much much better default than 96, and at least 600 should also be available), alongside image size which must be specifiable either in pixels or in linear measurements (millimetres or inches). These parameters are orthogonal.

The annoying conflict between DPI and metric linear measurements is probably fixed for all time. Every imaging person just has to live with it (25.4 probably the most commonly entered number on hand calculators globally?).

In summary I would say: just do what Photoshop does.

Another way of putting (most of) that:

When someone makes an image of a map (etc.) in Manifold, the surest bet is that it is destined to be used elsewhere. Almost certainly not in Manifold (though it could be), and quite possibly not (almost certainly not only) within Microsoft Windows.

So that’s how the image should be specified and prepared. For the wide wide world (of sports).

OK, so, to recap, you want to be able to say "I want an image to be 30 cm x 50 cm and the rendering should be done at 600 DPI", right? Isn't that what layouts are for -- to let you specify the physical size via page format, then arrange stuff in the resulting area, then print it with the desired DPI? Because we will allow saving a layout into an image as well.

Back when I was working with M8, I used a roll-type plotter to print 762 × 1,070 mm (Architect E size drawing). Resolution was about 600 DPI if I recall from several years ago. Print background was Google Earth with land parcel information to show location within the area. M8 had a Print to PDF feature which was necessary to get the resolution for oversize printing.

Well, kind of.

Layouts are bound to printer space.

More often, I just want to render data into an image. Not screen, not page—image. For any use I might later choose, in any format, on any platform, for distribution as is or further processing, anything.

I would like to see the full range of standard parameters for making an image—at any size.

Very trivially, there is no purpose in rendering an image at 96 DPI. Nobody ever uses 96 DPI, for anything. It’s an artefact.

(I think in the long term, layouts and maps can and should be merged into one thing, dropping paper space altogether. Layouts have always seemed to me very 1980s. Images can be printed, universally.)

Thanks a lot for this "render as image" add to M9.

I fully agree with Tim on those points. The layout is a mean to add the mapping decoration also as the coordinates grid or graticule texts on the side etc.

But one function I really use a lot in M8 is to turn the layout to an image for preprint exports in order to be sure that everything is exported correctly, and that the printer has to mean to change anything before printing . The print as pdf is always bad managing the transparency in layers in M8, just to mention one example.

So my interest is having the "render as image" both for maps and layouts.

The save as image option is one of the M8 options I missed the most.

Some thoughts:

In many cases what matters when creating images of maps is the real world units target resolution, that has to do with the project desired accuracy, or the print scale. For example for a printed map in 1:5000 you would want a background image with 1m or 1.5m pixel size. I think this would be a useful addition.

Also it would be useful to have the option to set the desired extend of the image in real world coordinates. For example from 500 to 1000 in Easting and 40000 to 40050 in Northing. Also it would be useful to have also the option to set the extend by using an existing layer.

QGIS has options like the above, that work well.

In QGIS when you have already set extend and real world resolution, the pixels resolution is automatically calculated ("Columns").

what matters when creating images of maps is the real world units target resolution, that has to do with the project desired accuracy, or the print scale. For example for a printed map in 1:5000 you would want a background image with 1m or 1.5m pixel size.

I'd very much like to hear more about how you use that in real applications. For example, increasing the number of pixels doesn't change the accuracy of the data: if you're rasterizing a vector display (what Save as Image is doing when it makes an image from a view of vector data), if the vector data shows lines of geologic faults and is only accurate give or take a kilometer rasterizing the line drawn for a geologic fault in that drawing so each pixel covers a meter in XY isn't going to make the data accurate to give or take a meter.

I also don't see where you get the 1m or 1.5m pixel size for a printed map in 1:5000. Could you elaborate on that? I know a lot of graphic artists and designers and they usually think in DPI (dots per inch) or similar measures, so if they want a 10 inch wide image that is 300 DPI resolution they need an image that is 3000 pixels wide. I realize printed cartography may be different, but for that there already are layouts and layout frames.

Scale is also important because layers in maps can be set to turn on and off automatically because of scale, and virtual layers like Legends also therefore can dynamically change based on scale. The Save as Image dialog automatically handles that, and it handles a lot of other things, like pulling appropriate tiles from image servers, or rearranging labels and dealing with overlaps, that change depend on scale. I don't know the details of how other GIS packages handle such things, whether they dynamically update when different scales are implied or if they just blow up or reduce a static view.

I'm not disagreeing with you as I think there are many possible additions to the Save as Image dialog and pixel size in the geographic projection used by a given layer might be one of them. But it's important to know how and why such a capability might be used, so if it is added the controls for it can be designed to most smoothly integrate with other workflow.

Given that the images created are created with full georegistration it makes sense that a geographic linkage such as providing readouts and controls on pixel size per meter or whatever might be desired. But that only makes sense if the image is used for a purpose and in software that can handle full georegistration of images, as with GeoTIFFs.

Software like PhotoShop or using images as illustrations in reports done in Word doesn't maintain georegistration, so there the size of the image in number of pixels wide or high is the dominant parameter. Another parameter I'd like to see is the computed estimated uncompressed size of the image, so people can see if they're trying to command the creation of a 40 GB image when they really want something around 40 MB.

it would be useful to have the option to set the desired extend of the image in real world coordinates. For example from 500 to 1000 in Easting and 40000 to 40050 in Northing.

I'd be interested in hearing why you want to set the extent in real world coordinates, as thinking in coordinates in Easting and Northing is mind-numbingly difficult and for that reason is not typically the way user interfaces set extent. Most people much prefer a visual, "what you see is what you get" (WYSIWYG) approach: just pan and zoom to the view you want in the map and tell the system to use that. That's why Manifold has a "current view" choice.

I note that the Q dialog shown doesn't provide that option. It just has current layer extent, calculate extent from whatever is the extent of a layer, or the extent of the full map canvas. Wouldn't it be a lot easier in Q if you could just pan and zoom to the extent you want and then hit "current view?"

If you do want to use manually set extents that's easy to do. Just leverage any one of the many facilities Manifold has for setting views. There's a big variety that already fits into existing workflow, so you can recycle information you already have with greater accuracy and less work.

For example, suppose you want a view because you want to match an index rectangle that shows the extent of some map or image that you already have. Add the index rectangle / grid layer to your map and select the one of interest. Zoom to the selection and turn off the index layer and there's your view to exactly the extents of that rectangle. No need to manually enter numbers.

Like I wrote above, I'd be curious to learn the reason why you might want to manually enter extents as projected numbers, as I can't think of any examples for that off hand.

But if that's what you want to do, no problem: add a layer in that same coordinate system and add a rectangular area. Pick the area and set the coordinates of the four points in the area to the extents you want. You can then zoom to that area and there's your view. That approach also has the benefit of providing visual previews so what you see is what you get. Make the rectangle layer partially transparent so you can see what the view will be based on the extents you specify.

With 9 you already have the equivalent of Q's set extent buttons by zooming to a layer or to selected objects in a layer and using "current view" or for the full map, "full view".

A common scenario is that I have a WMS image server and I want to get a part of it as a image to use it offline. Such an image could be exported to tiff to be used by people using cad, and/or printed as background of a vector drawing (inside or outside Manifold).

The WMS has some resolution, that might be bigger than the necessary. In that case, you should be able to set in the Save as Image dialog the resolution you need in the units you use in the project.

The "1m or 1.5m for 1:5000" comes from a popular assumption from printed maps age that the human eye can distinguish on paper two points/lines that are separated about 0.00025mm. So 0.00025*5000=1.25m for a 1:5000 scale. Also, you might have seen that in some projects the accuracy requirement is described in scales. For example "Project accuracy 1:50000". This is possible because some assumption like the above is made regarding the relationship image resolution and the scale of the final product.

Regarding the extend in real world coordinates. I have a project that covers a specific part of the world and I want an offline image of that area. So there should be a way to get exactly the area I need from WMS servers or google maps imagery, and in the resolution I need. The easiest way to to this is define the area I need using coordinates, or using a layer to define the area. Currently (and in M8), you can zoom window to the area you want. But in that case you cannot control the real world resolution (I described above why you need it). You can just do trial and error with the pixels, to get something acceptable to look at and that is not to big in disk size.

Regarding entering coordinates by hand, it is not the best way to do it, ofcourse. Better is by a window view, or using a layer.

Regarding Q, it does let you change the desired area manually, set it using the current view, or using a specific layer. And it lets you control both real world resolution and not just the number of pixels. And IMO it is better than the Manifold way.

If you already have specific coordinates for the render rectangle, you can enter them into the query generated by Edit Query. If you don't have the coordinates and want to render the extents of a particular layer / selection / whatever, zoom to that (eg, for a layer, right click the layer tab and select Zoom in the context menu) and render the current view.

You mean change the VectorMakeX4 coordinates in the query, right? That does the job for specifying manually the area. Also zooming to the the extends of a specific layer, does set the area you want for an image.

But in both cases you cannot control resolution. I describe why real world resolution is important in my reply post to Dimitri.

I get it. We'll think about specifying the dimensions of a pixel in physical units (eg, 1 pixel = 2 x 2 meters). (It would have been great if this could be put into a tool that zooms to the desired scale instead, because then you'd zoom to that scale and Save as Image with the current scale plus zooming to the desired scale would have been useful for things other than Save as Image. But visual control over the scale would remove visual control over the render area and the latter is more important. So, I guess, we should provide non-visual means to control the scale, as an option.)

I did some experiments with changing VectorMakeX4 values in order to get an image between specific world coordinates, and it seems that it doesn't work as I expected. Image scale is not the current, but some other. I suppose you have to edit somehow coordinate parameters too.

If you want to specify not just the render area, but also the render scale, you have to adjust the size of the image in pixels.

I don't want to adjust the scale. I want to keep the current scale, but instead of getting an image from X=5000 to X=10000, I want one from X=2000 to X=10000.

Let me elaborate. You launch Save as Image, set the view to something that preserves the current scale, press Edit Query. The generated query says that it renders the area from Xmin = 5000 to Xmax = 10000 into an image with the width = 500. The proportion between these values preserves the current scale, the dialog computed the width based on that. You decide that you need to adjust Xmin to 2000. This adds 3000 more data units by X. So, in order to keep the scale unchanged, you need to add extra pixels to the image. From the proportion, this is 300 more pixels. So the width of the new image has to be set to 800.

I realize performing these computations by hand is perhaps tedious (although you could modify the query to perform these computations for itself, too). But could we talk about what specifically is the scenario in which you have to generate such images? Because I thought you need them to match WMS output or something like that, and in this case you already have both the coordinates of the data rectangle and the dimensions of the final image - exactly what our rendering functions take.

Many times I need to have a part of a WMS image for offline use, as background in CAD software. Sometimes the final aim is to print the image, or other times I want to have it as a background to digitize on screen.

There is a always specific area of the world I want to cover with the image, and there is a specific resolution, I can know in real world units. If I want an image to show behind a whole town plan (scale 1:5000), I need a image with 1m pixel size, and if I have a county-sized map (scale 1:20000) I need an image with 5m pixel size. I don't care and I don't know how many pixels in x and in y are in the image, as far as it doesn't become too or unnecessary large on disk.

As tjhb says, "When someone makes an image of a map (etc.) in Manifold, the surest bet is that it is destined to be used elsewhere.". I suppose people that want to use the image in geographic aware software, or not so aware CAD software, would probably want to control the coverage area and the resolution in real world units. Probably people that want to use the image in software like Photoshop would care about dpi instead.

Thanks a lot for the explanation.

So we need to control both the render area (we have numeric values for the extent) and the pixel scale (we have numeric values for that, too).

We can currently use the numeric values for the pixel scale by right-clicking the scale readout in the status bar, selecting Custom, then entering the desired 1:xxx ratio. But then we need to somehow also specify the exact extent -- because this could be smaller or larger than the window, yet not a 'full view'.

We can also currently use the numeric values for the extent -- by creating a new drawing, placing a rectangle with the desired coordinates, then zooming to that layer. But then we need to somehow specify the exact scale -- right now we can only specify the number of pixels.

We can allow setting the view in Save as Image to the extents of a layer. This will allow scenario 1. We can also allow specifying the pixel size in physical units instead of the image size in pixels, as an option. This will allow scenario 2. So, we could do either of these things and that would solve the issue, correct?

Yes, both approaches would be a solution.

I think I would prefer scenario 2, because you have control over the final pixel size in real world units.

In scenario 1 you get automatically some pixel size, but using what assumptions? You could say that for 1:5000 I need a 1.25m pixel size (for the reasons I described before). Or you could select the pixel size the WMS server provides automatically for each scale level. But in cases that you don't have a WMS server, but your own offline data, there is not such information.

A possible disadvantage of scenario 2 on the other hand is that Manidold would have to render an image for saving at a scale (and so area/line/point/label styles) different than the ones on display. When you are just creating a plain WMS extract for offline use, that is not an issue.

In both cases it would be useful to have a approximate prediction of the image size, as if it was Tiff for example.

!!

Thank you very much, Adam :)

First feedback: It (Snapshot Render) doesn't work well with opacity of the layers. Then the Image of the Map comes darker than original.

I am telling about the situation when in the Map there are many layers with semi-transparency.

I can bypass it though later in a graphical program, so it is not big issue for me.

Just for you info.

Or perhaps I set up wrong some channels. This topic is not fully clear for me.

(We reproduced the issue, I removed the request for example data.)

Thanks, we will look into it.

In the meantime, turn the 'Render virtual layers' option on.

Ah, right. Now it's excellent :)