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
Related
I am creating a canvas with predefined dimensions (2505px width, 3542px height) which are the dimensions for an A4 paper in 300 DPI resolution.
I am converting the canvas to pdf using createPDFStream (https://github.com/Automattic/node-canvas#canvascreatepdfstream). The outputted PDF is good but I notice that the Page Size is 34,79 x 49,19 inches (see image below), which is much larger than a regular A4 paper, which causes some problems further down the line.
I notice that this is because that createPDFStream is assuming that the PDF should be in 72dpi, since 2505px / 72dpi = 34,79 inches & 3542px / 72 dpi = 49,19 inches. My question is if there is a way to specify to createPDFStream that the PDF is supposed to be in 300dpi so that we get the correct Page Size. Alternatively, if there is a library to use to correct the Page Size or DPI settings without compromising the 300 DPI image quality.
I tried digging deeply through the node-canvas for a solution, but I could neither find a way to correct the DPI nor find the place where the 72 DPI assumption is set.
I have created a figure using matplotlib but I have realized the plot axis and the drawn line gets zoomed out.
Reading this earlier discussion thread, it explains how to set the figure size.
fig, ax = plt.subplots()
fig.set_size_inches(3, 1.5)
plt.savefig(file.jpeg, edgecolor='black', dpi=400, facecolor='black', transparent=True)
With the above code (other configurations removed for brevity), I do get a resulting image file with 1200 X 600 desired dimensions(should we say resolution too?) and desired file size.
The projected image is scaled out in an unusual way, annotations for example are enlarged. While I can set the size of the labels on the axis, the figure doesn't look proportional with respect to the scale since the bottom and right spines are large and so are the plotted lines.
The question, therefore, is, what configurations are going wrong?
Figure size (figsize) determines the size of the figure in inches. This gives the amount of space the axes (and other elements) have inside the figure. The default figure size is (6.4, 4.8) inches in matplotlib 2. A larger figure size will allow for longer texts, more axes or more ticklabels to be shown.
Dots per inches (dpi) determines how many pixels the figure comprises. The default dpi in matplotlib is 100. A figure of figsize=(w,h) will have
px, py = w*dpi, h*dpi # pixels
# e.g.
# 6.4 inches * 100 dpi = 640 pixels
So in order to obtain a figure with a pixel size of e.g. (1200,600) you may chose several combinations of figure size and dpi, e.g.
figsize=(15,7.5), dpi= 80
figsize=(12,6) , dpi=100
figsize=( 8,4) , dpi=150
figsize=( 6,3) , dpi=200
etc.
Now, what is the difference? This is determined by the size of the elements inside the figure. Most elements like lines, markers, texts have a size given in points.
Matplotlib figures use Points per inch (ppi) of 72. A line with thickness 1 point will be 1./72. inch wide. A text with fontsize 12 points will be 12./72. inch heigh.
Of course if you change the figure size in inches, points will not change, so a larger figure in inches still has the same size of the elements. Changing the figure size is thus like taking a piece of paper of a different size. Doing so, would of course not change the width of the line drawn with the same pen.
On the other hand, changing the dpi scales those elements. At 72 dpi, a line of 1 point size is one pixel strong. At 144 dpi, this line is 2 pixels strong. A larger dpi will therefore act like a magnifying glass. All elements are scaled by the magnifying power of the lens.
A comparisson for constant figure size and varying dpi is shown in the image below on the left. On the right you see a constant dpi and varying figure size. Figures in each row have the same pixel size.
Code to reproduce:
import matplotlib.pyplot as plt
%matplotlib inline
def plot(fs,dpi):
fig, ax=plt.subplots(figsize=fs, dpi=dpi)
ax.set_title("Figsize: {}, dpi: {}".format(fs,dpi))
ax.plot([2,4,1,5], label="Label")
ax.legend()
figsize=(2,2)
for i in range(1,4):
plot(figsize, i*72)
dpi=72
for i in [2,4,6]:
plot((i,i), dpi)
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.)
What are the units for UserForm.Left and UserForm.Top in Word 2013 VBA? MSDN doesn't say. This answer suggests they may be twips, but on my system, they are coming out as 0.75*pixels.
That is, my screen is 1920x1200 but a userform moved to the lower-right corner has Left=1440=1920*0.75 and Top=900=1200*0.75. The system has two monitors, each 1920x1200, screen resolution 96 DPI, and TwipsPerPixel[XY] both return 15. Is it always three-quarters of a pixel, or is there some other system metric I need to check?
Well, the answer was staring me in the face, so here it is in case someone else benefits. If you have a more robust answer, please post it!
The units were points, 72 per inch. (72 = 96 dpi * 0.75.) I converted pixels to points with
pts = Application.PixelsToPoints(pxls)
and then used pts for Left and Top. Width and Height are also in points on my system.
According to Xerox, the font "Courier is a 10 point font that will print at exactly 12 characters per inch." Given a default page with 5.5 width, 65 characters per row.
One can quickly verify that 12 pt Courier, and many other 12 pt founts, fit 46 or 47 rows per default page with 9 inch height.
Consider a character width a column. For monospaced 12 pt fonts, it is common to have 60 characters per line. Given 46 rows, the ratio of columns to rows, or height to width in character spacing, is 18:11.
Yet nowhere is this ratio, or any like it, suggested for the total space a monospace or any glyph uses. That is because of the "72 pts per inch" clause.
If there are 72 pts per inch, there are 648 pts in 9 inches, or 14 pts for each of 46 rows.
Similarly, there are 396 pts in a 5.5 width document page. If 60 12 pt characters fit, each is ... 6.6 pts wide! Further, the ratio of 14 to 6.6 is 2.12. Yikes!
Variability between different fonts, etc., could account for some difference. 6.6 to 12 is beyond that.
Can this be explained?
There are two things to understand about font point sizes. First, it only specifies the height of the font, not the width. This should be obvious when you consider that a non-monospaced font will vary in width for each character. Second is that the point size only specifies the height of the character cell, not the row spacing - the relation between the two is left entirely up to the font designer, and can generally be overridden in software. For that matter the size of the character itself within the character cell is also left up to the font designer and can vary significantly between two fonts with the same point size.
For example, in my copy of Microsoft Word the default page is 8.5x11 with 1 inch margins, leaving a printable space of 6.5x9 inches or 468x648 points. I've set my paragraph to single line spacing with no before/after padding. If I use a Courier New 12 point font, each character should be 7.2x12 points, implying 65x54 characters per page. The actual capacity is 64x47 characters. This implies a width closer to 7.3 points, and a row height that is more than 12 points, approximately 13.7 points.
If I set the paragraph line spacing to exactly 12 points, I get 54 lines as expected.
If I switch to Consolas, another monospaced font, the capacity changes to 70x46. The designer of Consolas decided that it could be narrower but taller than Courier, for an identical point size.