RE: SOLVED - blurry screen captures - Snagit for Mac (4.1.2) -- DOES ANYBODY REALLY UNDERSTAND PNGs?

["Wright, Lynne" <Lynne -dot- Wright -at- Kronos -dot- com>]

Thanks... that DOES clarify things a bit (at least for me). 

I did find that, when adding callouts, the key to maintaining sharp resolution was sizing the image to the width that I wanted it to be in the final doc...ie resize the image inside the app that you use to add callouts, rather than resizing the resulting image+callouts graphic after importing it into a Framemaker or html help file. Doing the latter caused the resolution to start falling apart (because pixels are not resampled to fill in the increased amount of space). 

-----Original Message-----
From: techwr-l-bounces+lynne -dot- wright=kronos -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+lynne -dot- wright=kronos -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Sweet, Gregory P (HEALTH)
Sent: April-07-17 12:19 PM
To: Monique Semp <monique -dot- semp -at- earthlink -dot- net>; TechWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>
Subject: Re: SOLVED - blurry screen captures - Snagit for Mac (4.1.2) -- DOES ANYBODY REALLY UNDERSTAND PNGs?

Monique never said if this was for print or online. Since she is working in Google Docs I am going to assume print. 

Simple process for print:

1. Take your screenshot
2. Determine from your document what the output dimensions will be.
3. Resize the image to those dimensions, do not allow resampling.
4. Edit and add callouts. (your image is now at output resolution, so fonts will render at the intended size.) 5. Save the image.
6. Import it into your document.

Raster images lose clarity when you resample the image, not when you resize it. Resampling either forces the software to make up pixels to fill in the gaps, or throw pixels away to make the image size smaller. When you prevent resampling, you force the software to keep the same number of pixels and instead adjust the size of each pixel. Since the workflow is usually to scale down images, preventing resampling works just fine. When you scale up and make the pixels larger you will eventually hit a point where you lose clarity as each pixel becomes large enough to be individually discerned (grainy images).

By zooming in on an image before taking a screen capture you increase the number of physical pixels in the image. When you reduce the size of the image and allow resampling there is more data for the software to choose from when selecting what to throw away, so you get a bit cleaner image. If you prevent resampling you are cramming more pixels into the physical space allotted for the image so you get a clearer image. Likewise, if you scale up you have more pixels to begin with so you can go larger before individual pixels can be picked out. Hence why a 1 megapixel image cannot be scaled up as much as an 8 megapixel image. If you are old enough to remember film, you might recall that the higher the iso of film, the larger the silver halide crystals, which meant that enlargements go grainy at smaller sizes.

Iâd include how to resize without resampling in Snagit for Mac, here but my trial has run out and my purchase req has not gone through yet, so I am temporarily without Snagit.

Online images are a bit trickier because you have to account for a range of target pixel densities, anything from 72ppi to well over 366ppi, and you cannot adjust the ppi for just your image. You have to consider the two pieces together to maintain clarity across displays, that is you cannot just say itâs a 1024x768 image, itâs a 1024x768 -at- 96ppi -dot-  If you want it to be 1024x768 -at- 192ppi, and are creating the image on standard desktop*, then you have to create an image that is 2048x1536 -at- 72ppi or in the common vernacular these days an @2x image. If you want it to display the same on both displays, you have to write some css media queries to control the imageâs physical height and width based on screen res. This is why recent updates of Photoshop, Illustrator, etc. introduced new export features to export images @2x, @3x, @4x, etc.. Since you cannot decide what size pixels the screen is using, and you cannot adjust the pixel size used, you are left with only controlling the number of pixels in the image, i.e., resampling.

*Standard desktop monitors only have a 72 or 96 ppi density because thatâs what manufacturers arbitrarily decided would be the standard. Even the fancy 27â Thunderbolt display I am sitting in front of right now has only a 108ppi density. Laptop, tablet, and smart phone makers have thrown that standard out the window to cram more and more pixels into a physically smaller space. This can only be accomplished by reducing the size of each physical pixel so for a bonus mind-bending experience, go Google âcss pixels vs physical pixelsâ.

