[Qgis-developer] Raster rendering difference tracked down

Thu Jul 17 18:25:35 EDT 2008

Hi

2008/7/17 Hugentobler  Marco <marco.hugentobler at karto.baug.ethz.ch>:
> 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.

Ok no problem I'll leave them as is.

>
>>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):

In the case of quickprint I was doing (in pseudocode)
mapcanvas->getMapRenderer from the screen display canvas and then
repurposing the renderer to do the printing. After printing I was
reinstating the original mapcanvas settings. I guess with the
mapcomposer stuff I wont need to use this slightly kludgy way and can
create a unique maprenderer and then discard it after printing? I'll
probably just leave the quickprint alone until your composer stuff
comes in - I'm looking forward to trying it out!

Regards

Tim

>
> 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
>
>

-- 
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