I read some of those website links that explain about exporting different image sizes for iOS device. But I don't really understand of those explaining. (May be I am not good at in English language.)
I found these dimension for launch screen. Please let me clarify my understanding to you guys.
So, when I create an image, I must create a larger size(#3x) firstly and should export that image into smaller sizes (#2x, #1x). Am I right?
For example, I create 1242x2208px (3x) image and scale to 2x,3x and save.
My questions are that;
1) I draw images in Photoshop CS6.For any size of images, the Resolution is still 75px. isn't it?
So, for 1242x2208px(3x) size , the resolution is 75px and then I decrease the size. The image will small and does it get blurry appearance?
2) Does image elements (heart image in my example image)need to make to be large in smaller device(1x) to get the clear looks? Or
3) If we don't need to modify image elements or may be some texts of font size to be large or small, can we get the high resolution of image appearance in 1x? I'm afraid that if we scale to smaller(1x), it would be blur and not good in looks because we are still in 75 resolutions.
4) Does it need to make to fit the image elements to image size? I found this video https://www.youtube.com/watch?v=WOnczJSsMqk . In this video, he crops the white space and export into #1x, #2x and #3x. So, the size of #3x is not the image size from Apple official Guideline website. I don't know clearly this.
5) If we type the text (font size-90pt) in #3x image, then it will automatically changes to 60pt in #1x image. right?
But in this link https://www.smashingmagazine.com/2015/05/retina-design-in-photoshop/#font-size , he wrote that
a text box with the font set to 16 pixels. But #2x this is 32 pixels,
and #3x it’s 48 pixels!
Not ideal, is it, having to constantly multiply by two or three? I
don’t know about you, but I could do without the constant math. When I
design, I want to know that 16 pixels is 16 pixels!
So, the text should be 16 px in any size of image 1x,2x or 3x or not?
6) These image sizes are for launch screen, isn't it? But, if I create an image for background of Login screen, then is it the same concept and save as these sizes of image ?
7) Above image size dimension is correct or not? But, in this https://developer.apple.com/ios/human-interface-guidelines/graphics/launch-screen/ website, the sizes are a little bit different.
Now, I'm trying to create a design for login background image. So, I was finding the sizes before I draw. But, after reading many articles of image sizes in Retina device, I've confused and got many questions in my mind.
That's why I write down my questions like this and I would like to say sorry that my question is long and make you feel not easy to understand.
Sorry again for my poor English.
I hope anyone would help me to answer all my questions in steps.Thanks for reading till the end. :)
You are asking way to much here. First off, you do not work in pixels. You work in points. These are 2 different units of measurements. On a 1x scale 1 point = 1x1 pixel, on a 2x scale 1 point = 2x2 pixel, and on a 3x scale, 1 point = 3x3 pixels.
Now when it comes to how to scale, people claim that you start big and you got small for best quality. This is simply not true. It all depends on the actual image as to how it will scale. So your goal is to find what works best for the image. I would recommend starting off from big to small, but if it doesn't work out as nice as you like, go small to big, then try a different scaling method.
I personally do not rely 100% on automation, I like to tweak all 3 sizes manually until the images are perfect, which makes sprite-kit really tough to work with in this department because I have to design my graphics in a way that counter act the hardware scaling. Bottom line is at the end of the day, do what is best for your app within your budget constraints.
Now when it comes to font sizes, again you are working in points, not pixels. Whoever told you that you need to multiply has no understanding of how retina display works. So when you do 16pt font, the system will automatically pick 32pt and 48pt. (But if you read it it will still say 16pt)
Try not to over think this matter, it is really simple to understand. The entire point of retina display is to provide a sharper image while maintaining the same experience, and it does this by offering more granularity in the way pixels are displayed. Each individual pixel is very very tiny, which makes it hard to see with your eyes. Instead they are companions to other pixels, so that when your eyes put the 2 pixels together, you get a better looking image that could not be produced by using a single colored pixel. When you work on your apps, you want to keep this in mind. This is why it stinks for new people to get into development. Everybody should start with the iphone 2g, then adapt their app to iphone 4. They will get a clear understanding of what retina is built for.
Related
I created this UI framework in Direct2D some time ago to be able to draw/manage my own windows and widgets. I've been using it and updating it according to my needs and it works pretty well. However, now that high resolutions monitors are the new thing, I came across a small problem. Drawing images/icons in the best definition I can.
Since I'm using Direct2D all the draw functions work properly according to the DPIs/scaling of the target machines except of course images that are based in pixels and for that reason are not automatically managed by DirectX.
So, in the beginning I was simply drawing bitmaps as they were in 96 DPI, this meant that if I had an icon 10x10, and I used a function like ID2D1RenderTarget::DrawBitmap by specifying a destination rectangle, my image would be scaled up for higher DPIs. This of course would be noticeable and the icon would be blurry.
My first attempt at fixing this was to create my icons 4x bigger than the default DPI of 96. Then, using the same ID2D1RenderTarget::DrawBitmap and knowing that these images are 4x bigger, the DrawBitmap would draw the icon scaled down instead of scaled up. This had much better results, Starting from a windows scale of 150% and up it's perfect.
However, scaling down from 4x to 1x, the result is not great, images get somewhat pixelized. Much worse that doing the same in Photoshop.
I also tried using SetTransform before the DrawBitmap so see if the result is better, but it's exactly the same.
So my question is, how are people dealing with this issue. I'm sure I'm not the only one...
If your goal is to get best visual results, you'll need to prepare groups of icons in various resolutions, not just downscaled but specifically designed in lower sizes. Then you'll need to select one of those according to current context.
Regarding DrawBitmap, you could try with different interpolation modes.
As for general solutions that people are using, I don't think there is one. Many applications don't support this properly, or if they do for control layout, embedded bitmap resources are still stretched and look deformed or interpolated and look too blurry.
currently i am having much difficulty thinking of a good method of removing the gradient from a image i received.
The image is a picture taken by a microscope camera that has a light glare in the middle. The image has a pattern that goes throughout the image. However i am supposed to remove the light glare on the image created by the camera light.
Unfortunately due to the nature of the camera it is not possible to take a picture on black background with the light to find the gradient distribution. Nor do i have a comparison image that is without the gradient. (note- the location of the light glare will always be consistant when the picture is taken)
In easier terms its like having a photo with a flash in it but i want to get rid of the flash. The only problem is i have no way to obtaining the image without flash to compare to or even obtaining a black image with just the flash on it.
My current thought is conduct edge detection and obtain samples in specific locations away from the edges (due to color difference) and use that to gauge the distribution of gradient since those areas are supposed to have relatively identical colors. However i was wondering if there was a easier and better way to do this.
If needed i will post a example of the image later.
At the moment i have a preferrence of solving this in c++ using opencv if that makes it easier.
thanks in advance for any possible ideas for this problem. If there is another link, tutorial, or post that may solve my problem i would greatly appreciate the post.
as you can tell there is a light thats being shinned on the img as you can tell from the white spot. and the top is lighter than the bottome due to the light the color inside the oval is actually different when the picture is taken in color. However the color between the box and the oval should be consistant. My original idea was to perhaps sample only those areas some how and build a profile that i can utilize to remove the light but i am unsure how effective that would be or if there is a better way
EDIT :
Well i tried out Roger's suggestion and the results were suprisngly good. Using 110 kernel gaussian blurr to find illumination and conducting CLAHE on top of that. (both done in opencv)
However my colleage told me that the image doesn't look perfectly uniform and pointed out that around the area where the light used to be is slightly brighter. He suggested trying a selective gaussian blur where the areas above certain threshold pixel values are not blurred while the rest of the image is blurred.
Does anyone have opinions regarding this and perhaps a link, tutorial, or an example of something like this being done? Most of the things i find tend to be selective blur for programs like photoshop and gimp
EDIT2 :
it is difficult to tell with just eyes but i believe i have achieved relatively close uniformization by using a simple plane fitting algorithm.((-A * x - B * y) / C) (x,y,z) where z is the pixel value. I think that this can be improved by utilizing perhaps a sine fitting function? i am unsure. But I am relatively happy with the results. Many thanks to Roger for the great ideas.
I believe using a bunch of pictures and getting the avg would've been another good method (suggested by roger) but Unofruntely i was not able to implement this since i was not supplied with various pictures and the machine is under modification so i was unable to use it.
I have done some work in this area previously and found that a large Gaussian blur kernel can produce a reasonable approximation to the background illumination. I will try to get something working on your example image but, in the meantime, here is an example of your image after Gaussian blur with radius 50 pixels, which may help you decide if it's worth progressing.
UPDATE
Just playing with this image, you can actually get a reasonable improvement using adaptive histogram equalisation (I used CLAHE) - see comparison below - any use?
I will update this answer with more details as I progress.
I would like to point you to this paper: http://www.cs.berkeley.edu/~ravir/dirtylens.pdf, but, in my opinion, without any sort of calibration/comparison image taken apriori, it is difficult to mine out the ground truth from the flared image.
However, if you are trying to just present the image minus the lens flare, disregarding the actual scientific data behind the flared part, then you switch into the domain of image inpainting. Criminsi's algorithm, as described in this paper: http://research.microsoft.com/pubs/67276/criminisi_tip2004.pdf and explained/simplified in these two links: http://cs.brown.edu/courses/csci1950-g/results/final/eboswort/ http://www.cc.gatech.edu/~sooraj/inpainting/, will do a very good job in restoring texture information to the flared up regions. (If you'd really like to pursue this approach, do mention that. More comprehensive help can be provided for this).
However, given the fact that we're dealing with microscopic data, I doubt if you'd like to lose the scientific data contained in a particular region of an image. In that case, I really think you need to find a workaround to determine the flare model of the flash/light source w.r.t the lens you're using.
I hope someone else can shed more light on this.
I'll first tell you the problem and then I'll tell you my solution.
Problem: I have a blank white PNG image approximately 900x900 pixels. I want to copy circles 30x30 pixels in size, which are essentially circles with a different colour. There are 8 different circles, and placed on the image depending on data values which I've created elsewhere.
Solution: I've used ImageMagicK, it's suppose to be good for general purpose image editing etc. I created a blank image
Image.outimage("900x900","white");
I upload all other small 30x30 pixel images with 'read' function.
I upload the data and extract vales.
I place the small 'circle' images on the blank one using the composite command.
outimage.composite("some file.png",pixelx,pixely,InCompositeOp);
This all works fine and the images come up the way I want them too.
However its painfully SLOW. It takes 20 seconds to do one image, and I have 1000 of them. Surely there must be a better way to do this. I've seen other researchers simulate images way more complex and way faster. It's quite possible I took the wrong approach. Maybe I sould be 'drawing' circles instead of 'pasting' them or something. I'm quite baffled. Any input is appreciated.
I suspect that you just need some library that is capable of drawing circles on bitmap and saving that bitmap as png.
For example my Graphin library: http://code.google.com/p/graphin/
Or some such. With Graphin you can also draw one PNG on surface of another as in your case.
You did not give any information about the platform you are using (only "C++"), so if you are looking for a platform independent solution, the CImg library might be worth a try.
http://cimg.sourceforge.net/
By the way, did you try drawing the circles using the ImageMagick C++ API Magick++ instead of "composing" them? I cannot believe that it is that slow.
Pretty simple but specific question here:
I'm not entirely familiar with the JPEG standard for compressing images. Does it create a better (that being, smaller file size at a similar quality) image when the X dimension (width) is very large and the Y dimension (height) is very small, vice versa, or when the two are nearly equal?
The practical use I have for this is CSS sprites. If a website were to consist of hundreds of CSS sprites, it would be ideal to minimize the size of the sprite file to assist users on slower internet and also to reduce server load. If the JPEG standard operates really well on a single horizontal line, but moving vertically requires a lot more complexity, it would make sense for an image of 100 16x16 CSS sprites to be 1600x16.
On the other hand if the JPEG standard has a lot of complexity working horizontally but moves from row to row easily, you could make a smaller file or have higher quality by making the image 16x1600.
If the best compression occurs when the image is a perfect square, you would want the final image to be 160x160
The MPEG/JPEG blocking mechanism would (very slightly) favor an image size that is an exact multiple of the compression block size in each dimension. However, beyond that, the format won't care if the blocks are vertical or horizontal.
So, the direct answer to your question would be "square is as good as anything", as long as your sprites divide easily into a JPEG compression block (just make sure they are 8, 16, 24 or 32 pixels wide and you'll be fine).
However, I would go a bit further and say that for "most" spites, you are going to have a smaller image size, and clearer resolution if you have the initial master image be GIF instead of JPG, even more so if you can use a reduced color palette. Consider why would you need JPG at all for "hundreds of sprites".
It looks like JPEG's compression ratio isn't affected by image dimensions. However, it looks like your dimensions should be multiples of 8 but in all your examples you had multiples of 16 so you should be fine there.
http://en.wikipedia.org/wiki/JPEG#JPEG_codec_example
If I remember correctly, PNG (being lossless) operates much better when the same color appears in a horizontal stretch rather than a vertical stretch. Why are you making your sprites JPEG? If they are of a limited color-set (which is likely if you have 16x16 sprites, animated or not), PNG might actually yield better filesizes with perfect image quality.
I am trying to create a piece of software that can be used to create VERY large (10000x10000) sized bitmaps. All I need is something that can work in monochrome, since the required output is a matrix containing details of black and white pixels in the bitmap. The closest thing I can think of is a font editor, but the size is a problem.
Is there any library out there that I can use to create the software, or will I have to write the whole thing from the start?
Edited on May 25: OK, so I've been searching around and I have found that using the GtkTree Widget is a good way to create grids. Has anybody tried that with the large sizes that I require? And if so, can it be made to look like a drawing surface rather than a Spreadsheet like view?
Why don't you use bitmap objects, like gdk pixmaps if you use GTK?
10,000 x 10,000 pixels with a depth of 1 (monochrome) is 100,000,000 bits, which is 12,500,000 bytes, around 12 megabytes.
Not that large.