AW: [Qgis-developer] Raster rendering difference tracked down

Hugentobler Marco marco.hugentobler at karto.baug.ethz.ch
Thu Jul 17 16:03:31 EDT 2008


Hi Peter, Tim and other devs

I found the reason of the failing unit test. 

It basically is because of the usage of the method QgsMapRender::setOutputSize(QSize, int dpi). 

Before the render context branch, the dpi was only used for scale calculation. It had nothing to do with the resolution of the output. And this is correct, because dpi is a property ot the Qt output device, not of QgsMapRender. The output device is already configured and has a painter on it at the time QgsMapRender::render starts its job.
 
With render context branch, the dpi situation is a bit different. There are paint devices where QPainter draws in pixel coordinates (QImage, QPixmap & co). But there is also QGraphicsScene where QPainter draws in logical coordinates (mm in case of print composer). On both types of output devices, QGIS outline width values should be mm and the raster resolution should respect the pixels of the output device. To achieve this, the outline width values are scaled with a factor when drawing to main QGIS canvas (this line scale factor is 1 for QGraphicsView and >1 for main QGIS canvas). On the other side, the rasters need to be scaled when drawing to QGraphicsView to prevent pixels with 1mm squares (this raster scale factor is 1 for QGIS main canvas). Because, as the logical units of QGraphicsView are mm, the dpi is from a vector point of view is 25.4. But the dpi of the output device is of course different. In render context branch, QgsMapRender considers the dpi value passed in the method setOutputSize to be the 'vector dpi' and looks in the QPaintDevice where QPainter is painting on for the 'raster dpi'. It then scales the raster to match the output device dpi.

Therefore, if it is not painted to QGraphicsScene (like print composer does), the dpi value passed to setOutputSize should equal the one of the paint device. And btw, if it is painted to a pixel based device and the value is different, the scale calculation will be wrong. Therefore, line 61 of qgsrenderchecker.cpp should be changed 

from
mpMapRenderer->setOutputSize( QSize ( myExpectedImage.width(),myExpectedImage.height() ),72 );

to 
mpMapRenderer->setOutputSize( QSize ( myImage.width(),myImage.height() ), myImage.logicalDpiX());

With this change, the unit raster tests will pass. I'm also going to add more documentation to QgsMapRender class so it is more clear for developers using this class.
I'm of course also open if someone has suggestions about this.

Regards,
Marco



-----Ursprüngliche Nachricht-----
Von: qgis-developer-bounces at lists.osgeo.org im Auftrag von Peter Ersts
Gesendet: Mo 14.07.2008 16:47
An: QGIS Developer Mailing List
Betreff: [Qgis-developer] Raster rendering difference tracked down
 
Tim and Marco,

Here is a little update. I have tracked down the difference in rendering 
behavior, which is causing the two units tests to fail, to revision 
8440. This was the merge into the trunk of the Render Context Branch. 
More specifically, I believe the difference has to do with the scale 
factors that are being computed in QgsMapRender.cpp.

As it is right now, I will say the test results for the landsat_basic 
looks like it has artifacts compared to the expected result in the area 
being marked as different. However, when you load the original raster 
data for the landsat_basic test and 'Zoom to best scale' the displayed 
result does not exhibit any artifacts. So I think the next logical place 
to start digging around is the QgsMapRender->setExtent() and looking 
more at the scale factors, unless anyone has other ideas.

-pete

-- 
====================================
Peter J. Ersts, Project Specialist
American Museum of Natural History
Center for Biodiversity and Conservation
Central Park West at 79th Street
New York, New York 10024
Tel: Home Office (518)-632-4745 or NYC Office (212)-496-3488
Web: http://biodiversityinformatics.amnh.org
Web: http://cbc.amnh.org

Quantum GIS Raster Development Team. Visit http://www.qgis.org
to learn more about QGIS, a free and open source desktop GIS

Open Source,
...evolving through community cooperation to change the world bit by bit

_______________________________________________
Qgis-developer mailing list
Qgis-developer at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer



More information about the Qgis-developer mailing list