Problems with QwtPlotRenderer from Qwt 6

[Uwe]

It is a fact that the axes/labels are getting smaller with increasing resolution. To proove it, I uploaded the original output image to an image hosting service:

This is an image with a size of 3543x2362 pixels.

When I press 100% in my image viewer ( here gwenview ) my screen is too small to show the plot at once, but - when scrolling - the labels perfectly match to the size of the labels in the plot widget. When I enter "fit to page" the labels are tiny - but this no surprise, when you scale the image heavily down.

Increasing the resolutions leads to larger images. You will have to scroll more, but the labels will keep their size in 100% - and of course the image will be scaled even more in "fit to screen" mode.

I just changed line 216 of the mainwindow.cpp from the bode example and entered 300 dpi instead of 85 dpi. It is clearly visible that the axes are so small that they are barely visible if the whole image displayed on screen. Is this the desired behaviour of the function?

You told the renderer, that you want an image with 300dpi for a size of 30*20 cm. On a device with such metrics (maybe a printer) you will see the labels displayed in a very similar size as on the plot on your screen.

Again: a scalable vector graphics format is what you are looking for - and this is what the new double based render engine of Qwt 6 is made for.

Uwe

[mariposa]

When I press 100% in my image viewer ( here gwenview ) my screen is too small to show the plot at once, but - when scrolling - the labels perfectly match to the size of the labels in the plot widget.

Yes, this is not my problem. But the height/width (x-axis/y-axis) of the axis in pixels stays the same - no matter what resolution I use. That makes the axis very small on high resolutions. This was not the case using Qwt 5.

Again: a scalable vector graphics format is what you are looking for - and this is what the new double based render engine of Qwt 6 is made for.

I am very sorry to ask this over and over again and probably I am just missing something very basic, but I am not sure whether I explained my intentions in an understandable way.

My application is supposed to support exporting the plot in several graphic formats. On the one hand vector graphic formats (svg and png), and on the other hand pixel graphics (currently png and jpg).

Since not all applications support embedding pdf or svg images (for example Microsoft Word), I need the user to be able to export jpg/png images in a high resolution for printing the plot. I already realized this successfully using Qwt 5 by asking for the desired width/height of the output image in pixels. I created then a QImage with these dimensions and used the print() function to render the plot on that QImage.

The result was an image with the aspect ratio width/height. Even with very high resolutions (lets say 3000*2000 pixels on A5 paper) the axes were very well readable when printed. If always printed on the same paper size, the axes always had the same height/width, no matter what resolution was chosen.

If I now use Qwt 6 and set the resolution to a value so that the resulting image has similar dimensions (3000*2000 for example) I get much too small axes. The image is not usable for printing any more.

I know that SVG/PDF suits the need for printing better, but I want the high-res pixel output to work the way it was possible with Qwt 5.

Please excuse my insistent asking, but I really don't have a clue how to achieve the desired result.

[Uwe]

Yes, this is not my problem. But the height/width (x-axis/y-axis) of the axis in pixels stays the same - no matter what resolution I use. That makes the axis very small on high resolutions.

When you are talking about the tick labels read my comments above. If it is about the length of the axis backbones: they are increasing together with the size of the image ( more than 3000 pixels for the x axis in your uploaded image ).

This was not the case using Qwt 5.

Qwt 5 has a method like QwtPlotRenderer::render(), but something like renderDocument with metrics related to the real world simply doesn't exist. So this is obviously wrong.

I am very sorry to ask this over and over again and probably I am just missing something very basic, ...

Obviously.

When you render a plot in a size of 30x20 cm and a resolution of 300dpi to an image it means, that all text labels, symbols etc appear in the same size ( test it with the ruler on your desk) as on the screen, when you display the image on a device with exactly these metrics.

The image itsself only has a width/height in pixels, but this has nothing to do with cm or dpi ( inch !), what are sizes of the real world.

Uwe

[Uwe]

