Question on Framemaker 12 and Blurry Graphics

[gary.knighting]

Starting out with a very clean, crisp 45" wide graphic saved from a PDF file, I copied the image into Photoshop CC 2014, re-sized it to approx 5.5" and saved it as a Maximum Quality:12 JPG. The reduced file looks great in my other applications too. I then imported it into FrameMaker 12. The image displays in Frame extremely blurry and also prints from Frame blurry too.  (Note that it doesn't seem to matter if I select "By Reference" or "Copy into Document" as I get the same blurred mess.) While I can view a clean and very crisp image in Photoshop, or Acrobat 11, or any other software for that matter, the image is looking terrible in Frame. What am I missing here?

Thanks for your help!

[David__D]

I wouldn't worry too much what it looks like on-screen in FrameMaker, only what it looks like it your output from FrameMaker.  (You say you're "printing" from FrameMaker...?)

If the graphic is in a PDF in the first place, I would just keep it in the PDF!

Assuming you have Adobe Acrobat, use Acrobat to extract the particular page that has the graphic, and crop it, and save that as a new PDF.

Then just import this new PDF directly into FrameMaker, and set its zoom level within the anchored frame to make it the right size.

That way, you don't resample any pixels or apply lossy compression to anything.

[gary.knighting]

David D:

Thanks for responding. Unfortunately, I do have to worry about what I see in FrameMaker because the final delivered product, whether the .fm file is sent directly to the printer, or saved as a PDF and either displayed or sent to a printer, looks identical to how it displays in Frame; corrupted. As I mentioned in my initial message, the graphic originated from a Word document that had been saved in PDF format. I opened the document in Acrobat 11, copied and pasted the image into Photoshop CC 2014... again, all looks wonderful and crisp... reduced it to the desired size and saved it as a high quality JPG... again, all looks great when the image is viewed using a variety of viewers... then imported it into Frame and it looks terrible. You could open the reduced image right now and it will display and print just fine in other viewers and on a variety of printers. It is during the import into Frame that it corrupts and Frame's output is the same as the Frame display. Our policy is to use JPGs for all of our images, not PDFs.

Janet

[Seanb_us]

What is this image a picture of?

The new image is 12% the size of the original. That's a huge change. Imagine the original was 200ppi, then at 45" x1" wide it was 9000 pixels horizontally and 200 vertically, for a total of 1800000 pixels. At 5.5" x 1" there are now 220000 pixels. You removed 1580000 pixels out of your original image.

So, what happens when all of those pixels are removed? Software algorithms have to figure out how the image transitions between adjacent images. In short, quality will decrease a lot.

Also, you are using JPEG format. This lossy format compresses the image by throwing away data. So, each time you save the image, the quality of the image is reduced.

Additionally, when doing this kind of work, you need to begin with the source file. PDF is a destination, not a journey , so you need to get the original file from which the PDF was created.

So, what you are missing is this: the correct image for the job. You really cannot expect to use the same raster image for 45-inch output as well as 5.5-inch output. And, it comes back to, what is this an image of?

