TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
(Pardon my long-winded post here - it may help explain some things perhaps.)
Joe Pairman wrote:
> This is correct, and in fact what I was going to post until you got there first. The only slight
> qualification (and one that I'm not sure is relevant for this discussion, but is worth mentioning
> for completeness), is that the PNG format allows you to define a nominal PPI resolution in
> the file metadata. It is completely up to applications what they do with that information: some
> just ignore it, whereas others such as Adobe Illustrator use it to inform the initial (also nominal)
> dimensions of the image when you drag it into an Illustrator document.
Yes, noted and agreed!
FWIW, I do not use that kind of image meta-data info. Indeed, I have not looked to see how Snagit might allow it to be inserted in a capture. Probably because I don't use Adobe Illustrator, I suppose.
Perhaps the best way for people to understand about bit map files (from Snagit or anywhere) is to think of them as accurate representations of the color of each "pixel" in an image.
PNG is just one of many possible _storage_ formats of that bitmap information.
I.e., the specific bytes and actual format of a PNG _file_ is not important - this discussion could just as easily apply to a TIF or BMP formatted file of the _same_ capture.
As long as the chosen format is loss-less (and supported by the programs you want to use them in) ... i.e., JPEG does not work well for typical screen captures of vector information.
Setting aside the meta-data info a moment for simplicity, a bitmap image (whether stored in GIF, PNG, TIF, or BMP, etc. format) simply has an absolute X pixels total in the horizontal direction and absolute Y pixels total in the vertical, with color info (typically 24 bit - 8 each for Red, Green and Blue) for each pixel.
Very old GIF (pre GIF-89) files are limited to 256 total colors from a larger palette - I think of 1M possible colors - so it has to store a color definition in each file.
Again, for simplicity, I am not mentioning the additional bits that may be available for other color info (such as transparency, etc.) _or_ for scans done with 12 or 16 bits per R, G and B (resulting in 36 and 48 bit color images).
High resolution is typically for photographic images - my Epson 850 scanner does 48 bit scans (16 bits per R, G, and B) for example, and son's high-end Nikon DSLR camera captures 12 and 16 bits per color pictures.
Anyway, the larger the particular item is displayed and captured on the screen, the larger the values of X and Y numerically for a given capture.
So, if you zoom in _prior_ to a capture, the application program renders that item physically "larger" on your display (more pixels) and allows for a larger X and a larger Y in the captured file.
Then, _if_ the original source of information is vector data (which is converted on the fly to pixels on display by that application program), this makes the image _less_ pixilated when used later "reduced in size". BTW, some web sites use _different_ physical images based on what your browser tells them is the screen resolution, by the way ... this is how good Apple Retina compatible sites work.
(Lynne, this is why I choose to zoom in and "maximize" the item prior to capture - all text is generally rendered better, since the font is vector format and displayed with "more pixels" on the screen.)
After capture, the bitmap image _cannot_ then be "zoomed" in (or X and Y pixels increased) to create additional information - pixilation becomes obvious at some level, or the scaling method (interpolation of pixel data from the known data) becomes quite useless.
Any zooming of a bitmap on a screen is entirely dependent on how any given image display program (IrfanView, Photoshop, Xara, etc.) scales the _known_ pixel data to "display" on a given output screen (whether 1024x768, 1920x1200, 4K display, etc.)
Furthermore, since a given resolution (1920 x 1080, for example) monitor can be physically 20 inches, 24 inches, 27 inches, 31 inches, etc., the resulting _physical_ size of a PNG or TIF on a monitor is meaningless _unless_ the rendering program is aware of the actual monitor size and _also_ compensates by scaling, or truncating, the displayed pixels to achieve a given physical size on the screen.
Typical bitmap display programs do NOT do this ... afaik, even FrameMaker only uses monitor size information to "greek" text below a certain font size.
Basically, then setting a DPI for a bitmap image file is just a mechanical representation of how those pixels should be _output_ for some output devices... typically on a printer to achieve a certain physical size, because the dimensions of the paper are known and/or specified.
(BTW, as mentioned I could achieve exactly the same result as PNG formatted files by using TIF or BMP format files, although those have an entirely different storage formats _and_ meta-data. In most cases, keeping it simple is best.)
Z
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
