I am trying to draw some musical notes using the Bravura font from http://blog.steinberg.net/2013/05/introducing-bravura-music-font/ using core text functions.
A metadata json file accompanying this font has an "attach" coordinate in em unit fractions for where stems should be attached to certain musical notes. This attachment point is relative to a bounding box around the note glyph again with the dimensions in fractions of em unit.
My crude ASCII picture shows the attach point of the stem to the musical note:
|
|
|
/---\* <- attach point here
| |
\---/
From wikipedia:
"An em is a unit of width in the field of typography, equal to the currently specified point size. For example, one em in a 16-point typeface is 16 points wide. Therefore, this unit is the same for all typefaces at a given point size."
I would like to use the Core Text function CTFontDrawGlyphs which takes a coordinate in pixels to use for the glyph placement.
I would also like to use the Core Graphics functions CGContextMoveToPoint, CGContextAddLineToPoint to draw the stems that attach to the musical note glyphs.
I'm a bit unclear how to go from a coordinate in em unit fractions to a particular coordinate in pixels for a glyph of a particular point size so that I can accurately place these stems to the musical note glyph.
In the absence of a text transformation matrix (CGContextSetTextMatrix), 1 em will the be the same number of points as the font size. So for a 12 point font with the default identity text matrix, 1 em = 12 pt.
Note that almost nothing in Core Graphics is given in pixels. They're in points (Core Graphics points, not PostScript points). For a retina display, 1 point contains 4 pixels (2x2). This is probably what you mean anyway, but if you interact with images, the point/pixel conversion is very important.
(I kind of feel like I've repeated what you already know; is there more to the question? From a given origin, you would compute the coordinate by multiplying the em unit offset by the font size.)
Related
I try to build a structured light environment to do 3D scanning.
As far as I know, if I choose to use gray code to reconstruct a 3D model, I have to implement specific patterns that were encode in power 2(2^x, x = 0 ~ 10).
That is said, the patterns must be at least 1024 x 1024 in resolution.
What if my DLP projector only support resolution up to 800 x 480? It projects Moire pattern when the gray code pattern resolution becomes too high(I tried). What should I do?
My friends suggest that I create 1024 x 1024 patterns, and "crop" them into 800 x 480,
but I thought the gray code should follow specific sequence and patterns, my friends suggestion will create several image that is not symmetry.
Does anyone have the same experience like me?
----------2015.8.4 Update Question----------
I was thinking that if my projector can't perfectly projects high resolution patterns, can I just let it projects the patterns with low resolution, for instance, from 2^0 to 2^6?
Or the gray code strictly demands patterns from 2^0 to 2^10? Otherwise gray code is not available?
you can not directly scale down to your resolution
because it would distort the pattern make it useless
instead you can:
crop it to your resolution
but you need to handle that in the scanning part too because you would not have the full pattern available
use nearest usable power of 2 resolution
like 512x256 and create pattern for it. The rest of the space is unused (wasting pixels)
use bullet #2 + scale up to fit your resolution better
so create pattern 512x256 and linearly scale to fit to 800x480 as much as you can so:
800/512 = 1.5625
480/256 = 1.8750
use the smaller scale (512x256 * 1.5625 -> 800x400) so scale the pattern by 1.5625 and use that as a pattern image
this is scaled by nearest neighbor to avoid subpixel grayscale colors which are harder to detect. This will waste less pixels but it can lower the precision of 3D scan !!!
This is how I generate my pattern in C++ and VCL:
// [generate pattern xs*ys power of 2 resolution]
// clear buffer
bmp->Canvas->Brush->Color=clBlack;
bmp->Canvas->FillRect(TRect(0,0,xs,ys));
int x,y,a,da;
for (da=0;1<<da<xs;da++); // number of bits per x resolution
for (a=0,y=0;y<ys;y++,a=(y*da)/ys)
for (x=0;x<xs;x++)
if (int((x>>a)&1)==0) pyx[ys-1-y][x]=0x00FFFFFF;
bmp->SaveToFile("3D_scann_pattern0.bmp");
bmp is VCL bitmap
xs,ys is the resolution of a bitmap
p[ys][xs] is direct 32bit pixel access to bitmap
This is slight differently encoded then your pattern !!!
[Notes]
If you need precision use bullet #2
If you need to cover bigger area use bullet #3
You can also scale in y axis differently then in x axis as this is just 1D encoding
I want to read a barcode from a scanned image that I printed. The image format is not relevant. I found that the scanned images are of very low quality and can understand why it normal barcodes fail.
My idea is to create a non standard and very simple barcode at the top of each page printed. It will be 20 squares in a row forming a simple binary code.Filled = 1, open = 0. It will be large enough on aA4 to make detection easy.
At this stage I need to load the image and find the barcode somewhere at the top. It will not be exactly at the same spot as it is scanned in. Step into each block and build the ID.
Any knowledge or links to info would be awesome.
If you can preset a region of interest that contains the code and nothing else, then detection is pretty easy. Scan a few rays across this region and find the white/black and black/white transitions. Then, knowing where the "cells" should be, you known their polarity.
For this to work, you need to frame your cells with two black ones on both ends to make sure to know where it starts/stops (if the scale is fixed, you can do with just a start cell, but I would not recommend this).
You could have a look at https://github.com/zxing/zxing. I would suggest to use a 1D bar code, but wide enough to match the low resolution of the scanner.
You could also invent your own bar code encoding and try to parse it your self. Use thick bars for 1 and thin lines for 0. A thick bar would be for instance 2 white pixels, 4 black pixels. A thin line would be 2 white pixels, 2 black pixels and 2 white pixels. The last two pixels encode the bit value.
The pixel should be the size of the scanned image pixel.
You then process the image scan line by scan line, trying to locate the bar code.
We locate the bar code by comparing a given pixel value sequence with a pattern. This is performed by computing a score function. The sum of squared difference is a good pick. When computing the score we ignore the two pixels encoding the bit value.
When the score is below a threshold, we found a matching pattern. It is good to add parity bits to the encoded value so that it's validity can be checked.
Computing a sum of square on a sliding window can be optimized.
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.
I have a barcode image. I have to make it smaller.
Can that damage the barcode?
Proportional scaling
Not proportional scaling (only height changes)
Barcodes are: Type UPC-A / EAN-13 "vertical lines". Sorry not an expert in barcodes, thought the type of barcode would not be important. Scaling is moderate, the image does not lose relevant data.
Regular barcode (=vertical stripes) is recognized by the relative width of the lines. Thus, the horizontal height only matters for robustness against diagonal scanning. If the codes are scanned with a hand scanner, I'd just scale the height (or crop the image). In any case, the different widths of the lines should still be clearly visible. There may be compliance rules suggesting minimum proportions for a given barcode standard.
For regular linear product barcodes, the simple answer is yes, you can scale it (both case are safe).
However, if you scale too far and the bars end up too close together, you will start to get a high level of read errors.
You'll need to test it with an appropriate barcode reader to make sure you haven't scaled too much.
When scaling a barcode, there are several things you must keep in mind.
1) You get the absolute sharpest edges in a barcode if each module (the narrowest bar) is a whole number of pixels wide.
2) If the module width is not a whole number of pixels, produce a barcode where the width of each module is the truncated whole number and use bilinear interpolation to scale up. This will give you at most one pixel of gradient at the edges.
3) Be careful when buying a barcode library, choose one that includes built-in scaling that preserves the barcode, such as this one or this one. Barcodes have special demands that image processing normally does not have, such as pixel-perfection. Using e.g. Gimp might damage the barcode.
or "How I learned to stop worrying and learned to love measurement systems"
I wanted a central spot that I can refer to later to give me a quick low-down on various units of measurement used in programming. SO seemed the best place to put it, and while I could go ahead and answer the question myself, y'all are a much smarter bunch than I, so I might as well let you do it.
Please pick one unit that you're familiar with, use "#name" in the first line to give it as the heading (making it easy to find) and define it within your answer. Please do not duplicate - add comments or edit existing answers rather than adding a new answer. Similar units are still seperate - so please don't define em and en in the same answer. If a unit is exactly the same as another unit, add a line for "aliases" below the heading.
If it's a particularly obscure measurement type, please link to a second reference so people don't downvote you because they've never heard of it.
Point
Pica
Twips
Pixel
Em
En
CPI
DPI
I'm seeing a lot of downvoting - I suppose people believe this doesn't add value to StackOverflow's community. Please consider commenting below if you feel this doesn't add to the community, or if you think this is a bad question. I'm interested in improving it if you have any suggestions.
The great thing about standards is there are so many to choose from!
-Adam
I recommend to ammend the above answers using the following descriptions
PICA
Pica Typographic unit of measurement in the anglo-american point system. One pica is 1/72 Inch (0,351 mm) and equals 12 pica points. The didot equivalent of a pica is a cicero. A standard unit of measure in newspapers. There are 6 picas in one inch, 12 points in one pica.
PICA POINT
Pica Point 1/12 of a pica
POINT
996 points are equivalent to 35 centimeters, or one point is equal to .01383 inches. This means about 72.3 points to the inch. We in electronic printing use 72 points per inch
1 point (Truchet) = 0.188 mm (obsolete today)
1 point (Didot) = 0.376 mm = 1/72 of a French royal inch (27.07 mm)
1 point (ATA) = 0.3514598 mm = 0.013837 inch
1 point (TeX) = 0.3514598035 mm = 1/72.27 inch
1 point (Postscript) = 0.3527777778 mm = 1/72 inch
1 point (l’Imprimerie nationale, IN) = 0.4 mm
EM
An old printing term for a square-shaped blank space that’s as wide as the type is high; in other words, a 10-point em space will be 10 points wide.
EN
Half an em space; a 10-point en space will be 5 points wide.
DPI
The number of dots per inch a printer prints. The higher the dpi, the finer the resolution of the output.
PIXEL
The smallest dot you can draw on a computer screen
CPI
Counts per inch for Mouse properties and The number of horizontal characters that will fit in one inch for Printer properties
PITCH Alias CPI
Pitch describes the width of a character. Pitch equals the number of characters that can fit side-by-side in 1 inch; for example, 10 pitch equals 10 characters-per-inch or 10 CPI. Pitch is a term generally used with non-proportional (fixed-width) fonts.
TWIPS
A twip (derived from TWentieth of an Imperial Point) is a typographical measurement, defined as 1/20 of a typographical point. One twip is 1/1440 inch or 17.639 µm when derived from the PostScript point at 72 to the inch, and 1/1445.4 inch or 17.573 µm based on the printer's point at 72.27 to the inch
Additional Units:
LPI
The number of vertical lines of text that will fit in one inch
PPI
Thickness of paper, expressed in thousandths of an inch or pages per inch.
or sometimes no of horizontal pixels closely printed or displayed per inch.
FONT SIZE
Font size or Type size is the baseline distance for which the font was designed. A font should normally be identified and selected by this size, because the intended baseline distance is much more relevant for practical layout work than the actual dimensions of certain characters.
FONT HEIGHT
Font height is the height in mm of letters such as k or H. Typically, the font height is around 72% of the font size, but this is of course at the discretion of the font designer.
X-HEIGHT
x-height indicate typesize of lower-case letters excluding ascenders and descenders (from the height of the lower-case x)
H-HEIGHT
h-height or cap height refers to the height of a capital letter above the baseline for a particular typeface. It specifically refers to the height of capital letters that are flat—such as H or I—as opposed to round letters such as O.
Pixel
One of the little colored squares on your screen.
Pica
A typographical measure of 12 points, sometimes (incorrectly) called an Em. (in fact, an em is actually a horizontal distance the same as the point size of the type).
Twips
'Twentieth of an Imperial Point'. A measure used for marking up positions of widgets in Visual BASIC user interfaces. It was used this way so that positions could be specified precisely using integers. One Twip = 1/20 point = 1/1440 inch.
EM
An old printing term for a square-shaped blank space that’s as wide as the type is high; in other words, a 10-point em space will be 10 points wide.
DPI
Dots per inch. A dimensionless number used to measure the resolution of something in space, i.e. with respect to real occupied physical size.
dds complexity and headache since the standard/default DPI of a computer screen varies with the operating system. Macintosh screens generally have 72 DPI, while Windows favors 96. If you don't compensate for this when displaying images (and text), you will get unexpected variations.
Always amusing when people start talking of "the DPI of this image", for digital images such as PNG or JPEG. To me, they only have absolute pixels in them, unconnected to any physical size. If you want to print the image on a (for instance) 300 DPI printer, then you need to adapt and scale to get it correct, but the image itself only has pixels.
EN
Half an em space; a 10-point en space will be 5 points wide.
CPI
Counts per inch for Mouse properties and
The number of horizontal characters that will fit in one inch for Printer properties
PITCH Alias CPI
Pitch describes the width of a character. Pitch equals the number of characters that can fit side-by-side in 1 inch; for example, 10 pitch equals 10 characters-per-inch or 10 CPI. Pitch is a term generally used with non-proportional (fixed-width) fonts.
PostScript Point
1/72th of an inch.