I was wondering if someone knows the exact measurements of the new Windows Phone 8 Startscreen (for 480x800), i.e. margins (top, left & right, between tiles) and the edge length of all three different tile sizes.
For 720p (1280×720) and WXGA (1280×768):
Large Tile: 691 x 336 (yes, you're not reading it wrong, there's a extra pixel on the width)
Medium Tile: 336 x 336
Small Tile: 159 x 159
For WVGA (480x800):
Large Tile: 430 x 210
Medium Tile: 210 x 210
Small Tile: 100 x 100
For IconicTemplate (All resolutions):
Transparent icons!
Large Tile: 132 x 202 (IconImageURI)
Medium Tile: 72 x 110 (SmallImageURI)
Icon: 38 x 38 (DeviceLockImageURI)
For Application Icons
ApplicationIcon.png: 159 x 159
Background.png: 173 x 173
All numbers are in pixels. The horizontal margin between tiles are 10 px.
As a general piece of advice, provide your tiles in the high resolution, and they'll get downscaled by roughly a factor 1.6. Otherwise you'll find your low resolution tiles being upscaled, and the text will look very blurry.
And remember that some of the new special tile templates available in the SDK, will require different resolution images. The above is the full tile size, if you use a regular FlipTemplate.
Bonus Update: For App Bar Icons (not to be confused with the above)
76x76 circle with 42x42 icons.
Update:
Here's a test with different image sizes used with the iconic tiles.
Read the Claus' answer for the correct sizes.
Old answer:
For the Iconic Tile Template the 720p and WXGA sizes are:
Small Tile: 110 x 110
Medium Tile: 202 x 202
Wide Tile: N/A
The application's icon size is now 100x100, up from the previous 62x62.
For the Marketplace you must provide a 300x300 logo.
Microsoft has now posted the correct sizes for the Iconic template:
http://msdn.microsoft.com/en-us/library/windowsphone/design/jj662924(v=vs.105).aspx
SmallIconImage:
recommended “best fit”: 70x110px
max image size: 110x110px
IconImage:
recommended “best fit”: 130x202px
max image size: 202x202px
All other images and their sizes needed for publishing can be found at:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh184844(v=vs.105).aspx
And lock screen image:
http:// msdn.microsoft.com/en-us/library/windowsphone/develop/jj207048(v=vs.105).aspx
Related
I have created an icon in Adobe Illustration at 256 x 256 pixels.
When I output the file, it is shown as 772 x 772 pixels.
What is happening here, and how do I solve it?
Thank you!
New Document. Units = Pixels. Width = 256 px. Height = 256 px.
Align your artwork inside the given boundaries.
Export as PNG (as shown on your 2nd screenshot).
I'm using ImageMagick to convert the following PDF to an PNG file: PDF from IMSLP (Permalink)
In a PDF viewer it looks nice (even though it needs quite a bit of zooming):
but when converting with
convert "file.pdf" "/tmp/file.png"
the produced image gets an extremely low resolution:
when adding density and resize information, I get somewhat bigger images, but still not the original resolution that is stored within the PDF (certainly not 300 DPI)
convert -density "300" -resize "3000x3000>" "file.pdf" "/tmp/file.png"
When using Poppler-Utils' pdfimages, I'm getting the appropriate image:
My question is: Is there any way to tell ImageMagick to extract the images in the "correct" resolution (as is stored in the PDF document)? In other words, ignore the zoom that is necessary to view the PDF properly, thus extracting the correct image resolution?
I'm using ImageMagick 7.1.0.16 with Ghostscript 9.55.0 inside an Alpine Linux docker image.
Very unusual structure you have there its been through many changes but we can guess some pages may have been converted to 300 dpi or 600 dpi since they all render at roughly the same size.
Note that graphics dpi is subjective it is not that value that's used inside a PDF it is the the pixels per default of 72 point units that relate to a graphics working dpi. the image may have been 75 dpi but stored at 300 pixels per 72 points.
1st Analysis says images are
image-0028 = 714 X 900 dots nominally 600 dpi
image-0002 = 726 X 900 dots nominally 600 dpi
image-0005 = 674 x 900 dots nominally 600 dpi
image-0008 = 674 x 900 dots nominally 600 dpi
image-0011 = 674 x 900 dots nominally 600 dpi
image-0014 = 674 x 900 dots nominally 600 dpi
but all have been down-sampled to various sizes approx. 1.2" x 1.5" so a sensible source size to match all those reductions is possibly
9.6" x 12" with some cropping.
Thus to get the nearest original quality extract pages # 600 dpi (lossless png would be best to keep those lossy jpeg flaws)
Then reconvert them to 75 dpi should give you the closest to the poor quality inputs.
You need to increase your density much larger and put your resize after reading the input in Imagemagick.
This will be 5800 × 7200 pixels:
convert -density 4800 IMSLP358086-PMLP578359-Ehr_OP_20_5.pdf[1] x.png
This will be 2417 × 3000 pixels:
convert -density 4800 IMSLP358086-PMLP578359-Ehr_OP_20_5.pdf[1] -resize "3000x3000>" y.png
I've searched for a while now, but can't seem to get the answer I'm looking for.
I have an image, when I do properties on that image it says:
Dimensions 1717x697
Width 1717 pixels
Height 697 pixels
Horizontal Resolution 96 dpi
Vertical Resolution 96 dpi
Bit depth 32
So everything I've found searching says to get inches you are supposed to divide the pixels by the dpi...
So when I divide 697 by 96 I get 7.26041...
The height of my document that was scanned was 3.5 inches tall...how is that possible?
What I'm trying to do is if I have a piece of paper that is scanned and that piece of paper is 3.5 by 8.5 (coupon) I want to be able to know the the inches of that document based on pixels or some other method.
Thanks,
Mark
I am trying to get ImageMagick to do something for me and I am running into a few problems. First, I am not understanding units of measure and such passed into ImageMagick and so my script is not producing what I need. Second, the way I am doing it is extremely inefficient. Running this script takes a very long time (the one you see below is slightly trimmed down from what I am running).
So to what I am doing... I have a number of svg files with icons in them. I am looking to generate a page for each of these files. The page generated will contain the icon tiled over the entire page with a margin on the side. I am looking for 1/2 inch tiles with 1/2 margins around the page which needs to be a US Letter (8 1/2 x 11 inch).
After reading a lot of the documentation this is what I came up with.
colors=(red blue purple yellow green black)
mkdir -p generated/icons/
for color in ${colors[#]}; do
images=`printf "source/icons/${color}.svg%.0s " {1..300}`
montage $images -tile 15x20 -page Letter+1+1 -units PixelsPerInch -density 2550x3300 \
generated/icons/${color}.pdf
done
So for each of my files I run montage. I use printf to repeat the image file name 300 times. I then tile this 15x20 times. 15x20 comes from 8.5 minus 1 inch margins = 7.5*2 = 15 and likewise (11-1)*2 = 20. 300 images come from 15*20. I then say I want this on a letter page offset 1x1. (This was my attempt at a margin) I say I am speaking in pixel per inch (but none of the units seem to match up). I set the dpi to 300 by the density command where 8.5*300 = 2550 and 11*300 = 3300.
I've been toying with other settings (geometry etc.) but none of these are working. And the units don't seem to make sense either... Right now my resultant pdf is a square etc...
How do I make tiled pages as such? Also is there a way for me to do this more efficiently? What I have thus far is very slow.
EDIT:
Some more information:
i:montage --version
Version: ImageMagick 6.8.8-10 Q16 x86_64 2015-03-10 http://www.imagemagick.org
tile image:
my current output:
Notice margins not right, is square not a letter page, also tiles as skewed
Given the PNG image you provided, and I presume you want a 1 inch border of white all around inside an 8.5x11 inch printed image. Thus the tiled width would be 7.5 inches and tiled height would be 10 inches.
1 in = 300 dpi so border thickness = 300 px = 2 tiles thick
11-1 = 10 inches tall for tiled region height = 10*300 = 3000 px
8.5-1 = 7.5 inches wide for tiled region width = 7.5*300 = 2250 px
1 tile = 0.5 inches at 300 dpi = 0.5*300 = 150 px
convert lUDbK.png -resize "150x150!" -write mpr:tile +delete -size 2250x3000 tile:mpr:tile -bordercolor white -border 300 -units pixelsperinch -density 300 tiled_page.png
Time to process was 1.75 sec on my Mac Mini.
This produces an image which is rather large. You will have to extract the image to see the border, since this page background is white.
(Note that PNG only supports pixelspercentimeter, but IM converts my specification of pixelperinch accordingly. So if you look at the meta data, it will probably show you some other density in units of pixelspercentimeter. But they will correspond to the desired 300 dpi.)
I am new to the world of raster images, so I will first explain which definitions I use and hope that I will use them right:
- geometry (the total number of pixels of the image %w * %h)
- resolution (pixels per inch / ppi)
- size or "print size" (the display size (e.g. in inches) on screen or printer)
I have some PDF documents containing raster images of different geometry. When opening with evince they therefore all display (and I guess potentially print) with different sizes. I would like to define the print size within the pdf so that evince (or any other viewer) would display every page with the same size when opening the document.
How could this be realized? Geometry and print size of the image are linked by the resolution as far as I understand. Currently one of my pdf's shows to following ImageMagick:identify output:
$identify -units PixelsPerInch -format "%w x %h - %[resolution.x] x %[resolution.y] - %[fx:w/72] x %[fx:h/72] in\n" example.pdf
geometry - resol. - print size -
538 x 375 - 72 x 72 - 7.47 x 5.20 in
546 x 381 - 72 x 72 - 7.58 x 5.29 in
1210 x 1681 - 72 x 72 - 16.80 x 23.34 in
1658 x 1166 - 72 x 72 - 23.02 x 16.19 in
542 x 365 - 72 x 72 - 7.52 x 5.06 in
1673 x 1169 - 72 x 72 - 23.23 x 16.23 in
I would like to realize a constant print size (column 3) and I do not want to change the geometry of the image/ avoid to re-compress it, so that it does not loose quality. In order to proceed it seems to me that I need to understand the following which I cannot find any information about:
1) Which of these three values is actually saved in the pdf document and which one is calculated by identify?
2) Which software (and how) would allow me to batch process a number of pdf files in order to achieve my goal.
3) Guessing that geometry and resol are values of the pdf file and print size is derived from it, the software would need to calculate a resolution value for each image so that print size would qual over all pages?
Thank you very much!
Cheers,
Benjamin
1) I think only the first two are actually stored in the PDF, but the third value (print size) is directly related to resolution (538x375) and pixel density (72ppi aka 72dpi), so it can easily be calculated anyway.
2) It seems like you're going about this a little backward. There are plenty of applications that are perfectly suited to controlling image layout and printing. Adobe Illustrator is one of the most common and there are some free ones, too. But these are going to involve loading the images, visually arranging them on the page and adjusting the print sizes visually, rather than programmatically.
2) If you did want to do this programmatically, though, I think you're going to have a hard time finding software to solve that problem. GIMP and Photoshop both have some batching capability, and I know GIMP has a fairly robust CLI, so you might be able to use that.
3) Yes, you'll start with the print size you want, divide the number of pixels by the number of inches to get ppi/dpi.
NOTE: Keep in mind that dpi goes both directions. If you have a 200 x 300 image and a 400 x 400 image, and you want them both to print 10 inches square, then you're going to distort the 200 x 300 image, stretching it horizontally. The 200 x 300 image will also look poorer quality than the 400 x 400, because you have fewer pixels to work with.
For these and other reasons, I highly recommend a visual approach, rather than a coding approach.
Good luck!