AW: [Qgis-developer] Raster rendering difference tracked down
Hugentobler Marco
marco.hugentobler at karto.baug.ethz.ch
Thu Jul 17 16:58:32 EDT 2008
Hi Tim,
Yes, there should be no need to do scaling yourself in quickprint plugin. QgsMapRender is intended to look at the resolution and convert outline width, symbol sizes and labels automatically. But the units for all this is mm now where it was pixel before, so it will look different with the same settings. Therefore I'm not sure if reverting the control images will work.
>And the maprender can be
>reasonably expected to return 0 outputDpi if the render mode is to a
>graphics scene?
QgsMapRender just gives back the dpi value you entered in setOutputSize (via mScaleCalculator):
void QgsMapRender::setOutputSize(QSize size, int dpi)
{
mSize = size;
mScaleCalculator->setDpi(dpi);
adjustExtentToSize();
}
int QgsMapRender::outputDpi()
{
return mScaleCalculator->dpi();
}
Regards,
Marco
-----Ursprüngliche Nachricht-----
Von: Tim Sutton [mailto:tim at linfiniti.com]
Gesendet: Do 17.07.2008 22:36
An: Hugentobler Marco
Cc: Peter Ersts; QGIS Developer Mailing List
Betreff: Re: [Qgis-developer] Raster rendering difference tracked down
Hi Marco
Ah this sounds like it explains the issues (and kludgy workaround) I
had with quickprint too. In fact I think a large part of the code in
quickprint that tried to scale labels etc for the print device can
probably be dropped if I understand things correctly. If I understand
you correctly, where before I was doing:
//
// Remember the size and dpi of the maprender
// so we can restore it properly
//
int myOriginalDpi = mpMapRender->outputDpi();
//sensible default to prevent divide by zero
if (0==myOriginalDpi) myOriginalDpi=96;
QSize myOriginalSize = mpMapRender->outputSize();
int mySymbolScalingAmount = myPrintResolutionDpi / myOriginalDpi;
Now I guess I can ditch : mySymbolScalingAmount and just call:
void setOutputSize(QSize size, int dpi);
on the maprender (passing it the print device resolution) in the same
way you are suggesting for render checker? And the maprender can be
reasonably expected to return 0 outputDpi if the render mode is to a
graphics scene?
Also it would be interesting to roll back the control image changes I
made for the vector rendering checks and see if they pass with your
suggested change to renderchecker (I felt I was cheating a little bit
changing the expected output to make the vector tests pass :-P ).
Regards
Tim
2008/7/17 Hugentobler Marco <marco.hugentobler at karto.baug.ethz.ch>:
> 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
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
--
Tim Sutton
QGIS Project Steering Committee Member - Release Manager
Visit http://qgis.org for a great open source GIS
openModeller Desktop Developer
Visit http://openModeller.sf.net for a great open source ecological
niche modelling tool
Home Page: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
More information about the Qgis-developer
mailing list