Graphics

Report · Jul 24, 2013

This question was posted in response to the following article: http://help.adobe.com/en_US/framemaker/using/WSd817046a44e105e21e63e3d11ab7f741c8-8000.html

Report · Jul 24, 2013

Why do images become bitmapped in FrameMaker? (I know...low resolution and the wrong type of file used...) However, my SME insists of using PNG images at 96 dpi. Our standard is: 96 dpi for small images; 150 dpi for medium images; and 300 dpi for large images (500 x 700 pixels max.) I've tried to explain this to the SME with no luck. He's making Snagit capture at 96 dpi. And I've been told to "ONLY USE HIS IMAGES THE WAY THEY ARE." I have some success with importing an image into a "frame" within a Anchored frame so that I can have a precise size for the image. But if I have to reinsert the image, size the image in FM, or just look at it "funny," it becomes bitmapped. Then I get the "evil eye" from the power-that-be for making bad images. Then I have to get a fresh image from my backup folder. What's a poor tech writer to do?! Why can't Adobe make the use of images in FrameMaker more stable...easier...? Don't they know they are ruining my life?! (I'm just kidding, hopefully!)

Report · Jul 24, 2013

SLBwriter wrote:
Why do images become bitmapped in FrameMaker? (I know...low resolution and the wrong type of file used...) However, my SME insists of using PNG images at 96 dpi. Our standard is: 96 dpi for small images; 150 dpi for medium images; and 300 dpi for large images (500 x 700 pixels max.) I've tried to explain this to the SME with no luck. He's making Snagit capture at 96 dpi. And I've been told to "ONLY USE HIS IMAGES THE WAY THEY ARE." I have some success with importing an image into a "frame" within a Anchored frame so that I can have a precise size for the image. But if I have to reinsert the image, size the image in FM, or just look at it "funny," it becomes bitmapped. Then I get the "evil eye" from the power-that-be for making bad images. Then I have to get a fresh image from my backup folder. What's a poor tech writer to do?! Why can't Adobe make the use of images in FrameMaker more stable...easier...? Don't they know they are ruining my life?! (I'm just kidding, hopefully!)

There's an easy fix for this. Get whomever is the highest-level arbiter to decide if the stuff's supposed to look its best, or if an arbitrary rule that makes it look bad is the ruling thing. It would help to show examples of what's possible the right way, and what you get the destined-to-degrade-and-fail way. Then, let that person decide.

You might get some advice by posting your question to the techwriter peers on the techwr-l.com forum. There's not a sliver of a doubt that you're in a unique situation.

HTH

Regards,

Peter

_______________________

Peter Gold

KnowHow ProServices

Report · Jul 24, 2013

Thanks for you great answer! The reason I posted my question was to see if there was anything I can do better with the images, and then I'll have more information to support my assertions to TPTB. I am not allowed to change the images...huh? The final output is hardcopy print. This was hunting for evidence, since I don't pretend to know everything. You and the next guy gave kind of opposite answers, which was good; it shows there are many ways to look at an issue. Here I go, wish me luck again.

Report · Jul 24, 2013

96 dpi images are low resolution images. They'll look okay on screen at

native size or smaller, but if you have to blow them up, you are going

to see jaggies. Pixels are small squares. If you blow them up, they

become BIG, obvious squares. You cannot change that. If you want to blow

up an image without jaggies, it needs to be saved at a higher resolution

so that it contains more pixels.

Your existing standard is: 96 dpi for small images; 150 dpi for medium

images; and 300 dpi for large images (500 x 700 pixels max.). This

sounds like a bad rule. Resolution should not be dependent on image

size. It should be dependent on output device. 96 dpi is the resolution

for screen. 150 dpi is sometimes used for desktop printers. 300 dpi is

for printing press (and also a better choice for desktop printers). And,

remember, this resolution is for images at native size. Your 500x700 px

maximum image, for example, would print at only 1.66"x2.33" at 300 dpi,

but would print at 5.2"x7.3" at 96 dpi.

It sounds like your SME has got the right idea. Screen capture best

practices generally call for capturing the image at native monitor

resolution, which is commonly 96 dpi. Then, if you want to blow up the

image, you don't resample it, you merely change the dpi in FrameMaker.

Yes, if you blow it up, you will see jaggies, but people understand

that about screen captures. Since screen captures are generally used to

capture menus, dialogs, and other items meant to display on screen,

there's generally no need to blow them up-- and I venture that most

don't. They are already at a size designed to be readable.

I'm not sure why you have a problem with FrameMaker's image handling. It

is VERY stable. I have books with thousands of illustrations in them.

And FrameMaker does not convert any images to bitmaps. If they are

bitmaps, they remain bitmaps. If they vectors, they remain vectors.

Depending on the image format you use, you may get a low resolution

preview image in FM, instead of a full-resolution image-- to reduce

memory size-- but it will print at full-resolution.

EPS is the most recommended image format. It handles vectors and

bitmaps, is both PC and Mac compatible, and passes around the Windows

GDI at print time-- so that CMYK images stay CMYK, instead of being

forced into RGB. EPS does give you the ugly, low-res preview, but prints

fine. If that bothers you immensely, use PDF instead of EPS. You'll get

a high-res preview at the expense of slower file loading and fuller

memory. I've not used PNG, so don't know it's quirks-- except to be sure

they are 8-bit PNGs. The higher-bit versions create hundreds of named

colors in FM.

Best practices are also to import graphics by reference, rather than

importing a copy. It keeps file sizes low, speeds up file loading, and

makes it easy to edit a graphic and have the changes reflected in all

documents that use it.

Report · Jul 24, 2013

Thank for your great help!

The screen captures are of software windows and items that are 96 dpi.

Would my images look better if I compress them?

I never had problems with FM images before, when I make the screen captures. My background in graphic art is robust...degreed...15 years experience..no brag...just fact. Mostly, I have used Photoshop and Illustrator to manipulate and create images and import them by reference. Then I save the file to PDF for printing and delivery. The SME uses Snagit. But I thought it should not matter.

My question was rhetorical, but I did get some good info. Other people here at work have the same issues with FM and images.

As a contractor, I get intimidated easily by TPTB; this one in particular. Thanks for the encouragement.

Report · Jul 24, 2013

Some observations on the prior postings:

1. images are bitmaps

2. dpi (dots per inch) does not equal ppi (pixels per inch) (see: http://forums.adobe.com/thread/370714)

3. FM doesn't give a rat's a** about your image's dpi. It uses the number of pixels and your specified import dpi to size the image.

4. 8-bit PNG files are indexed and will generate colour definitions in FM's colour table. You need to use 24-bit PNGs to avoid this.

5. The preview image in an EPS file is dependent upon the application that created it. It can be a high-res colour one too.

6. PDFs are internally converted to EPS in FM (using the same mechanism as saving as an EPS from Acrobat).

7. if you use a lossy technique, such as in the JPG format, to compress images, then it can degrade your image and add artificats (especially for screen captures). Non-lossy compressions such as used in PNG and TIF files do not affect image quality.

Report · Jul 24, 2013

Maybe you need to take a nap. I'm not allowed to change the images I was given, although I certainly know how. Why do some people assume the worst of others?

Report · Jul 24, 2013

Nothing was said about changing anything. Some inaccuracies in prior statements were addressed. How you use the information is totally up to you. Why are you making assumptions?

Report · Jul 24, 2013

IDK: Maybe it was your gruff manner. Your answer was totally useless, BTW. Go back to your bottle.

Report · Jul 24, 2013

Don't poo poo Arnis' post. Except for possibly line item #1, I agree on

every point. The guy knows his stuff.

Report · Jul 25, 2013

BTW. Go back to your bottle.

Remarks like that do not inspire anyone to help you.

Report · Jul 25, 2013

The original post was about the quality of the output. At least that is how I interpret it. Another post mentioned printed hard copy. How is it made?

IF you made a PDF from the FrameMaker document and then printed that, it may be that your PDF settings were such as to worsen the quality of the printed images. It is nothing that FrameMaker did. It was the PDF creation process.

Something else to look at.

Van

Report · Jul 24, 2013

Hi, Arnis:

I always get lost in these discussions. But, IIRC, in the old days, Dov Isaacs would periodicaly pop in and give a workflow for resizing bitmapped images via some resampling steps in Photoshop, I believe it was. Perhaps methods have changed, or opinions have changed, but if you remember in more detail, or if Dov is watching over us, a little more light might be shed.

HTH

Regards,

Peter

_______________________

Peter Gold

KnowHow ProServices

Report · Jul 24, 2013

> ... resizing bitmapped images via some resampling steps in Photoshop ...

I would have included the steps I use, but our OP is apparently not at liberty to do it.

Basically:

upscale by an integer multiplier, using NN, to at least twice the final pixel dimensions
convert BM to 8-bit gray; IC to 24-bit color
rescale to the target image size and desired res, using bicubic or bilinear interp, whichever looks better
reconvert to BM or IC using ED dither
if I had to save as PNG, use a repeat-count (lossless) compression, and not a curve-matching (lossy) compression

Report · Jul 24, 2013

Rescaling an image (interpolation) is different from resizing and as far as I can tell, the OP just needs to fit (resize) the screen capture into a fixed-size area.

To do this in FM, the image dimensions (pixels) need to be divided by a user-specified dpi in the FM import options, i.e. a scalar, to get that fit. Optimum quality on the output is obtained when the FM "dpi" value is an integer mulitplier of the output device's resolution.

Report · Jul 24, 2013

Arnis,

You don't consider an Illustrator drawing to be an image? Maybe I've

been using the term wrong. It sounds like you want to limit it to

bitmapped graphics.

I know about the minor difference between dpi and ppi, but don't usually

take time to explain it.

Thanks for catching the PNG 8-bit error. As I said, I don't use PNGs,

and remembered it wrong.

Report · Jul 24, 2013

Mike,

In my hierarchy of usage, a "graphic" can consist of images and drawings. An "image" is a raster/bitmap and is not easily rescaled (without affecting the quality). A "drawing" is vector artwork and is effectively infinitely scalable. Some file formats (such as AI, EPS, PSD and PDF) support both formats, so one should be quite specific about describing what content one is working with.

So the OP's opening statement probably needs some further clarification for the usage of the term "bitmapped" (as an image already is a bitmap). Was this meant to be "pixelated", i.e. over-enlarging an image to the point where individual pixels become prominent ?

Report · Jul 24, 2013

> Why do images become bitmapped in FrameMaker?

They don't, assuming we are talking about rendered output, and not editing preview, which is a different matter.

> Our standard is: 96 dpi for small images;

Then you are doomed unless:

1. You use the image at the exact capture dpi (no rescaling by FM), or

2. at an exact integer multiple or fraction of that resolution, or

3. you build enough graphics skills that you can quietly optimize quality (or at least minimize collateral damage) without getting caught violating policy.

> ... so that I can have a precise size for the image.

I'm going to guess that these PNGs are either bitmaps (bi-level) or indexed-color as given to you, rather than contone gray or contone color.

Bitmaps and indexed-color images essentially don't scale, except at integer multiples and fractions. Without informed guidance from an image steward, any arbitrary non-integer scale factor forces use of "nearest neighbor" (NN) interpolation technique. NN visibly exacerbates what in your case is already a coarse raster image of marginal quality.

This is fundamentally not an image management problem.

It's a management problem.

Report · Jul 25, 2013

I don't really understand the problem here. The SME is taking screengrabs off his screen, which generally *is* a 96dpi bitmap - i.e. SnagIt is just copying the pixels off the screen and putting them in a PNG file for you. It's not degrading them in any way, it's capturing them perfectly. You then import it into a anchored frame in FrameMaker, when you can stretch it to whatever size is convenient.
Whether that looks a mess on your own monitor screen will depend on how zoomed in you are or not - but it won't change the fact that all the pixels the SME captured are still there, safe and sound, none added, none taken away.
What happens next, are you making a PDF? If the screenshot looks like hell in the PDF, you are probably using unsuitable Distiller settings, you should choose betters ones (lossless compression, higher DPI, etc)

Report · Jul 25, 2013

> ... off his screen, which generally *is* a 96dpi bitmap - i.e. SnagIt

> is just copying the pixels off the screen and putting them in a

> PNG file for you. It's not degrading them in any way, it's capturing

> them perfectly. You then import it into a anchored frame in

> FrameMaker, when you can stretch it to whatever size is convenient.

I played a bit with some screencaps to PNG, as indexed color and

bitmap

Yep, as long as the final rendered resolution, on both axes, is coarser

than the PDF downsampling settings, the pixels are passed through

unchanged. They remain unchanged until hitting the display frame

buffer or the printer, where they typically must be rescaled to match

whatever rasters those use.

If an author is incautious enough to rescale by free corner drag

(anamorphic), the result can be non-square pixels, but there is still

no resampling going on until the final display surface. It remains

indexed color or bitmap in the PDF.

However, if the image is higher resolution than the configured PDF

downsample trip point, or is rescaled with that result, it appears

that Save-to/as-PDF printing or Distilling is causing it to be

converted to contone, rescaled, and left as contone in the PDF.

96 dpi screenshots (of dialog boxes in this case) can look pretty

awful as indexed or bitmap, but the FM->PDF process, even with

re-sizing in FM, doesn't make them look appreciably cruder.

Of course, we don't even know that the PNGs in question are

indexed or BM.