[Qgis-developer] Unit tests failing - a heartfelt plea

Marco Hugentobler marco.hugentobler at sourcepole.ch
Sat Jun 16 23:31:19 PDT 2012


Hi Radim

>thePaintDevice->logicalDpiX() = 85 thePaintDevice->logicalDpiY() = 86
>      sceneDpi = 96 rasterScaleFactor = 0.890625

Looks like the problem is that, in QgsRenderChecker::runTest, myImage may have different DPI depending on the system (in your case, myImage seems to have 85/86 and myExpectedImage 96). Could you test if it works if you set the DPI of myImage programmatically to 96:

QImage myImage( myExpectedImage.width(),
                   myExpectedImage.height(),
                   QImage::Format_RGB32 );
myImage.setDotsPerMeterX( 96.0 / 25.4 * 1000.0 );
myImage.setDotsPerMeterY( 96.0 / 25.4 * 1000.0 );
...


Like that, rasterScaleFactor
  should be 1.0 on all systems.

>Anybody has idea why rasterScaleFactor is used and how it should work?

rasterScaleFactor is there because in the print composer, units are mm and so in this case, the raster images have more pixels than output units.
But for drawing to QImage, rasterScaleFactor is always 1.

Regards,
Marco



On 16.06.2012 12:53, Radim Blazek wrote:
>> Here it is http://dash.orfeo-toolbox.org/viewTest.php?buildid=87438
>> it looks interesting. In the first raster test called 'raster', some
>> columns are wider, some others are narrower. In following raster
>> tests, the problem may be the same (columns and rows somehow shifted).
> More observations:
> * test raster tenbytenraster.asc size is 10x10
> * output device is set to expected_raster.png size 100 x 100
> * QgsMapRenderer::render is using
>       rasterScaleFactor = ( thePaintDevice->logicalDpiX() +
> thePaintDevice->logicalDpiY() ) / 2.0 / sceneDpi;
>     in this case:
>       thePaintDevice->logicalDpiX() = 85 thePaintDevice->logicalDpiY() = 86
>       sceneDpi = 96 rasterScaleFactor = 0.890625
> * because of rasterScaleFactor, the raster is rendered as 90x90
> instead of 100x100, doing such resampling, it may probably happen that
> certain output column falls to a different data source column
> depending on architecture - it is not clear to me however, how it
> would be possible, it should be all IEEE 754, there is also IEEE
> 754-2008, but I have no idea if it can make difference or if it is
> even implemented in new CPUs. Anyway, we should not usually reach such
> problems.
>
> Anybody has idea why rasterScaleFactor is used and how it should work?
>
> Radim
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux&  Open Source Solutions
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee



More information about the Qgis-developer mailing list