Skip navigation
wandajp
wandajp Calculating status...
Currently Being Moderated

Image scaling changes

Jul 11, 2011 11:36 AM

Before I started here, the team was using FrameMaker 8 and migrating to FM 10. During the migration, we noticed that images in the documents we opened, converting them to FM10, had their image scaling data changed.

Typically, we acquire screen shots using the highest resolution screen supported - mine is currently set at 1440 x 900. We scale the images to a width of 510 pixels (optimally) but no more than 600 pixels in our screen capture utility. We save the screen shots as Grayscale JPEGs. This process has, historically, provided images that fit our text column flow perfectly.

In previous versions of FM, the images imported by reference appeared as 100% scaling in the FM image properties. Now, they appear as 75% scaling. We're wondering why and if there is any effects we need to be aware of in terms of PDF and HTML Help file sizes.

While testing the import process, looking to see if the FM scaling data affected the image size, we saw that the pixel dimensions given by SnagIt varied wildly from the pixel dimensions given by FM. For example, the SnagIt dimensions for one image indicated it was 505x493 pixels whereas FM gave the dimensions of the source file as 507x315 pixels. Both are, as far as I know, giving me the source file dimensions but they are different.

We might not have noticed this, the images looked okay, but we were carefully going through the transition to FM10 and looking at every detail.

 

Question: why is FM10 auto-scaling the images to 75%?

Question: does this scaling do anything to our output that we need to be aware of?

Question: why do we get two different dimension data from the two software packages?

 

Thanks,

Wanda

265 Views   7 Replies   Latest reply: mandrill22, Jul 13, 2011 11:00 AM
 