When you render a plot in a size of 30x20 cm and a resolution of 300dpi to an image it means, that all text labels, symbols etc appear in the same size ( test it with the ruler on your desk) as on the screen, when you display the image on a device with exactly these metrics.

What's not the case - o.k. now I have understood what you mean.

Uwe

[mariposa]

Unfortunately, there is a misunderstanding of my problem.

When you render a plot in a size of 30x20 cm and a resolution of 300dpi to an image it means, that all text labels, symbols etc appear in the same size ( test it with the ruler on your desk) as on the screen, when you display the image on a device with exactly these metrics.

Yes, I absolutely agree. This is exactly the behaviour of the renering function. But this is not the behaviour I need. To illustrate my problem, I exported the plot as pdf file with a paper size of 18*15,32 cm. If I print this, everything is fine because it is a vector graphic. No pixels visible.

Now I used the standard Mac OS X viewing application ("Preview") and saved the pdf file as jpg file. "Preview" (of course) asks for a resolution for the output file, because the page dimensions of the real world need to be converted to pixels. First, I set the value to 72 dpi:

http://img28.imageshack.us/img28/4976/97755256.jpg

If I print this image with the same real world dimensions as the pdf, I get (of course) a pixelated printout. The resolution is too small.

Now I used the very same pdf and saved it with a resolution of 300 dpi as jpg:

http://img638.imageshack.us/img638/2135/300xj.jpg

If I print this image with the same real world dimensions of the pdf, I don't see any pixels, because the resolution is sufficient.

Now I want the user to be able to export the plot as jpg like you can see it in the second link.

Qwt 5 has a method like QwtPlotRenderer::render(), but something like renderDocument with metrics related to the real world simply doesn't exist. So this is obviously wrong.

The image in the second link has a resolution of 2125*1809 pixels. If I rendered the plot to a QImage of the same dimensions using the old print() function, the output looked exactly as in my second link. Now (Qwt 6) the image looks as if I made a screenshot of my application when viewed fullscreen on a monitor with 2125*1809 pixels. And that is definitely not the result I need.

Und nur um ganz sicher zu gehen nochmal auf Deutsch zwischen uns Landsmännern:

Mir geht es nicht darum, dass irgendwelche Achsen zu kurz oder zu lang sind. Und ich weiß auch was dpi sind und dass Pixelgraphiken lediglich eine Höhe und Breite in Pixeln haben und die Auflösung erst dadurch entsteht, dass man es in einer bestimmten Größe darstellt. Ich habe mit der print()-Funktion exzellente Ergebnisse erzielt, habe den Code auf Qwt 6 portiert und bin nun nicht mehr in der Lage das zu reproduzieren.
Ich konnte direkt aus meinem Programm das Bild so exportieren wie du es in meinem zweiten Link siehst. Und das bekomme ich ohne den Umweg über ein externes Programm nicht mehr hin.

Es tut mir wirklich leid, dass ich so penetrant nachfragen muss, aber ich komme der Problemlösung einfach nicht näher.

[Uwe]

Ich habe mit der print()-Funktion exzellente Ergebnisse erzielt, habe den Code auf Qwt 6 portiert und bin nun nicht mehr in der Lage das zu reproduzieren.

It's more important to the right thing as to do what Qwt 5 does - nevertheless I modified the bode example in Qwt 5.2 with the following code:

QImage image(3543, 2362, QImage::Format_ARGB32);
image.fill( QColor( Qt::white ).rgb() );
plot->print(image);
image.save( "bode300-52.png" );

QImage image(3543, 2362, QImage::Format_ARGB32);
image.fill( QColor( Qt::white ).rgb() );
plot->print(image);
image.save( "bode300-52.png" );

To copy to clipboard, switch view to plain text mode 

The result is the same as with Qwt 6. What exactly was the code, that gave you those excellent results ?

After updating SVN trunk ( painter transformation were killed before ) you could try the following code:

const double scaleFactor = 4.0;
const QSize sz(3543, 2362);
 
QImage image(sz, QImage::Format_ARGB32);
image.fill( QColor( Qt::white ).rgb() );
 
