Bug report #7927

composer fails to export with high dpi, without any message

Added by Regis Haubourg over 11 years ago. Updated about 11 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:Marco Hugentobler
Category:-
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:16798

Description

Hi, QGIS doesn't export any image beyond a given dpi resolution.

For A0 maps with lots of raster and transparency, I can't export better than 50 dpi.
I had to downsize to A1 (and change all labeling also) to export up to 220 dpi correctly.
From 220 dpi to 300 dpi, I encounter issues with blending mode layers (see #7926).
From 400 dpi and above, nothing happens after having choosed destination file name. Gui is responsive, no file is written

print_tests.tar.gz (403 KB) Giovanni Manghi, 2013-07-12 03:10 PM

Associated revisions

Revision bed65cb1
Added by Hien TRAN-QUANG over 11 years ago

Fix #7927 : Add a warning message if trying to print a composition
as an image fails (Qt's QImage sanity check for memory overflow)
Moved previous commit from core/qgscomposition to apps/qgscomposer
as QGIS server uses qgscomposition.

Revision aa0a17b2
Added by Marco Hugentobler over 11 years ago

Merge pull request #670 from tqhien/master

Fix #7927 : Add a warning message if trying to print a composition

History

#1 Updated by Hien TRAN-QUANG over 11 years ago

Hello.

I can't reproduce your bug. Exports as images (jpg) are fine for me on my test case. (QGis MASTER a3ea7ce/ Ubuntu 12.04LTS 64bits, size of A0 up to 500 dpi, but really slow over 300dpi).

Can you please tell us what platform/OS you are on and whether you are on 32 or 64bits system. It seems that Qt's qImage does a memory check to avoid memory overflow, which depends on the platform you're on (cf src/gui/image/qimage.cpp of the Qt SDK) and in every case is limited to malloc calls.

So I think this bug is QT-related and not QGIS. Maybe a simple check just like QT's and a messagebox would be enough.

#2 Updated by Regis Haubourg over 11 years ago

Hi,
I'm running OSGEO4W master under windows 7 enterprise 64 bits service pack 1. I remember having the same problem in old master branch with XP machine. I have 16 Go RAM. I hope it's not a QT bug...
régis

#3 Updated by Marco Hugentobler over 11 years ago

  • Status changed from Open to Closed

#4 Updated by Regis Haubourg over 11 years ago

  • Status changed from Closed to Reopened

Threshold is too low. I was able to print a 300 dpi with no problem on A1 paper size, in yesterday's osgeo4w revision. Today with error message, even 150 dpi is impossible. We have a regression and this is now a blocker then ;-)

#5 Updated by Giovanni Manghi over 11 years ago

just for curiosity: isn't this the old issue of printing on Windows? As QGIS on win is 32bit then it can use just 4gb of ram (actually much less) and then priting of large/complex layouts fails. In my experience the same layouts do print ok on 64bit Linux/Mac boxes.

#6 Updated by Regis Haubourg over 11 years ago

  • Assignee set to Marco Hugentobler

Well, not sure if it is the same issue. Old one lead to crash, new one lead to no action. I'm now testing with 64 bit Win 7.. I guess a warning message is necessary, but user should be able to try to export anyway.
Régis

#7 Updated by Jürgen Fischer over 11 years ago

regis Haubourg wrote:

I'm now testing with 64 bit Win 7..

With a 64bit build? Otherwise it doesn't matter if you running on a 32 or 64bit Windows.

#8 Updated by Hien TRAN-QUANG over 11 years ago

The problem is not QGIS but QT ! Presently, exporting an image goes throught QT's memory checks, which depends on the platform (max integer values differ) and the memory (on the heap) available. The error message I introduced only reflects that QT is failing platform tests and/or can't allocate memory for the image. Export can't be done.

To get over QT's memory check needs a complete change in image export (use of imagemagick if QT fails ?)

#9 Updated by Regis Haubourg over 11 years ago

Hi, tested today, and i could export 220 dpi - A1 with no problem. A1 - 300 dpi raised a message (see attached screenshot).
As I could export in 300 dpi on the same platform some days ago, before the revision adding that message, could we just add a "continue anyway" button? it seems that QT test are a bit pessimistic.
Cheers
Régis

#10 Updated by Hien TRAN-QUANG over 11 years ago

Sorry, but a "Continue" button won't do anything. We cannot presently rewrite QT source code (even if it would be useful as for SVG export).

Maybe the only way to sort it out for now is for Osgeo4W to build QGIS with a greater HEAP/other linking options.

#11 Updated by Regis Haubourg over 11 years ago

Hi,
sorry I probably missed something, I thought error message was raised on QGIS side to prevent possible error on QT image export. Any idea of a possible solution in new Qt version.. Not being able to export 600 dpi for printing will be a great blocker for professionnal users.
cheers,
régis

#12 Updated by Hien TRAN-QUANG over 11 years ago

The problem is that QT (4.8 or 5.0) does not raise any error if it can't create the image export. It just returns a NULL object. That's why in the first ticket, there was no action. The warning message in QGIS just tells the user that his computer configuration cannot export the image (memory or max integer issue).

And since this revision, other features/revisions may have used some more memory.

Is exporting a 600dpi PDF or building your own QGIS from source a possible workaround ?

#13 Updated by Regis Haubourg over 11 years ago

Why building QGIS from source could solve this?

#14 Updated by Hien TRAN-QUANG over 11 years ago

You can specify a different value for heap/stack size, large data flags (see http://msdn.microsoft.com/en-us/library/aa366778%28v=vs.85%29.aspx)

I don't have a windows build environment for now, so I can't test those parameters.

#15 Updated by Regis Haubourg over 11 years ago

  • Status changed from Reopened to Closed

Ok thanks, this issue could be solved by an official 64 bit build, discussed today in the lists.
I think issue can be closed then, I will probably fund a part of a 64 bit release.
Tanks a lot for your answers.
Régis

#16 Updated by Giovanni Manghi over 11 years ago

  • Category set to 33

#17 Updated by Giovanni Manghi over 11 years ago

regis Haubourg wrote:

Ok thanks, this issue could be solved by an official 64 bit build, discussed today in the lists.
I think issue can be closed then, I will probably fund a part of a 64 bit release.

Waiting for an eventual solution thanks to a 64bit build for Windows, I still see crashes on Windows and blank PDF on 64bit Linux, using on the latest master revision:

The attached project is made of a hand full of Spatialite vectors, no fancy symbology, no labels.

Printing as vector works up to A0 and 600dpi.

Printing as raster causes QGIS to crash printing in A0 at 300 dpi (works at 250) and printing in A1 at 450 dpi (works at 300).

Printing as raster (A0 600dpi) fails also on Linux, but instead of crashing it produces silently a blank pdf.

#18 Updated by Stefan Blumentrath about 11 years ago

The GarminCustomMap plugin is facing a similar problem (e.g. #5077) when directly importing the mapCanvas, I think.
Like Hien suggests, I tguess it is (at least partly) a Qt issue (see also: http://stackoverflow.com/questions/13574670/problems-with-large-qimage).

However, A0 with 600 DPI is a little less than ca. 20,000 x 30,000 pixels (300 DPI would be 10,000 x 15,000 pixels), which is below Qt`s hard limits (32,768 x 32,768 pixels).

Also, using an image-format with a lower color-depth might help a bit (e.g. QImage::Format_RGB555 instead of QImage::Format_ARGB32) When exporting a QImage.

When directly exporting from mapRenderer even my old 32bit Ubuntu Laptop with 1GB memory manages to export a QImage of 20,000 x 15,000 pixels (Format_RGB555) to PNG.

Also available in: Atom PDF