I need to compare the quality of streaming between Linux desktop server and an Android client. So I have two images one from Linux server and the other one from Android client and they have different resolution.
My question is how to calculate SSIM between these two images (I do not need CODE just a direction to the solution). I already have SSIM code in c++ but it will compare between similar resolutions.
THANKS
What you are trying to achieve is not entirely straight-forward. Comparing the objective quality of two images of different resoluition using a metric like SSIM is ill-defined. This is due to a plethora of factors, among the foremost being:
a) Sampling-related, where the comparison of a number of samples in the reference image against a subset of those samples in the downscaled (degraded) image is not particularly meaningful (how do you compare something against nothing?)
b) Due to characteristics of the human visual system, most notably the contrast sensitivity function, which in this case can be summed up as that a human observer will perceive the lightness of the samples differently, due to differing spatial frequencies.
What the way forward is here depends on the actual problem formulation, which is not clear. What is it exactly that you are trying to measure? If you are measuring the quality of a resampling algorithm, that is something for which SSIM is not an appropriate metric. If you are trying to measure the relative quality of two different image sets, then the obvious answer is to create two uncompressed images at the different resolutions, encode and measure them separately, and compare their respective SSIM values.
Do note that the original SSIM does not account for various HVS properties which would come into play, any you may be better off trying to find a different metric. Also, in case you mean to measure the quality of a stream (i.e. video), SSIM is not particularly performant.
You could use this workaround:
Scale down the bigger image to match the resolution of the smaller image.
After the scale down you can compare the images with the SSIM
Related
Regarding Android's call to provide multiple versions of a bitmap/image, why can't only the highest resolution image be used?
E.g if the xxhdpi image is available - will that be able to scale down to all lower density versions or will it just mean it will scale bigger than the allocated size (View)?
PS: If I'm using a background image, does scaling matter? E.g. should I still provide multiple versions of 1 image to fit different pixel densities?
Usually image scaling operation is resourceful and the outcome might be worse than using pre-scaled image.
It has already been answered several times, but I will answer it again. Btw I'm not myself a big pro in Android, but I will try to answer in the best way possible.
Automatic scaling is a thing in Android, but using that is a waste of resource, we already know that using a PNG Graphic asset is a waste of CPU/GPU power when we can use XML for basic designs (which uses less resources), so why waste more power for downscaling it (which increases app opening time and makes it laggy), simply creating multiple sized images for different display sizes is the best option.
A simple and convenient option is to use a free software like Adobe XD which supports export into different sizes.
Simple answer: Avoid using PNG(or other image format), but when you don't have other options do create multiple sizes to save resources.
A lot of different questions were asked around the question "How to deal with Textures for different devices in Libgdx". I would like to summarize information here and ask what is not clear for me still.
Tips for the good quality of Textures:
Forget about the approach to build huge Textures with transparency. RAM will be destroyed on low devices. explanation
Use Viewport. Aspect Ratio for Textures will look the same for each device. explanation
Avoid raw textures. Apply the TextureFilter. explanation
Use AssetManager. It allows you to load, dispose, make screen loading progress in the easiest way. example
Use different resolutions for different devices. Use ResolutionFileResolver. It allows Libgdx automatically to choose the most appropriate Texture for each device. example
Note: feel free to add ideas to this list
The question is about the last point. Android platform has a huge amount of different phones and tablets. I understand that it doesn't make sense to create each Texture for each Resolution.
How many resolutions to cover separately? I suppose to take 3 categories: for lower, middle and high devices.
If so - how to choose the most appropriate one for each category?
Are there any cases to use the same Texture somewhere? (small icons, HUD, etc)
We started using vector drawables in our Android application.
I have read about performance issues faced while using raster images in android applications.
Can anyone explain the reason why there is a performance issue ?
Is it okay to use plenty of vector drawables in an application ?
Thanks in advance !!
This isn't really android specific. It's more to do with different image formats. A raster image has a "fixed" size, in the sense that it is always comprised of the same number of pixels, which is one of the major factors in file size (and memory footprint once it's loaded). This also affects your ability to transform the image.
If you want to shrink a raster image, you have to drop pixels, which is necessarily a lossy transform (even though the smaller size makes it difficult or impossible to notice the lost data). To enlarge the image, you have to interpolate pixels: add data that wasn't there in the original image, which means the image will start to pixelate.
With a vector image, on the other hand, the data stored is not in terms of pixels. Instead it stores "paths" that instruct the computer on how to draw the image. These paths are size-independent, which means that its size can be increased or decreased with no loss of data or image quality. Since the size doesn't matter, only the data necessary to hold the paths (and other data) is stored in a vector image file. This means that the file is (generally) much smaller than the equivalent raster image and so takes up less memory when loaded.
Using a vector will mean your app takes less memory and is more easily adaptable to different screen sizes because android can shrink/expand your graphics to fit without losing any quality.
Raster graphics have more complexity to support images that cant be easily convert vectors like shapes. The technique behind raster graphics are uses pixels unlike vectors uses lines as we know path in Android.
So that raster images have more path elements that represents pixels. Android generates images by using these elements. Complex vectors are takes more time when trying to be generated instead loading a given bitmap.
As i know, You shouldnt be able to use raster in Android. It only supports vectors.
Good luck
Emre
So, we're developing a game and the artist asked in what resolution is he supposed to prepare the graphics.
I've done some research
http://developer.android.com/guide/practices/screens_support.html
developer.android.com/about/dashboards/index.html
and from what I gather I should ask him for 1920x1200 resolution graphics, and then
from these I can prepare graphics for lower resolution devices.
That would be a major screw-up if I asked him for wrong resolution art so I want to make sure.
Is that the case ? When he does these 1920x1200 graphics, am I going to be able to produce all the other popular sizes/resolutions with no problem ? My biggest fear are ratio differences.
Thanks.
If clipping isn't a concern, you can use 1920x1200. However, you'll have to do some editing for different aspect ratios, like you guessed.
I would create a large one for each target aspect ratio, if that is your concern. The most common ones are probably 16:9, 15:9, 4:3, but you might want to do some research on what your focus devices are.
If you have one in each aspect ratio, it makes scaling easier. However, the artists I've worked with generally provide me more than that, since a general scale doesn't always look good in a l/mdpi setting. They normally work with vector graphics for the base images, and then can scale to whatever resolution and put it in a raster format. You might want to ask your artist about that, though, since I'm not much of an expert on it. All I know is he sends me pretty pictures in many different resolutions.
All in all, though, aspect ratio isn't very important for most graphics. A fullscreen background, maybe, but all your UI components should be fine with just an mdpi/hdpi/xhdpi version.
Please use larger graphics. The accepted answer is alright for year 2013 when it was posted, but there are devices with 2560x1600 now and graphics don't look sharp and crisp on them.
If you want to support everything properly and make your life easy, ask the artists to supply everything in at least 2733x2134 pixels (for fullscreen images like backgrounds, etc.) You can use smaller sizes for sprites (just calculate which percentage of the screen it would occupy).
BTW, that 2733x2134 might look odd, but it was carefully calculated. See the details here:
http://bigosaur.com/blog/31-android-resolutions-definite-answer
I understand that Andengine gives us option to scale our scene to any size screen that the user may have.
My question is if it would be better to develop for a larger resolution, say 1280/800 and scale it down for smaller screens OR to go for smaller resolution, say 800/480 and scale it up on bigger screens?
I did try to test this in a sample game by developing it for 1280/800 and scaling down (by ratioResolutionPolicy) to 800/480, and the results weren't satisfactory, there was stutter every here and there the framerate on the debugger though showed 60+. Is it bad programming on my part or does it have to do with the scaling down of the pixels, should I develop for smaller screen and scale it up?
I guess it depends on what kind of graphics you are using.
Say, for example, you want to create something in a retro-gameboy-pixel style, then it makes more sense to use small images and develop for a small resolution (like 480x320). Pixel graphics can be scaled up without loosing quality, but not down (then the pixels loose form).
But if you want high resolution graphics you are most likely better of developing the whole thing for a big resolution and let the AndEngine scale it down.
In both cases the quality of the pictures also depends on the TextureOption of your TextureAtlases as well.
Anyway, I can imagine that neither scaling down, nor scaling up is more efficient. Scaling is done by openGL and should go quite quickly. The downside of using big resolutions though, is that the device has to hold huge images in it's memory and the of course processing big images always takes more time than processing small images. So maybe the best way is to develop for middle-size devices (e.g. 960x640) ?
I know this isn't much help, unfortunately it is a lot of try and error to get the best results for your specific requirements.
christoph
To achieve good result on all type of android device you have two ways to follow from my perspective.
First, you have to develop and use two graphics to handle all the type of devices. For example one with resolution 1024x600 and other with 480x320. Based on device current resolution you have to load specific one type of graphics.
Second, you choose any single resolution that best suits to you and have great share in the market. Develop and use graphics only for that resolution. For other resolution scale that graphics based on aspect ratio. For this you have to create super class of sprite and change value of x,y,height and with based on aspect ratio calculate.
This was my experience that I share with you. If you have any doubt then feel free to ask it.