QPainter painter(&image);
painter.scale(scaleFactor, scaleFactor);
 
QwtPlotRenderer renderer;
renderer.render(d_plot, &painter, QRectF( QPointF(0, 0), sz / scaleFactor ) );
image.save( "bode.png" );

const double scaleFactor = 4.0;
const QSize sz(3543, 2362);

QImage image(sz, QImage::Format_ARGB32);
image.fill( QColor( Qt::white ).rgb() );

QPainter painter(&image);
painter.scale(scaleFactor, scaleFactor);

QwtPlotRenderer renderer;
renderer.render(d_plot, &painter, QRectF( QPointF(0, 0), sz / scaleFactor ) );
image.save( "bode.png" );

To copy to clipboard, switch view to plain text mode 

Is this what you want ?

Uwe

[mariposa]

After updating SVN trunk ( painter transformation were killed before ) you could try the following code:

Is this what you want ?

Many many thanks for your efforts. Unfortunately - even after the SVN update - the exported image is not correctly scaled and the plot is just occupying the upper left quarter.

But I understand how your code works and the effect will probably be very similar to using setDotsPerMeterX/setDotsPerMeterY from QImage.

But this will (as far as I can see it) have the disadvantage that the number of curve points is determined by the size of QRectF( QPointF(0, 0), sz / scaleFactor ). These points are then stretched to the "full" resolution. My tests using setDotsPerMeterX/setDotsPerMeterY resulted in a curve that has visible "steps" and I assume this will also be the case for your proposed solution.

Regarding the code I used successfully with Qwt 5:

When I used Qwt 5 for my project, my code was not yet under revision control and I have overwritten the old parts, therefore I don't have the "original" any more. Until now all efforts to reproduce the "desired" behaviour using Qwt 5 were so far not successful (I know, this is embarrassing). I will go on trying and as soon as I get it working, I will post the code here.

Until I find an acceptable solution for the pixel graphic output I will deactivate these export functions and follow your advice to only offer pdf/svg as graphic format.

[Uwe]

Unfortunately - even after the SVN update - the exported image is not correctly scaled and the plot is just occupying the upper left quarter.

Replace the implementation of MainWindow::exportDocument in the bode example with the code I have posted and check the result. Then try to find out what you are doing wrong in your application.

But this will (as far as I can see it) have the disadvantage that the number of curve points is determined by the size of QRectF( QPointF(0, 0), sz / scaleFactor ). These points are then stretched to the "full" resolution.

No, not with the double based render engine of Qwt 6.

My tests using setDotsPerMeterX/setDotsPerMeterY resulted in a curve that has visible "steps" and I assume this will also be the case for your proposed solution.

When painting to a paint device, that is aligning to integer coordinates (like a QWidget or QImage), Qwt manually rounds certain coordinates - instead of letting Qt floor them. Unfortunately this rounding is based on logical coordinates - not respecting the scale factor of the painter. But this is a bug - not a problem in general.

When you modify the implementation of QwtPainter::isAligning like below you might have some effects because of the flooring but it should be very close to what you expect.

bool QwtPainter::isAligning( QPainter *painter )
{
    if ( painter && painter->transform().isScaling() )
        return false;
 
    ...
}

bool QwtPainter::isAligning( QPainter *painter )
{
    if ( painter && painter->transform().isScaling() )
        return false;

    ...
}

To copy to clipboard, switch view to plain text mode 

Uwe

PS: Forget about trying to find your code for Qwt5 - you won't succeed. Better try to support the development of Qwt 6

[mariposa]

Thank you very much. At first it did not work because (for some reason) after the last SVN co only debug libraries of Qwt were built and therefore the bode example was still linked against the "old" release libraries. But after I modified qwtbuild.pri it worked as expected.

The result looks the way I want it and after modification of the QwtPainter::isAligning function the "steps" are indeed gone.

Unfortunately two issues are remaining:
1) The scaling factor needs to be adjusted according to the desired resolution in order to get reasonably sized plot elements. But it hopefully won't be too difficult for me to find a suitable formula...