Replies
  • Art_Campbell
    Currently Being Moderated
    1. Art_Campbell,
    Jul 11, 2011 11:52 AM   in reply to wandajp
    Report

    There are a number of messages kind of related to migration between

    revs in the forum, but to summarize, I think it's usually a really

    good idea to MIF-wash (Save FM as MIF, reopen that and SaveAs .fm) any

    migrated documents to remove any artifacts from previous revs.

     

    I'm not sure it'd change/fix your files, but it may help some.

     

    (If you download the MIF2Go eval from omsys.com, they install a MIF

    washing utility that works on component files in books and stays on

    your system even if you don't buy the product.)

     

    Art Campbell

                  art.campbell@gmail.com

      "... In my opinion, there's nothing in this world beats a '52

    Vincent and a redheaded girl." -- Richard Thompson

                                                          No disclaimers apply.

                                                                   DoD 358

     

    I support www.TheGrotonLine.com, hyperlocal news for Groton MA.

     
    |
    Mark as:
  • Arnis Gubins
    Currently Being Moderated
    2. Arnis Gubins,
    Jul 11, 2011 6:37 PM   in reply to wandajp
    Report

    Wanda,

     

    For images, the %scaling value isn't what is intiailly used when importing. What is the dpi value that you specify when you import the image? That determines how FM "scales" the image, i.e. it assumes 72dpi is 100% and adjusts the image relative to that.

     

    Also, for screen captures, you really should be using a non-lossy format such as PNG (or even GIF) instead of JPG. I would check the JPG files produced in Snagit in an image editor or a viewing tool such as IrfanView (that provides detailed image info) as the disparity that you indicate (505x493 vs 507x493) is very large.

     
    |
    Mark as:
  • wandajp
    Currently Being Moderated
    3. wandajp,
    Jul 12, 2011 10:52 AM   in reply to Art_Campbell
    Report

    Thanks, I'll look into this for files we haven't pulled into FM 10 yet, see if the change continues.

    Thanks,

    Wanda

    sig-less for now

     
    |
    Mark as:
  • wandajp
    Currently Being Moderated
    4. wandajp,
    Jul 12, 2011 10:57 AM   in reply to Arnis Gubins
    Report

    I'll ask the group about the image format used.

    We import using 96 dpi. I think the team developed this process based on past experience. They didn't have this in FM 8, it just since they upgraded to FM 10 (which is where I join the team).

    I'll keep poking around, see what I can see. The 75% doesn't seem to be harming the image quality at all, in fact when one of the writers changes the scaling to 100% the images look wretched.

    This all may become moot, or critical, as we move towards single-sourcing and DITA.

    Thanks,

    Wanda

     
    |
    Mark as:
  • Art_Campbell
    Currently Being Moderated
    5. Art_Campbell,
    Jul 12, 2011 11:26 AM   in reply to wandajp
    Report

    It's unlikely to become moot. As Arnis pointed out, you're using a file format (jpg) that's ill-suited to screen shots because it's lossy. It intentionally throws away data every time the file is re-saved, so each time the image file changes, quality degrades. The process of maintaining the images is unlikely to change just because the wrapper around the images changes.

     

    Again, as Arnis pointed out, PNG would be a MUCH better choice because it's stable....

     
    |
    Mark as:
  • Error7103
    Currently Being Moderated
    6. Error7103,
    Jul 12, 2011 11:30 AM   in reply to wandajp
    Report

    We  save the screen shots as Grayscale JPEGs.

     

    Are the screen images contone (e.g. real-world photos, CGI imagery),

    or flat (e.g. dialogs, line art)? JPEG uses curve-matching compression,

    which is great for tones that vary smoothly, but introduces nasty ringing

    edge artifacts on sharp edges of flat tones.

     

    TIF(zip), uses repeat-count compression, and is both non-destructive to flat

    tone images, and often compresses them more efficiently. We use EPS

    for the import format (no compression) and let Distiller or Acrobat post

    determine the compression to use.


    This process has,  historically, provided images that fit our text column

    flow perfectly.In  previous versions of FM, ...

     

    What is the target delivery format?

     

    ... the images imported by reference appeared as  100% scaling in

    the FM image properties. Now, they appear as 75%  scaling.

     

    In case you want to try it, I have never seen imported EPS objects

    change size when migrating a document to a later rev of FM.

     

    We import using 96 dpi.

     

    If the target is PC screen display at 100% page size, that's probably a

    decent target. PC screen resolutions today probably range from 80 to

    110 dpi, and I'd guess that 96 is very close to the sweet spot.

     

    We use (and I favor) bringing in all contone content at 200 dpi or

    higher. We bring bitmap (bi-level line art) in at 600. But then our

    target media is 600 dpi B&W bitmap on paper. However, we like

    to give web readers of the PDFs reasonable detail in images.

    ______

    Apple's "Retina" crusade is trying to move the industry to 300 dpi

    displays. I'd be happy with 200.

     
    |
    Mark as:
  • mandrill22
    Currently Being Moderated
    7. mandrill22,
    Jul 13, 2011 11:00 AM   in reply to wandajp
    Report

    While the JPEG algorithm does a great job at compressing gradients (such as the ones you find in photographs and illustrations with wide tonal ranges), I will echo the comments made by others on this forum that it is not suitable for bi-level images, text, and line art (dialog boxes) as it will introduce artifacts and not provide as great a degree of compression either. IrfanView has a great batch conversion utility that will convert all your images to a more suitable format. (TIF or PNG.)

     

    There is another issue associated with the MIF-wash that has caused scaling problems for me. I do not get the scaling error you mentioned but if I have an anchored frame with an image inside it, the MIF conversion will sometimes rescale the anchored frame (Object Properties gives you the rounded off version of the "stored" dimensions you see in the MIF file (e.g. 2.828 displayed in the Object Properties window may actually be shown as 2.82899 in the MIF file).

     

    Through trial and error, I have think that "manually" resized frames (i.e making the anchored frames fit the edges of the body frames with Gravity turned on) may give you an anchored frame that fits perfectly at the edges in the FM file, but upon saving as MIF and opening the MIF file in FM I always find some anchored frames resized larger by a thousandth of an inch (so the previous example might become 2.829) which is enough to pop it out of its frame and into the next available body frame). Not sure if this is what is happening, but in my application this has always been an annoyance requiring resizing in the MIF file. Fortunately, all my dimensions are consistent and I can simply fix this through "Replace All".

     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points