I am using QSplashScreen to display a splash screen for my QtQuick 2 application. I am using a decent quality image (838 X 500). It displays correctly in some screen resolutions. But for some other resolutions like 2K resolution, it looks like some low quality transformation is applied.
Already tried Qt::SmoothTransformation
Connecting my laptop to my monitor (I have 2K monitor) and selecting 'Duplicate display' option in display management, produces low quality image. Selecting 'Second screen only' produces decent quality image.
QPixmap pixmap(qApp->applicationDirPath()+"/splash.png");
QSplashScreen splash(pixmap.scaledToWidth(screen_width*0.35,Qt::SmoothTransformation));
splash.show();
Is there a way to display an image without loosing the quality?
I am experiencing the same issue with 'Image' in QML.
If Qt is attempting to render the image at the same "physical" size on a higher resolution display, then it will have no choice but to upscale the image. You should provide a higher resolution image:
https://doc.qt.io/qt-5/scalability.html#loading-files-depending-on-platform
The target platforms might automate the loading of alternative
resources for different display densities in various ways. On iOS, the
#2x filename suffix is used to indicate high DPI versions of images.
The Image QML type and the QIcon class automatically load #2x versions
of images and icons if they are provided. The QImage and QPixmap
classes automatically set the devicePixelRatio of #2x versions of
images to 2, but you need to add code to actually use the #2x
versions:
if ( QGuiApplication::primaryScreen()->devicePixelRatio() >= 2 ) {
imageVariant = "#2x";
} else {
imageVariant = "";
}
Forget the part about iOS - I think it's outdated, because it has applied to all platforms for a while now.
So in your case, you should add a splash#2x.png that is twice the resolution (and detail) of splash.png. If you're just using QPixmap, you will need to add the code above to ensure the correct image variant is selected. If you're using QML's Image type, it will select it automatically.
Related
I'm trying to adjust button width depending on the current language that is set in comboBox. For some language like spanish some of the texts are just too long to be fitted into PUSHBUTTON. All controls are in .rc file. To calculate PUSHBUTTON width I'm using RECT (rect.right - rect.left) and to calculate text widht I'm using GetTextExtentPoint32W but unfortunately this method is giving me different values depending in what PC is running. In my laptop where resolution is set to 1920x1080 and scalling100% (recommended is 125%) text width is around 25% bigger than in PC with the same configuration
It depends on the Device Context which may be different across PCs.
Also, you need to be DPI-Aware (since your scalling is not 100%) and GDI isn't.
Suggestion: move to Direct2D.
I made an MFC app for my friend using VS2015 in Win10. It looks like this, which is exactly the same as in resource editor.
.
But when he ran the app on his computer in Win7, the Bitmap image in Picture Control enlarges and covers up some text boxes below, which looks like this.
.
After I searched and realized it may be related with DPI awareness. I disabled DPI-Awareness in property page of Manifest Tool and rebuilt. The same thing happened even when it runs in Win10.
Could someone help me explain the cause of this and find a solution to fix the size of the image control? Thanks.
The main problem is that a dialog from a resource is always measured in DLUs.
And DLUs are calculated from the size of the font, that is used for the dialog.
See this article how dialog base units are calculated.
Now you have a static picture control that is sized in DLUs. The bitmap is just scaled in pixels and is never resized, when you assign it to a static dialog control. And because the real size of the static control depends on the used font, you get different layouts for your dialog and your bitmap.
And because just the font changes when you choose no DPI awareness and because the font changes from windows version to windows version your dialog always look different.
Advice: Paint you picture your own and stretch it accordingly.
Also this stackoverflow question is nice documents and shows the effect of DLUs.
And here some code for auto sizeing picture controls.
An auto-sizing bitmap picture control
A simple image preview class using GDI+
CxImage
Normally, I prefer to keep control in my hand by using SetWindowPos() to set the size of image I want in different situations. You can use below two lines to control/set position and size of your image.
Assume ID of the Picture Control is IDC_STATIC2 then you can use like:
CStatic * pStatic = (CStatic *) GetDlgItem(IDC_STATIC2);
pStatic->SetWindowPos(NULL,20,20,50,50,0);
I am using OpenCV on iOS to detect a rectangular label to assist users in snapping a photo of that label. I have an overlay that presents once the matches threshold is met.
My question is, does that patch image used have to be exact? The labels I am detecting have text on them that vary from label to label. All the same font but different characters. Is it possible to train OpenCV with a patch images color and/or size/dimensions? Or is there perhaps another way around this issue?
Here is a close example to the labels Im scanning, EXCEPT THERE ARE NO ICONS AND ALL ONE FONT TYPE.
Here is the tutorial I am following, which is achieved with an image of a target. http://www.raywenderlich.com/59999/make-augmented-reality-target-shooter-game-opencv-part-3
I have a CListCtrl control (or a ListView in Win32) that is created with LVS_REPORT style.
I am intending to display icons in its items as such:
But the question is what size of icons do I need to make and load?
Let me explain. From the old Win32 samples, I can see that everyone creates image lists with 15x15 pixel icons. But the issue with those is that it looks horribly pixelated on any modern PC with higher DPI settings. Thus I was looking for a dynamic way to determine the appropriate size of image lists for the CListCtrl.
And also the first part of the question, what icon size should I make originally?
EDIT
PS: Since DPI scaling came up, how do you find it out? I'm currently using the following approach:
//No error handling for brevity
HDC hDC = ::GetDC(hAppsMainWindowHandle);
int nCx = ::GetDeviceCaps(hDC, LOGPIXELSX);
int nCy = ::GetDeviceCaps(hDC, LOGPIXELSY);
::ReleaseDC(hAppsMainWindowHandle, hDC);
//I technically get horizontal & vertical scaling --
//can those be different?
double scalingCx = (double)nCx / 96.0; //1.0 = 100%
double scalingCy = (double)nCy / 96.0;
Is font scaling something different?
A list view uses a "small" or "large" image list depending on its mode. In report mode, it uses the "small" image list. You can use GetSystemMetrics() to get the dimensions of "small" images using the SM_CXSMICON and SM_CYSMICON metrics (use SM_CXICON and SM_CYICON for "large" images).
Note that the returned values will be virtual/scaled if your app is not DPI-aware, so to get accurate values, make sure it is DPI-aware via SetProcessDPIAware(), SetProcessDpiAwareness(), or a DPI manifest.
Update: I just ran across this function, might be useful for you when writing a DPI-aware app:
LoadIconWithScaleDown()
Make larger images and let the API scale them down to smaller sizes.
The report style list view wants small icons, that is icons with SM_CXSMICON by SM_CYSMICON metrics. Assuming your app is high DPI aware, then the actual value of these metrics depends on the user's chosen font scaling or DPI setting. So up front you cannot know what size icons should be used. You have to query the system metrics at runtime, and use appropriately sized icons.
Now, what size icons you include in your executable depend on what DPI settings you wish to support. Back in XP days you could reasonably expect to encounter 100% and 125% font scaling. These days, high density display panels are common and you really need to support larger ratios. At least 150% and 200%, and quite probably 175%.
The closest I can find to guidelines is in this MSDN article: http://msdn.microsoft.com/en-US/library/windows/desktop/dn742485.aspx
This article was written around the Vista time frame and already shows its age. I think you have to use these articles as a guide and adapt to the hardware of the day.
You will also find that people run their machines at font scaling values in between the round numbers listed above, and in the article I link to. One of my colleagues runs at 120%. Interestingly this has highlighted various bugs in our code so it's always useful to have someone dog-fooding your program.
When you build your image lists at runtime, size them according to system metrics. And try to avoid scaling icons. For instance, if system metrics suggest an 18px icons, and you only have 16px and 20px icons, then make a new 18px icons. Fill the image with transparent pixels, and blit the 16px icon into the middle of this 18px image. Make the icon out of that. This approach will avoid aliasing problems.
I created QPropertyAnimation and connected it to my SonogramWidget that scroll a long picture vertically on animation events. The 'long picture' is composed of 100 pre-calculated QPixmap objects 1024x128 placed one after another vertically. They displayed in SonogramWidget::paintEvent() with QPainter. Drawing procedure paint not all QPixmap at once, but only visible of them, considering widget height and current vertical offset. CPU is almost free, because QPixmap is a fastest way to display a picture. There is no big calculations during scrolling, because all the 100 QPixmaps are pre-calculated and stored in memory.
I see strange effect: pulsating movement: 2 times a second the entire image slightly speed-up and moves up by 1..2 pixels faster than usual motion. The same effect when i replace Qt Animation Framework with single 60 fps QTimer and scroll the image in its SLOT.
Video: http://www.youtube.com/watch?v=KRk_LNd7EBg#t=8 (watch from 00:08; My firefox adds more chopping to video playing itself, google chrome plays the video much better).
I see the same effect for my Linux and Windows build.
SOLUTION
i figured out the issue: the "chopping" was not a bug, it was a feature! It is a feature of integer-number calculations, so sometimes we had to have different numbers for animations, like: 16,16,16,16,16,16,17,16,16,16,16,16,17,....
In the paintEvent add the following assert:
Q_ASSERT(m_animation->currentValue() == m_animatedPropertyValue);
If it triggers, then you know you must use currentValue() instead of the property value. This might be the case. Let me know.