2) The text lables in the resulting graphic look a little bit odd:

screenshot_text.png

And the thickness of the lines of the axes (and the grid) doesn't seem to get adjusted. The resulting lines seem to be a little too thin for printing.


Update: I found a way for getting rid of the scaling factor. In my project I successfully use the following code to generate pixel images that can be of any resolution and always look the same when displayed in the same "real world" size:

const double toInch = 1.0 / 25.4;               //convert mm to inch
 
//the user is asked for setWidth and setHeight (intended "real world" size in mm)
const QSizeF size = QSizeF(setWidth, setHeight) * toInch * setResolution;
const QRectF documentRect( 0.0, 0.0, size.width(), size.height() );
const qreal toDPM = 1.0 / 0.0254;
 
const QRect imageRect = documentRect.toRect();
QImage image( imageRect.size(), QImage::Format_ARGB32 );
 
//the selected resolution (setResolution) is converted to DotsPerMeter
image.setDotsPerMeterX(setResolution * toDPM);
image.setDotsPerMeterY(setResolution * toDPM);
 
image.fill(QColor(Qt::white).rgba()); 
QPainter painter(&image);
QwtPlotRenderer renderer;
 
renderer.render(par->spectrum_plot, &painter, image.rect());
painter.end();
image.save(fileName, format.toLatin1(), setQuality);

const double toInch = 1.0 / 25.4;               //convert mm to inch

//the user is asked for setWidth and setHeight (intended "real world" size in mm)
const QSizeF size = QSizeF(setWidth, setHeight) * toInch * setResolution;
const QRectF documentRect( 0.0, 0.0, size.width(), size.height() );
const qreal toDPM = 1.0 / 0.0254;

const QRect imageRect = documentRect.toRect();
QImage image( imageRect.size(), QImage::Format_ARGB32 );

//the selected resolution (setResolution) is converted to DotsPerMeter
image.setDotsPerMeterX(setResolution * toDPM);
image.setDotsPerMeterY(setResolution * toDPM);

image.fill(QColor(Qt::white).rgba()); 
QPainter painter(&image);
QwtPlotRenderer renderer;

renderer.render(par->spectrum_plot, &painter, image.rect());
painter.end();
image.save(fileName, format.toLatin1(), setQuality);

To copy to clipboard, switch view to plain text mode 

This works so far as intended. Unfortunately, the problem concerning the too thin lines and odd looking texts are still there.

[Uwe]

QwtPlotRenderer calculates and sets internally a scale factor depending on the ratio ( logicalDpi ) between plot and target paint device. While my code combines the scale factor assigned in the application code with this ratio, your code changes the ratio itsself. The effect on the internal scale factor is the same.

Concerning the font I recommend to use a different one - mine looks much better. Concerning the lines you should try to assign non-cosmetic pens ( QPen::setCosmetic(bool) ), where you want to have them scaled like the fonts.

For Qwt6.0.0 I will modify QwtPlotRenderer::renderDocument for images and introduce a flag so that the application can explicitely enable/disable the internal rounding of Qwt. Of course the "right" solution is to round to double values, that match the physical resolution of the target device, but I'm afraid it is too late for Qwt 6.0.0.

Uwe

[mariposa]

Concerning the lines you should try to assign non-cosmetic pens ( QPen::setCosmetic(bool) ), where you want to have them scaled like the fonts.

I've tried to find an easy way to set the pen that is used for drawing the scales, but unfortunately I did not succeed. For the curve and grid it was quite easy (because of the setPen() member function), but I couldn't find something similar for the scales.

Is there an "easy" way, or do I have to subclass QwtScaleDraw and reimplement the drawing functions?

[Uwe]

QwtScaleDraw explicitely disables cosmetic pens. So I'm afraid you have to overload QwtScaleDraw::drawTick and QwtScaleDraw::drawBackbone to set it again - but I'm not sure if you will see some alignment problems then.

Uwe