Just a straight forward question. I´m trying to make the best possible choice here and there is too much information for a "semi-beginner" like me.
Well, at this point, I´m trying with screen size values for my layout (activity_main.xml (normal, large, small)) and with different densities (xhdpi, xxhdpi, mhdpi) and, if a can say so myself, it is a mess. Do I have to create every possible option to support all screen sizes and densities? Or am I doing something really wrong here? what is the best approach for this?
My layouts are now activity_main(normal_land_xxhdpi) and I have serious doubts about it.
I´m using last version of android studio of course. My app is a single activity with buttons, textview and others. Does not have any fragments or intents whatsoever, and for that reason I think this has to be an easy task, but not for me.
Hope you guys can help. I don't think i need to put any code here, but if needed, i can add it.
If you want to make a responsive UI for every device you need to learn about some things first:
-Difference between PX, DP:
https://developer.android.com/training/multiscreen/screendensities
Here you can understand that dp is a standard measure which android uses to calculate how much pixels, lets say a line, should have to keep the proportions between different screensizes with different densities.
-Resolution, Density and Ratio:
The resolution is how much pixels a screen has over height and width. This pixels can be smaller or bigger, so for instance, if you have a screen A with 10x10 px whose pixels are two times smaller than other screen B with 10 x 10 pixels too, A is two times smaller than B even when both have 10 x 10 px.
For that reason exists the meaning Density, which is how much pixels your screen has for every inch, so you can measure the quality of a screen where most pixels per inch (ppi) is better.
Ratio tells you how much pixels are for height as well as width, for example the ratio of a screen of 1000 x 2000 px is 1:2, a full hd screen of 1920 x 1080 is 16:9 (16 pixels height for every 9 pixels width). A 1:1 ratio is a square screen.
-Standard device's resolutions
You can find the most common measurements on...
https://material.io/resources/devices/
When making a UI, you use the DP measurements. You will realize that even when resolution between screens are different, the DP is the same cause they have different densities.
Now, the right way is going with constraint layout using dp measures to put your views on screen, with correct constraints the content will adapt to other screen sizes
Anyway, you will need to make additional XML for some cases:
-Different orientation
-Different ratio
-Different DP resolution (not px)
For every activity, you need to provide a portrait and landscape design. If other device has different ratio, maybe you will need to adjust the height or width due to the proportions of the screens aren't the same. Finally, even if the ratio is the same, the DP resolution could be different, maybe you designed an activity for a 640x360dp and other device has 853x480dp, which means you will have more vertical space.
You can read more here:
https://developer.android.com/training/multiscreen/screensizes
And learn how to use constraintLayout correctly:
https://developer.android.com/training/constraint-layout?hl=es-419
Note:
Maybe it seems to be so much work for every activity, but you make the first design and then you just need to copy the design to other xml with some qualifiers and change the dp values to adjust the views as you wants (without making from scratch) which is really faster.
Related
I have a training dataset of 640x512 images that I would like to use with a 320x240 camera.
Is it ok to change the aspect ratio and the size of the training images to that of the camera?
Would it be better to upscale the camera frames?
It is better if you keep the aspect ratio of the images because you will be artificially modifying the composition of the objects in the image. What you can do is downscale the image by a factor of 2, so it's 320 x 256, then crop from the center so you have a 320 x 240 image. You can do this by simply removing the first 8 and last 8 columns of the image to get it to 320 x 240. Removing the first 8 and last 8 columns should be safe because it is very unlikely you will see meaningful information within an 8 pixel band on either side of the image.
If you are using a deep learning framework such as Tensorflow or PyTorch, there are pre-processing methods to automatically allow you to crop from the center as well as downscale the image by a factor of 2 for you. You just need to set up a pre-processing pipeline and have these two things in place. You don't have any code established so I can't help you with implementation details, but hopefully what I've said is enough to get you started.
Finally, do not upsample the images. There will be no benefit because you will be using existing information to interpolate to a larger space which is inaccurate. You can scale down, but never scale up. The only situation where this could be useful is if you use superresolution, but that would be for specific cases and it highly depends on what images you use. In general, I do not recommend upscaling. Take your training set and downscale to the resolution of the camera as the images from the camera would be what is used at inference and at that resolution.
I am using Perl's
Image::Imlib2
package to generate thumbnails from larger images.
I've done such tasks before with several ImageMagick interfaces (PHP, Ruby, Python) and it was relatively easy. I have no prior experience with Imlib2 and it is a long time since I wrote something in Perl, so I am sorry if this seems naive!
This is what I've tried so far. It is simple, and assumes that scaling an image will keep the aspect ratio, and the generated thumbnail will be an exact miniature copy of the original image.
use strict;
use warnings;
use Image::Imlib2;
my $dir = 'imgs/*';
my #files = glob ($dir);
foreach my $img ( #files ) {
my $image = Image::Imlib2->load($img);
my $cropped_image = $image->create_scaled_image(50, 50);
$cropped_image->save($img);
}
Original image
Generated image
My first look at the image tells me that something is wrong. It may be my ignorance on cropping, resizing and scaling, but the generated image is displaying wrongly on small screens.
I've read What's the difference between cropping and resizing?, and honestly didn't understand anything. Also this one Image scaling.
Could someone explain the differences between those three ideas, and if possible give examples (preferably with Perl) to achieve better results? Or at least describe what I should consider when I want to create thumbnails?
The code you use isn't preserving the aspect-ratio. From Image::Imlib2::create_scaled_image
If x or y are 0, then retain the aspect ratio given in the other.
So change the line
my $cropped_image = $image->create_scaled_image(50, 50);
to
my $scaled_image = $image->create_scaled_image(50, 0);
and the new image will be 50 pixels wide, and its height computed so to keep the original aspect-ratio.
Since this is not cropping I've changed the variable name as well.
As for other questions, below is a basic discussion from comments. Please search for tutorials on image processing. Also, documentation of major libraries often have short and good explanations.
This is aggregated from comments deemed helpful. Also see Borodin's short and clear answer.
Imagine that you want to draw a picture (of some nice photograph) yourself in the following way. You draw a grid of, say, 120 (horizontally) by 60 (vertically) boxes. So 120 x 60, 720 boxes. These are your "pixels," and each you may fill with only one color. If the photo you are re-drawing is "mostly" blue at some spot, you color that pixel blue. Etc. It is not easy to end up with a faithful redrawing -- the denser the pixels the beter.
Now imagine that you want to draw another copy of this, just smaller. If you make it 20x20 that will be completely different, since it's a square. The best chance of getting it to "look the same" is to pick 2-to-1 ratio (like 120x60), so say 40x20. That's "aspect-ratio." But there is still a problem, since now you have to decide all over again what color to pick for each box, so to represent what is "mostly" on the photo at that spot. There are algorithms for that ("sampling," see your second link). That's involved with "resizing." The "quality" of the obtained drawing clearly must be much worse.
So "resizing" isn't all that simple. But, for us users, we mostly need to roughly know what is involved, and to find out how to use these features in a library. So read documentation. Some uses are very simple, while sometimes you'll have to decide which "algorithm" to let it use, or some such. Again, what I do is read manuals carefully.
The basic version of "cropping" is simple -- you just cut off a part of the picture. Say, remove the first and last 20 columns and the bottom and top 10 rows, and from the initial 120x60 you get a picture of 80x40. This is normally done when outer parts of an image have just white areas (or, worse, black!). So you want to "cut out" the picture itself from the whole image. Many graphics tools can do that on their own, by analyzing the image and figuring out those areas. Or, we select and hit a button.
I'm still not certain that you understand the difference between these terms
Your original image is 752 × 500 pixels
Resizing is a vague term that just means making a picture a different size somehow
Scaling is to change the size of an image proportionally. Scaling your picture down by a factor of ten would result in an image 75 × 50 (it should be 75.2 but we can't have 0.2 of a pixel). Scaling it up would make it bigger
You have scaled your picture to 50 × 50 pixels, which is a vertical scale of 10 (500 ÷ 5) but a horizontal scale of 15 (752 ÷ 50), so it appears squashed horizontally (or stretched vertically)
Cropping is to reduce an image by removing parts of it. To crop your image to 50 × 50 you would choose a 50 × 50 rectangle out of the whole picture and remove the rest. It would be a piece about the size of your monkey's nose, but you can pick any region you wish
zdim has shown you how you can call
$image->create_scaled_image(0, 50)
so that the height, or y-dimension, is reduced to 50, while the width, or x-dimension, is scaled by the same factor. That will result in a thumbnail 75 × 50 as above
I hope that helps
As I said in my comment, there is an
Image::Magick
Perl module if you would prefer to be back on familiar ground
Resizing and scaling is the same; you just change the size of the image. You can make it smaller or bigger.
Depending on the interface, you have to give either the new dimensions or a scaling factor for the operation. A factor less than or greater than 1.0 would make the image smaller or bigger. Smaller images are created by subsampling and bigger images by interpolation.
Cropping is very simple. You select a rectangular region of an image and that's your new image. It's like using scissors.
In your code example the image is named cropped_image although it is created through scaling, or resizing.
The output image is an image of size 50 x 50 pixels. That's what you did here:
my $cropped_image = $image->create_scaled_image(50, 50);
So no matter how your image looks before, you stuff it into 50 x 50 pixels. In this case not only reducing the resolution but also changing the aspect ratio.
The image is not displayed improperly, it's displayed perfectly fine.
On Mac OS X, I need to convert a point measurement to pixel measurement.
The formula which I know is
pixel = point * resolution (in terms of dpi) / 72
I have few measurements which I want to convert to pixels. Although reverse cases would also be possible.
How to do this in Cocoa or Quartz?
Does it depend on axis? Means would 5 pixels in Y-axis would be same as 5 pixels in X-axis in terms of points? Or is it safe to assume that resolution is same for both X and Y axis?
Please note that I do not want to make any assumption about resolution.
You probably don't want to convert anything to pixels. OS X now works in points; so for example when you draw a rectangle you are giving its dimensions in points, not pixels.
A OS X Quartz point is related to, but not the same as, a (computer) printing point - the two used to be the same, 72 points = 1". However WYSIWYG has become "some scale of" and 72 points (note not pixels) on screen is not a physical inch as screen pixel densities have increased. However 72 points is still an "abstract" inch.
In OS X you draw in points, the OS takes care of mapping those points to the physical pixels on the screen; which roughly translates to screens up to a certain density being treated as 72ppi (pixels/inch) or 1 pixel/point, and higher density screens being treated as 144ppi or 2 pixel/point - for example these are the ppi assigned to standard and Retina screenshots.
If you really, really need to know what a point translates to in pixels you can find out, but this changes depending on what screen a window is on.
For details of all of this you can start with Points Don’t Correspond to Pixels and then read the rest of the High Resolution Guidelines for OS X that reference is part of. How to find point to backing store mapping, if you really, really need to know, is covered.
HTH
There is an opportunity for confusion when your user specifies a length in 'points' as to whether they mean typography points of size 1/72" or lenghts compared to Mac UI points, which vary with the display resolution.
In Mac OS, "points" are pixels, unless you are in high resolution mode, in which case points are 2x2 pixels. The "Points Don't Correspond to Pixels" page says "on a high-resolution display, there are four onscreen pixels for each point," indicating a 4:1 correspondence in hi-res, and 1:1 correspondence in standard res. It also notes:
Note: The term points has its origin in the print industry, which defines 72 points as to equal 1 inch in physical space. When used in reference to high resolution in OS X, points in user space do not have any relation to measurements in the physical world.
To convert a typographer's point size to something physically the same size on a Mac screen in Mac points, your formula is exactly correct. You might rename 'pixel' to Mac points:
MacPoints = (TypesettersPoints/72)*ResolutionInDotsPerInch
Best to stick with points.
First you would need to know where the point is coming from. Views, Windows and Screens all have their own coordinate systems.
You would need to do several things to translate this to the pixel grid of a given screen.
First you need to convert your point to the screen coordinates.
Then to coordinates of pixel grid of the screen.
You will also need to find out the current display properties to know if it's a retina display or not. ( makes a big difference.)
All of the methods are in NSView, NSWindow, NSScreen.
All of the functions are part of Quartz Display services. You will need ones for CGDisplay you might need ones for CGWindow.
You will also need to have your app observe notifications for display configuration changes and figure out the hard part, when a point is in a coordinate space that overlaps two screens.
I leave it to you to do the rest and decide if you really need this.
Okay, so let me start by saying: PLEASE do not tell me how to create a fluid website or that I should read some statistic from Google on just how much pixel width by height is visible by website visitors as tracked by Google analytics...
As a web designer, certain assumptions about your audience must be made in order to design an effective website. So, what pixel dimensions do you assume are the minimum pixels width and/or height that these users should view your website at?
I understand that with a properly formatted "fluid" design, you should be able to view it at any dimensions - HOWEVER, there is always a target that the designer is hoping for as their minimum and maximum viewing sizes.
So, how about it? I want to hear people's personal experiences. Please do not point me to some obscsure net-article. All of that is great, BUT, I want to hear from those others, like me, who are in the trenches, actually designing websites: what pixel dimensions do you think are the minimum that your site should be seen at?
So, once again, for those in the cheap seats....
WHAT I WANT TO KNOW IS THIS:
What size is the optimal size to view your latest, greatest website design at?
Please, no flaming-weenies telling me what is wrong with my post... if you have nothing constructive to add, please do not respond.
I usually design for 800x600, taking out some vertical space for the browser, so around 800x450 - 800x500. If all of the important information falls in that resolution when viewed with OS-default font size settings, I consider that a good thing.
We had to build a webapplication for users from several systems. We decided that the users will need at least a resolution of 1024x768. the bad part with this page is that graphic designers had too much influence in creating the site. Well, also on bigger screens, everything is in a maximum 1024 pixels wide. We wanted to use the whole screen, but no: "doesn't look cool enough".
At the company I work, we design for a target resolution of 1024*768. This just stems from the fact that the place we are writing an application (GWT) for at the moment have a few old 15" computers lying around, and the application needs to run on their browsers too.
For on-screen viewing, you should trim about 40 pixels off of the width of the screen resolution. The narrower width accommodates for borders and scrollbars.
Think of your target audience:
Are they more likely to have high-resolution monitors (and a 1024x768 or larger display)? If that is the case, keep your width to about 980 pixels.
If your target audience is elderly, or has poor eyesite, they tend to prefer the larger fonts that an 800x600 resolution provides. For this audience, keep your width to about 760 pixels.
Will your audience print out your web pages (or a portion of them, e.g., for order confirmations or instructions/directions)? If so, the page to be printed must fit a 540 pixel width for 8.5x11" paper with .5" margins or 511 pixels for A4 paper.
(HTML5 standards may stray from these traditional guidelines, as pages can grow horizontally and vertically when the user expands viewing areas of the page.)
Is there a standard max for the width of the main content area of a web page? I want to maximize screen real estate without affecting usability. I've seen a lot of sites stick to 980px or less. Anyone have any suggestions?
Target either the 800x600 or 1024x768 resolution.
For 800x600 it is around 750px.
For 1024x768 it would be 970px.
I'm assuming you're referring to the wrapper width since you mentioned 980.
The most ideal solution is to not think of pixels at all and instead rely on ems/%s and scaling, be as fluid as possible so your design fits on small mobile devices and your elements heights are not fixed but auto. Example being: http://www.456bereastreet.com/
But if you're stuck with web designers who still think pixel and you know for sure you'll be unable to get them to try making images that are liquid/fluid, I would say shoot for 960 pixels in width so you have enough viewing area in a 1024x768 with scrollbars in IE6/XP, but this really depends on your audience and the majority of your audience's screen resolutions.
Research, such as that referenced here suggests that people have a more difficult time reading long lines of text. That's why I restrict my content width to 800px or so.
You have to first ask the question. Who is my audience?
There's no "standard", especially in this age of PDAs/smartphones/netbooks/smartbooks/kiosks/etc... - while it may sound cliche, the best thing is to design a fluid layout not depending on exact screen size.
The answer may change depending on your intended/anticipated user base, of course (e.g. assume 1024 px screen width leaving you with 980 working px - and consciously decide that you are not interested in supporting anyone with smaller screen resolution).
Another solution is to allow size layout customization by making it into portal-like with user having control of layout of the portlets (ala My Yahoo).
960 is a pretty common standard, and the rationale behind that figure is the fact that fitting on a 1024 pixel wide screen will allow a big majority of your users to see the content without scrolling. See here for one of 100's of sites that give access to browser & user system capabilities statistics for some initial inspiration.
But in the end, it'll up to you to understand the structure of your customer base - if your site targets iPhones, targetting 1024 pixel wide screens may not be your smartest decision.
Not sure about absolute pixel values, but one thing I'd make sure of is that the text columns don't get too wide. There is a number of characters beyond which reading comprehension is impaired.
1000 pixels in width, is what I use which fits into the minimum 1024x768 resolution used these days without a horizontal scroller at the bottom of your browser ....