Export preview not matching exported image

[twatzl]

Hi, so a while ago I opened ticket #36009 https://github.com/qgis/QGIS/issues/36009

in the discussion the conclusion was that it is expected behavior, however I now played around with the export settings and I still think that this is somehow weird behavior and it would make life a lot easier if it could be changed.

Describe the bug

When exporting a map the preview shown in the export dialog uses another zoom level as the exported map.

When exporting I would expect that the png I get looks exactly like the preview. If the required resolution is not available, I would expect either a. A warning and a suggestion for correct parameters b. Upscaling of the tiles that are availble c. The preview to show the tiles that will actually be used

In any case the expectation would be that exactly what I see in the preview is what will end up in the exported file.

How to Reproduce

1. Use any tilemap from mapbox studio as background.
2. create a print background
3. set export resolution to 300 dpi
4. set map size e.g. to 1280x1080px
5. set map scale to 1:12 000 000
6. export as png

QGIS and OS versions

QGIS version 3.12.1-București

[roya0045]

set export resolution to 96 if I recall.

[baswein]

I also struggle with this. If you set the export resolution to 96 dpi it will show you a preview of what your output would be at 96 dpi but if you set the export resolution to 300 it will still show you the 96 dpi tiles but when you export you get different tiles effectively making the layout a broken WYSIWYG editor. It would be great to have more control over the zoom level of the tiles and separate it from the export resolution of the layout. This would be especially powerful with vector tiles.

[3nids]

After discussing with @nyalldawson, there is two approach to solving this issue:

The easy stupid quick fix: make the preview image respect the DPI => this will dramatically increase the image real size and hence the preview rendering time (which will be the same than the actual rendering)

The performant approach:

1. Add a "preview final dpi" setting to map settings and render context, update the map settings to render context conversion code
2. Add a new flag ("has multiple resolution levels") to raster data provider which will define whether preview dpi should be respected or not
3. Only set this flag for WMTS layers
4. In the raster layer renderer, check whether preview output dpi is set and whether data provider supports it
5. If so, render a massive image to a qimage and resize and then render that

This is quite some work to achieve.

[baswein]

Thank you @3nids and @nyalldawson for looking into this- ya'll are amazing. Would the dpi preview performance hit be for all layers or just the WMTS layers? If it was just WMTS layers then that shouldn't be too bad as most of what you do in layout view does not cause the map to refresh.

For those of you also struggling with this my current work around for raster tile layers is to temporarily make the map frame full bleed and export a georeferenced image at the dpi that I am interested in and add it back to the map using it instead of the tiled layer. This allows me to divorce the tiles that are displayed in the final version from the dpi of my final print map. It also 'saves' the tiles as they where in the moment in case the service decides to change them. Of course this does not get around the fact that the tiles are designed for something like 96 dpi.

Now that vector tiles are available in QGIS through the MapTiler plugin etc. this work around is not as ideal because there is no way that I am aware of to get the vector output as PDF back into QGIS without making it a low resolution raster.

This presents an issue for the performant approach because I want my vector tile service to be loaded at the scale that the text and line widths are the right size for the paper size but I want the raster tiles and other raster layers to be loaded and printed at the higher resolution. I of course have no sense of the technical feasibility of this but perhaps zoom level overrides for vector and raster tile layers would be a solution. As an aside this is also related to the magnifier in map view as it loads new higher zoom tiles even when it is locked.

[nyalldawson]

Would the dpi preview performance hit be for all layers or just the WMTS layers? If it was just WMTS layers then that shouldn't be too bad as most of what you do in layout view does not cause the map to refresh.

All layers, regardless of whether or not you have a wmts layer present. And there's a lot of actions which trigger a map redraw:

• toggling layer visiblity in the main canvas
• paging between atlas features
• any scale/extent/size change on the main map
• moving items when you have the "prevent label overlap" setting switched on for a map
• even zooming into/out of the layout currently triggers a redraw at the new preview dpi!

The hack approach is a horrendous solution :laugh:

@3nids

We didn't consider vector tiles in our discussion -- I guess they'd also need to check and respect the new render context "desired output resolution dpi" setting.

[baswein]

It would not be ideal and I don't know if this is easier but In many programs there is a separate preview mode that shows what the final print would look like. I assume this works by printing the layout to a temporary image file and then displaying that. This isn't really any different than printing it to a folder yourself but it saves the manual steps and clicks of choosing a folder, naming the file, navigating to the folder, opening up the file, closing the file, and deleting the file.

[joeberkovitz]

I agree, it feels wrong that the preview is not an accurate rendering of what the printed or exported map will look like. It's counter to the whole purpose of the Print Composer. At least there should be an option to preserve the faithfulness of the preview, at the expense of performant tile loading.

[roya0045]

@joeberkovitz Set output resolution to 96 dpi and it should be the same.

[pjshelton]

Some of us want to use QGIS to produce print ready maps. i.e. need to export images with at least 600 dpi or more.

[roya0045]

@pjshelton If this is truly critical then you can look to fund something to solve this issue. Nyall and Richard clearly stated that this is not trivial.

[joeberkovitz]

@roya0045 I'm not claiming this is truly critical — I can see it would be a bunch of work, have too many other things to do, and can make do with magnifying the map ~6x to simulate 600 dpi output. However... setting the output resolution to 96 dpi i not a solution. It downgrades the printed output to look the same as the coarse-resolution screen display. So you get consistency without the quality :(

[roya0045]

If you want consistent quality the best option is to download the data, set up the symbology and not rely on external services, or less.

[joeberkovitz]

Thank you, that's a very useful suggestion. Note that there is another wrinkle in the picture that I don't think has come up: the external service I'm using (like many other tile-based services) provides quite divergent views at different resolutions, as it's based on scans of different sets of maps that were designed for use at specific scales. So part of previewing is not just seeing things at the desired resolution, but actually "hunting" for the resolution that delivers the best result for a given purpose.

Downloading works great if you know what you are getting, but in this case it just moves the "hunt" into the download process, where it is cumbersome to try one combo of resolution and extent, and then another.

I am not arguing for raising the priority of this, just want to note in the thread that the ability to see layouts at their actual export resolution would make it easier to find the right combination of extent and resolution when the content is highly resolution dependent.