A simple process for online might be:
1. Define your target resolutions.
2. Determine your scale factor from the resolutions of your capture and editing devices (account for both if different).
3. Edit your screenshot and add call outs.
4. Export your image set.
5. Apply css or another technique to display the correct version of the image and/or determine the appropriate display size.

Cheers!

Greg



On 4/7/17, 10:27 AM, "techwr-l-bounces+gregory -dot- sweet=health -dot- ny -dot- gov -at- lists -dot- techwr-l -dot- com on behalf of Wright, Lynne" <techwr-l-bounces+gregory -dot- sweet=health -dot- ny -dot- gov -at- lists -dot- techwr-l -dot- com on behalf of Lynne -dot- Wright -at- Kronos -dot- com> wrote:

    ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.
    
    
    I'm confused about why zooming in before taking the screen shot would make a difference. As you said, the number of pixels that makes up an image is fixed; and the amount of visual information in each pixel is fixed. So no matter what the zoom level of the object that you're taking a screenshot of, the image is going to contain the same number of pixels; its just that the larger the image, the larger the pixels within it are. So isn't it the resolution of the screen that makes a difference, not the zoom level? Ie. higher res screen image = higher density of pixels = higher res png capture?
    
    If you add callouts then export the resulting image as a png, changing the dpi when you export doesn't affect the output resolution, but it does determine the display size.  So Monique, that could be the key to your problem of the callouts being too small in the final image; if you export the doctored image at a higher dpi, it should increase the display size of the callouts. But the underlying image will also be bigger, so you'd have to experiment to figure out some standards in terms of how to size the png image when you're adding callouts, so that you get the correct ratio between callout display size and height/width of the labelled image when you import the image into your doc.
    
    I found this article somewhat helpful http://www.webdesignerdepot.com/2010/02/the-myth-of-dpi/ ; but it still kind of astonishes me that in all of the internet -- as well as in this forum of tech writers -- I have never found a simple, clear explanation of how to take a png, add callouts, and insert it into a doc or help system, without running into resolution or sizing issues.
    
    Anybody?
    
    -----Original Message-----
    From: techwr-l-bounces+lynne -dot- wright=kronos -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+lynne -dot- wright=kronos -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Syed Zaeem Hosain
    Sent: April-07-17 3:37 AM
    To: Monique Semp <monique -dot- semp -at- earthlink -dot- net>; TechWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>
    Subject: RE: SOLVED - blurry screen captures - Snagit for Mac (4.1.2)
    
    Hmmm ... I don't use the Mac version, but have become confused by some comments made in this discussion.
    
    First and foremost, Snagit simply captures what is on the screen - the color of each "captured" pixel if you will. The fact that it uses PNG format by default is because this is simply a loss-less storage format of those pixels.
    
    So, there is no "font" inside the captured image - any "text" is simply what pixels were "shown" by the particular program that rendered that text on the screen. So, whether I show that text from Photoshop, Word, an application menu ... even Chrome or Edge ... is quite irrelevant really.
    
    An image in PNG format does not have any concept of pixels / inch or anything like that - the image is simply a certain number of pixels in each axis. This size is influenced by the choices you make with your rendering program to begin with.
    
    So, what works well for me is to simply increase the display of what I want to capture on my screen as reasonably large as possible ("zoom in without showing rendering artifacts").
    
    As long as the image is rendered well for that display (whether it is a 1920 x 1200 monitor or a 4k display is not too critically important - depending on what I am capturing) in the first place, Snagit will simply capture those pixels as rendered by the underlying program.
    
    Of course, it is mildly important that the image on the screen is not pixilated due to too much zoom - like an image from a web site designed for a low-res display. Often I am capturing from PDF renders on my screen, and since this is a vector format, zooming in often produces perfectly good images (of text renders for example) for capture.
    
    Then I capture using Snagit with that "relatively maximized" image and proceed to crop and edit as needed.
    
    This generally creates a decently sized captured image, meaning "a maximal number of pixels on each side of the image capture". Which (when used in FrameMaker or Powerpoint or elsewhere) provides me good visible quality - of course, FrameMaker wants to use a particular dpi when importing that image ... I just use a value large enough to give me a good fit to the frame. No blurring of the kind discussed here.
    
    Yes, I use PNG format to store my screen captures, since it is loss-less and does not create the pixel color artifacts that JPEG does, since JPEG is designed to compress photographs that have "relatively" benign color transitions between pixels ... unlike a screen capture of something like the menu of a program. So, JPEG has a "quality" control that optimizes the compression ... too much compression and you really lose quality!
    
    JPEG "introduces" pixels around color transitions that the human eye simply blends together - this is very bad when the image is not a photograph ... solid color lines get "blurred" by other color pixels, etc.
    
    Never use JPEG when the image you are capturing has large sections of solid color ... like menus, charts, line drawings, and the like.
    
    Z
    
    -----Original Message-----
    From: techwr-l-bounces+syed -dot- hosain=aeris -dot- net -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+syed -dot- hosain=aeris -dot- net -at- lists -dot- techwr-l -dot- com] On Behalf Of Monique Semp
    Sent: Thursday, April 6, 2017 04:17 PM
    To: TechWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>
    Subject: SOLVED - blurry screen captures - Snagit for Mac (4.1.2)
    
    Well, I bit the bullet and spent quite a few hours today learning Snagit for Mac. It's *very* different from my Snagit for Windows version 10 (maybe the newest Windows version is similar to the Mac version, but I don't know).
    
    The interface, for me, is the opposite of intuitive. It seemed like I was learning a totally new program. And TechSmith hasn't made it easy with their emphasis on videos instead of a well-written Help doc.
    
    But now I've drastically simplified the workflow: take a capture, save it as <name>_capture.snagproj, save the version I'll edit as <name>.snagproj; edit to increase the canvas size (otherwise the resultant PNG doesn't include anything outside the original capture size even though you can see it all in the editor!), add a border, callout lines, and text -- I saved my styles, which are minimalistic instead of the cartoonish defaults, in a theme, which is a nice feature I hadn't used -- save the <name>.snagproj file, and Save As the PNG.
    
    When I import the PNG into Google Docs, everything is now perfectly clear.
    The only oddity is that the font really seems much smaller than it should.
    Snagit says it's Arial 10 pt, but it's very small in the actual PNG. So something odd there, I'm just letting that go so I can return to creating content.
    
    I continue to be frustrated by the inability to specify a capture resolution or specific size in Snagit for Mac, the inability to resize an image to a specific physical size (in both Google Docs and Snagit for Mac), and the lack of info about what resolution the final PNG ended up (the Finder > Get Info shows the image's *dimensions*, not resolution info, which I don't think are the same thing?). But I do have crisp images and good text/callouts with a minimum of back-and-forth between tools. So that's a giant improvement.
    
    Hope this info helps someone,
    -Monique
    
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
    
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    You are currently subscribed to TECHWR-L as Syed -dot- Hosain -at- aeris -dot- net -dot- 
    
    To unsubscribe send a blank email to
    techwr-l-leave -at- lists -dot- techwr-l -dot- com
    
    
    Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit http://www.techwhirl.com/email-discussion-groups/ for more resources and info.
    
    Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com
    
    Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
    
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    You are currently subscribed to TECHWR-L as Lynne -dot- Wright -at- kronos -dot- com -dot- 
    
    To unsubscribe send a blank email to
    techwr-l-leave -at- lists -dot- techwr-l -dot- com
    
    
    Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit http://www.techwhirl.com/email-discussion-groups/ for more resources and info.
    
    Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com
    
    Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
    
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    You are currently subscribed to TECHWR-L as gregory -dot- sweet -at- health -dot- ny -dot- gov -dot- 
    
    To unsubscribe send a blank email to
    techwr-l-leave -at- lists -dot- techwr-l -dot- com
    
    
    Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
    http://www.techwhirl.com/email-discussion-groups/ for more resources and info.
    
    Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com
    
    Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives
    

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as Lynne -dot- Wright -at- kronos -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives