Page 1 of 1

Standards for capturing images for web and pdf output.

Posted: Mon Oct 10, 2016 1:19 pm
by neilm
Hello

I would like to establish a set of guidelines for our tech writers to follow when capturing screenshots for inclusion in Flare topics, so that the images will render well in our different output formats (HTML5 and PDF) for different devices (hello, Retina display devices)

Couple of notes:
- the images are captured as raster (.png or .jpeg) images), since we don't control the source and cannot easily produce vector (.svg) images. (Yes, one CAN capture png and convert it into svg, but it results in artifacts you have to manually clean up, and the resulting svg is a best-guess by software, which inevitably results in poor guesses by the software)
- we're not capturing three copies of the same image to handle each of the primary outputs/rendering (HTML5 output for "standard" resolution screens, alternate HTML5 output for Retina screens, PDF output for printed content). Just, No. With the volume of screenshots and frequency of changes we're faced with, capturing 3 separate copies of the same image would be monumentally time-consuming. Capturing one image is already work enough.
- we're totally fine with editing css to make dynamic image sizing work. But doing so usually results in large source image files that are then processed by the client, and unpredictable output since you're at the mercy of whatever the client browser/renderer decides to do to the image. Not ideal. While we have the css skills, I just don't think it's a pragmatic approach.
- I'm not a complete image editing beginner, but perhaps I'm overlooking something obvious like DPI or native resolution considerations.
- I have reviewed some previous threads (e.g. viewtopic.php?f=18&t=27983&p=123106&hil ... ot#p123106, viewtopic.php?f=10&t=27140&p=119728&hil ... ts#p119728) as well as product documentation, but they don't really answer the question, which is:

#########
How should you capture screenshots for the best possible output?
#########

So, does anyone have guidelines for capturing images?
For example:
1) What screen resolution should you use when capturing images? The largest (e.g. 1024x768), or the highest (e.g. 1900x1200)?
2) if you're capturing images from a VM, is it better to run the VM in full native resolution on your host machine so as not to introduce resolution variances? Or should you install the image capture software on the VM ?
3) Whether there are better ways to resize images that result in the, errr, "crispiest" image output? (given that we're working with raster, not vector)
4) What DPI should images be saved at for best output in HTML5 for both retina and non-retina devices?
5) any post-capture tricks one can do to crispen-up the image? (I use Snagit to capture, crop and resize and then usually apply the Sharpen 75% filter, but this sometimes results in inconsistent quality depending on the contrast available in the screenshot)

I apologize if the question in fundamentally stupid because of very different output processing. I'm just trying to give my writers some consistent set of guidelines so we can capture screenshots consistently and not have too many blurry images in our outputs across multiple devices.

Any tips or suggestions are much appreciated!

Re: Standards for capturing images for web and pdf output.

Posted: Mon Oct 10, 2016 2:26 pm
by SteveS
When capturing images for our microsoft range of resources I set my virtual machine screen resolution to the minimum resolution from Microsoft's system requirements.

It's all about the user. What screen resolution is the lowest, or most common, used by the end users? Use that to setup the machine (virtual or physical) you use to capture the screen shots.

There is a lot of information on these forums about screen capturing, resolution, and resizing.

Basically:
The windows display is 96 dpi, apple 72. That means when you capture a shot there will be a matrix of dots displayed with 96 to the inch. If you change the image resolution to 300 dpi you will not increase the number of cells in the matrix but the image will display the dots at 300 to the inch, making the image 1/3 of its original size.

If you want to resize an image, or increase the resolution, you are better off using a graphics package to resample the image and then use the unsharp tools to sharpen the image. But really, why bother? a 96dpi image (not resized) is as sharp as you will get from a screenshot.

If your screenshot is too big consider screen portraits or cropping the image to highlight the detail. As I've explained elsewhere physically resizing an image will nearly always result in a loss of crispness as the graphic engine tries to display the image resolution matrix over the screen matrix. Unless there is an exact mathematical relationship (ie a 192 dpi image on a 96 dpi display) it doesn't work and why convert 96 to 192 when all you are doing is copying a rgb value to 4 squares, making the image half the size, so you make it 200% to return it to the original size and the graphics engine converts the 4 squares back to 1.

I have capturing software on both the VM and host machine. If you run the capture software on the host you get better performance but you cannot use the advanced capture properties (ie you can't capture a window because the application is already in a window according to the host).

HTH

Re: Standards for capturing images for web and pdf output.

Posted: Fri Oct 14, 2016 1:20 pm
by Carsten Pedersen
My biggest problem is multiple contributors capturing images (e.g. software dialogs) in different DPI. This renders very strangely in e.g. PDF files.

-cpede

Re: Standards for capturing images for web and pdf output.

Posted: Sun Oct 16, 2016 2:25 pm
by SteveS
Carsten Pedersen wrote:My biggest problem is multiple contributors capturing images (e.g. software dialogs) in different DPI. This renders very strangely in e.g. PDF files.

-cpede
You wouldn't believe some of the stand-up fights we've had with people who claim 'you must capture images at 300 dpi to get the sharpest images..."

"The more dots per inch, the better!"

If only they understood.