Bringing screenshots into Frame documents has four major considerations:
- how to perform the original screen capture
- how to post-process it in a graphics editor
- what graphical object model (and file format) to store it in
- making sure it isn't damaged by your workflow
1. Screen Cap, typically of dialog boxes ...
... used to be simple; isn't anymore.
Dialogs used to have identical pixel dimensions on all user screens. You hit Alt[PrntScrn] in Windows and you got a one pixel per pixel 24-bit color image on the clipboard.
More recent operating systems now have much more scalability in the GUI. So either capture at what the default user sees, or at the optimal presentation enlargement, which might be precisely 2x the default display.
2. Post
Before you even start this step, you need to know exactly how you will be presenting the final document out of Frame:
B&W? Color?
What dimensional size on the page?
If hardcopy, what are the optimal parameters of graphical images for your print process? If web or PDF, various other considerations arise. I'll presume print.
In our workflow, the print engine is 600 dpi bitmap. We normally present images at one column width, about 3.5in. Our PDF workflow passes 600 bitmap untouched, but resamples gray and color to 200 dpi. I tend to use 600 dithered bitmap, but always test if there's any doubt.
Chances are the screencap bitmap, at your native printing res, is too small. There is no "dpi" associated with clipboard images. Once pasted into an image editor, the editor should provide the ability to declare the dpi (Photoshop does, both at paste, and via "resize without rescale"). If your image editor doesn't, fire it. If you can't see and control dpi, you have no real control over this workflow.
Plan to save the final image in a format that at least supports linear dimensions (like EPS) if not explicit dpi (TIFF). Save out the image at the exact size you intend to use at import in Frame. Do you know how Frame scales objects? I don't. So do your scaling where you have control over how.
Play with the defined "dpi" until the linear dimensions match your planned import frame. If that dpi passes through your workflow unmolested, you may not need to perform any resizing.
If you need to convert from 24-bit color to bitmap (at your printing resolution), I'd suggest using error diffused dithering converting to your target res, as this tends to preserve the hard edges in dialog boxes and rasterized text.
If you need to re-scale, I'd suggest scaling up by an integer multiple, using "nearest neighbor", to the nearest size just higher than your target dpi. Then rescale bi-linear down to your target size.
3. File Format
The main consideration here is compression, followed by color depth and size encoding.
Screenshots tend to have expanses of flat colors, and hard edges. These objects compress reasonably well using repeat-count compressions (like ZIP or RLE). They tend to get damaged by curve-matching compression, like JPEG, because they typically contain no curves through color space. Hard edges get fuzzy or pick up ringing artifacts.
So don't use JPEG (and what compression will your workflow use?). I tend to use TIFF(ZIP) for screenshots.
Avoid indexed color (4-bit, 8-bit or 15/16-bit) color.
Don't use GIF. It has no size encoding. The usual presumption is that GIF is 72 dpi, which makes importing it a nuisance, and at least a minor math exercise. Plus, it's indexed color, and may scale poorly downstream.
Experiment. See what looks optimal in the final product.
4. Workflow
As you can see throughout the above, all your careful planning can be for nought it your save-as-PDF, distiller or print shop process resamples everything down to 90 dpi. You have to know what's happening, and how to optimize for it, or you probably won't like the result.
_______
We once had graphics showing up at 10 (yes ten) dpi in print.
Turned out the print engine could handle JPEG 5 but not JPEG 2000.
We had to hastily back-port images until a software upgrade fixed it.
1
Reply
AdChoices