As an aside, the STC Houston hosted an event on Using Graphics in Technical Communication (my presentation) that discsussed this topic and approaches. Perhaps they have something available from that meeting (http://www.stc-houston.org/programs/)?

Cheers,

Sean

[Bob_Niland]

With imported PDF and EPS images, what FM shows to the author during edit is the 72 dpi preview or thumbnail image encoded in the graphic file (or a gray box if none is present).

On Windows, if you print to a non-PostScript printer (such as an HP LaserJet using the PCL driver), FM actually prints the thumbnail, because it doesn't pass the full-resolution PostScript image data to anything but a Ps or PDF print path, and evidently declines to interpret that data and pass it to the Windows GDI (Graphics Device Interface API). This is all a holdover from the early days of Windows PCs, when the PCs simply didn't have the performance to perform display PostScript (and it's overdue for a fix in FM).

When you Save-As/Print-to PDF. or print to Ps and Distill, the PDF will contain the full image detail. If you only have a non-Ps printer, your PDF reader can then print the PDF of your document at full resolution. The PDF reader knows how to hand the Ps data structures to the Windows GDI.

If you have a recent printer, you may have the option of installing either/both the native PDL driver (e.g. PCL) or a PostScript driver. All recent HP LaserJets offer this as far as I know.

When I need to precisely preview an image that I want to import as EPS or PDF (such as for precise callout arrow placement), I'll use Photoshop to render a TIFF of it at the printing resolution (usually 600 dpi). Once the FM edit is complete, I'll re-import the EPS or PDF, replacing the TIFF. This reversion is important for images that have vector or stroked text content. If the image is entirely raster anyway, there's no harm in just using the TIFF. Another hack is to rescale the original EPS or PDF in Illustrator, then import at 25% in FM. This provides a more detailed preview to edit with.

It's also worth mentioning that EPS and PDF previews and thumbnails take up space in the file. These aren't visible in the final PDF, but the space they occupy can easily be larger than the real image data. You can strip this metadata in Acrobat Std/Pro. I've seen the size of a PDF drop to 1/3 doing this.

[Seanb_us]

I think the problem image is a JPEG not a PDF.

[gary.knighting]

Sean:

Do you have a suggestion that may work for us then? Our docs will be translated into numerous languages, including Japanese and Chinese. My research indicated that JPG was the only widely used graphic format that would survive the various translation software.

Janet

[Seanb_us]

Hi,

What is it an image of?

Also, not sure what you mean by "survive the various translation software." I would note that all localization vendors should be able to handle PNG, JPEG, TIFF, in addition to AI and PSD, if not CDR (certainly, if they can handle your FM files, they can handle all of these graphics formats). Additionally, translation to another language should not alter a raster image -- I am curious about your translation workflow.

Thanks,

Sean

[gary.knighting]

Sean:

The images are of various computer hardware. As far as translation, not all vendors can handle PNGs and TIFFs, or PSDs. According to what I have researched online to date, some can, some cannot. The problem seems to be in planning for SOME of the Asian translations, as most Western and Eastern European can handle PNGs, PSDs, and TIFFs.  I am planning for the future here and developing a workflow, so figured now was a perfect time to ask. Want to make sure I am using the most widely used format, and it appears JPG is. Some of these clients will be editing these images to customize the documentation.

Janet

[Jeff_Coatsworth]

I’ve never had to do it, but I always thought it was a bad idea to put translatable content in your images – like callouts or pointers. I’ve heard in recommended that you just stick with numbers so that your numbering guide is the part that gets translated & not the image.

[Seanb_us]

Hi,

You can't translate words in a raster image. The words and letters don't exist; they are pixels.

But, what you can do is use a format that supports text and layers, like AI or PSD, and include the text on a layer and have the layer translated. Or, you can add the callouts in FM and have the callout translated as part of your FM file translation.

Sean

[gary.knighting]

Great to know. Thanks Jeff. I'll keep that in mind. This image is just a good-old-fashioned JPG with no callouts, etc.

[Seanb_us]

If that's the case, then it doesn't matter if your translation service can handle your images. Import the images by reference, but only send the FM files to the translation vendor. The translation vendor will translate the words in FM, send you the files back, and FM can find the graphics again when you supply the expected folder location. But still, don't use a vendor who cannot handle those images. Also note that I would expect you to need only one (maybe two) translation vendors.

[Seanb_us]

Hi,

(Sorry, for some reason I thought Word was involved, but you went from PDF to JPEG, and then imported the JPEG by reference into FrameMaker.)

With a side thought to translation: rasters like JPEG/PNG won't be translated. Also, these file formats are a global standard (as are TIFF, PSD, and AI). I would stay away from any translation vendor who cannot handle these few image formats.

Back to the graphic at hand, I recommend getting the source image that was used in the original PDF. I am not sure if this is originally a photograph or illustration. Anyway, 45-inches is way too big for 5.5-inch output, so see if the various images of computer hardware are available separately in their original format. Begin with the original format of those images, not processed PDF output.

Resizing any raster, such as JPEG, by 80% is going to destroy the image quality of any raster image because of the huge data loss involved.

FrameMaker handles JPEGs just fine. So, am really not sure what the issue could be. Can you tell me

• When you imported the image into FrameMaker, what display setting did you choose?
• What resolution is the JPEG you are currently using and what are its pixel dimensions.

Thanks,

Sean

[Bob_Niland]

> I think the problem image is a JPEG not a PDF.

The things to look for on JPEGs are encoding problems, such as:

• Image was saved out of Photoshop as Indexed Color
• Image was saved in a format that something in the workflow doesn't support, lie JPEG 2000.

[gary.knighting]

Again, as my earlier message details, the image is a standard high quality JPG file. Nothing more, nothing less.

[Bob_Niland]

> ... image is a standard high quality JPG file.

No such standard thing. Now, had you said it was a 24-bit (8-bit/channel) RGB space image, using sRGB, Adobe RGB or no color profile, and encoded for ISO/IEC 10918-1, then I'd agree it's a more or less "standard" JPEG file. Many users have no awareness of these details. Often this is due to experience with Microsoft products, where the philosophy is "you don't need to know, and we won't tell you even if you ask".

> Nothing more, nothing less.

Then that can't be the problem, can it? If you don't want our help, just say so.

The common ways for people to get into trouble with JPEG include:

• JPEG often comes out of the camera, or out of the image editor encoded for a low resolution, or not encoded at all, which typically defaults to 72 dpi. Anything less than 200 dpi is usually too low for publication quality. Such images will usually have extents (overall inch/cm dimensions) too large.
• If you re-size by re-samplling/scaling, the dpi can easily be left too low.
• Those who are aware of JPEG's limitations will often immediately convert the incoming RGB image to a less destructive color space, perhaps more bits/channel, or even a different color model (CMYK, LAB, etc.), to minimize artifacts and res loss during edit. If we fail to re-collapse to 24b RGB before save, we can create a valid JPEG file that downstream apps can't use, or display in a degraded fashion.
• Those unaware of image management traps may convert the image to a lower quality and possibly not even realize it. Scenario: user saves image to GIF for separate web page use (typically an 8-bit 72 dpi indexed color format), makes some further edit and then re-saves to JPEG. The JPEG is now a basically ruined 8-bit indexed color low res object (and one that scales very poorly to print and screen).

I further concur with Arnis to avoid JPG in FM documents. You may have no choice about it coming in from many cameras as JPG, but immediately save it as .PSD as your master copy, and on completion of edits, save out a separate EPS or TIFF as the final import object. You can rescale before saving to EPS/TIFF, or just let the PDF workflow downsample it for you.

[Seanb_us]

From what I have read, this issue seems not a color one. Also, JPEG as a format should be no more difficult in FrameMaker than other tools, such as Word or Photoshop. Of course, JPEG might be an incorrect choice for a format based on the image itself and its destination output. Anyway, there's something else going on here -- different images are being compared, etc. I am curious to learn back about resolution and pixel count.

[gary.knighting]

Think I have figured out what is going on. As I mentioned, I found the original graphic file. This time, I tried importing the original without trying to resize it first in Photoshop. I accidentally typed the wrong value in the dpi field and got a message that Frame cannot handle that size bitmap. Funny, because it is showing that it is a JPG in the file description area. Anyway, I used Frame to reduce the graphic to the smaller size and it is looking fine. So, makes me think that there is something going on between the process Photoshop uses when saving the JPG and FrameMaker. So, going to avoid the headache and just let Frame resize my graphics. Thanks for your help everyone! Especially with the translation ideas!

Janet

[gary.knighting]

Not sure why you would think so! I am absorbing a ton of great info from everyone that is going to be super useful as we get deeper into this project. Just frustrated with this darned image! I can't for the life of me figure out what is wrong because it doesn't appear to be the image when I look at everything I know about it. I actually found the original, which is 45.33" and I reduced it and everything is great until I import it. Same problem. So, this darned thing has me very baffled! It has to be something in Frame that is changing the entire picture, so I am going to play around with it over the weekend using some of the suggestions here and see what I might learn! Thanks everyone!

Janet

[Arnis_Gubins]

Janet,

The 45.33" description of the original image is completely meaningless for use in a publishing application. If you could supply the number of pixels (height & width) in the original image, the number of pixels in the reduced image (and perhaps mention the function that you used to "reduce" the image)  and the dpi that you are specifying in FM, that would help determine why you are getting less than optimal output image.

[gary.knighting]

Sure, sorry... missed that earlier... the original was 3264 px x 2448 px, Width was 45.33, height 34. The new image was 386 px x 290 px. Width 5.3625 and height 4.022. The function was Photoshop's resizing... Image, Image Size with auto resampling. Wasn't sure what the DPI on the new image was, so I entered 450 dpi and that resulted in a fairly close size to what I was looking for, but the result was where the blurriness came in. Even after using the Object Properties in Frame to tweak the size (I used the scaling percentage for that), it didn't seem to help with the quality at all. When I allow Frame to do all of the re-sizing... avoiding Photoshop all together, the same image is fine. So, it would seem there is something going on with how Photoshop is altering the graphic that presents an issue when you import that graphic into Frame, but is not an issue for the other software.

Janet

[Seanb_us]

Hi,

The new workflow you have isn't the best. So, when you have a chance, I recommend you reread a few of my posts (I did ask about pixel info.), especially the first one. I recommend you hook up with someone who has done image resizing and also translation before, so you can adopt some proven workflow.

All the best,

Sean

[gary.knighting]

I definitely will! The workflow still has a lot of kinks, so am trying to resolve them all as I re-familiarize myself with Frame after 15 years! The translation workflow is something we are still in the very early planning stages with, so thank you! I'm glad I posed the question before things get rolling because it is not something I have had to worry about before! Thanks so much for all your help. You were all so very helpful!

Janet

[Arnis_Gubins]

Janet,

You're little resizing operation went from an image size of about 8 million pixels down to a size of 0.1 million pixels (throwing away about 99% of your data). This didn't give FM much to work with, so no wonder you were seeing a blurry image.

Using your original image, in order to get a size of 5.3625" wide, you just divide the width of the image in pixels by the physical width desired to get the dpi needed for the scaling, e.g. 3264 (pixels) / 5.3625 (inches) = 608.67. So for your case, specifying 600dpi in FM would have given you the size that you wanted (for the best quality image) using the original jpg.