[SATLUG] nnOT: Graphics knowledge / preparing (TIFF) images for publication

Lance Schneider schneider.lh at gmail.com
Tue Aug 30 02:08:15 CDT 2011


Desktop publishing was birthed using TIFF. It can handle all sorts of
compression algorithms but does not need to be compressed - affording many
flexible options for image data manipulation. That is why it is still the
preferred format for use in publishing applications. PNG should work fine
but the compression is a necessity instead of a luxury as with TIFF. The
publishing arena is chock full of the desire not to have to adopt additional
or new methods unless absolutely necessary and some (most?) see such
deviation as making the already time-crunched atmosphere of their work
unacceptably compacted by having to take additional steps to process data.
The amount of loss in PNG is not an issue generally - compared to the extra
compression accommodation instead of being able to work with a file format
that can contain other data types or be dissected on the fly.

Basically what you are up against is publisher preference. Not always a
place where contrast and equivalent sells the other party.Here's hoping they
accept the PNG images.

On Mon, Aug 29, 2011 at 11:33 PM, Alan Lesmerises
<alesmerises at satx.rr.com>wrote:

> On 8/29/2011 7:40 AM, Don Davis wrote:
>
>> In a way my question is at least tangentially Linux related. This list
>> seems brimming with people who know a lot.
>> Explanation at top - questions on bottom.
>>
>> I created a set of graphics using R. With some tweaking the images
>> looked as they should. They were generated as PNGs. Reading the
>> publishers specifications they specify no jpgs but rather TIFF. Fair
>> enough. I've sent an email asking the publisher if PNGs would be
>> acceptable (they are not receiving the images directly but as
>> incorporated in a .doc file.)
>>
>>
>> Questions:
>> 1. Are PNGs used in print publications? Would quality degradation be
>> apparent by simple graphs?
>>
>
> I can't speak for the publishers, but both are bit-map formats.  Aside from
> differences in how the information is encoded, PNG's are like the
> next-generation successor to GIF's.  As I understand it, PNG format was
> developed to circumvent licensing issues with GIF.  It's best suited for
> images with a limited number of colors, such as logos, graphs,
> non-photorealistic illustrations (i.e., not much if any color gradients,
> etc.) and the like.  Photos and other complex images don't work all that
> well in PNG format, at least in terms of file size.
>
> As for TIFF's, I've seen that format used most often like standard BMP
> bitmap format files.  As long as the image sizes (in pixels) remains the
> same, you should be able to make direct conversions form PNG to TIFF.
>
>
>  2. I used imagemagick:
>>  for i in *png; do convert $i -colorspace cmyk $(echo $i | sed -e
>> 's/.png/.tif/g'); done
>> to convert PNGs to TIFF files (with cmyk colorspace). When resized the
>> print becomes unreadable. Why? How might this be avoided?
>>
>
> Errors and loss of detail during image conversions usually crops up when
> either the source or the destination format (or both) uses a "lossy"
> compression method (like JPG), or when re-sizing images (especially true
> when using "lossy" compression).  As mentioned above, you should be able to
> convert from PNG to TIFF without problems as long as the image size stays
> the same and the color palette isn't reduced.  However, if in converting
> high color depth images _to_ PNG format the number of colors is reduced,
> image degradation can certainly occur.
>
>
>  Wondering - The graphs should be 300 or 600dpi. The approximate image
>> sizes for many are 1.87 x 2.89 inches. Should the images be generated as
>> 1122 x 1734. This does not seem to help when rescaled to smaller images.
>>
>
> I never got why people focus on DPI when you're looking at an image on a
> computer display.  DPI has no real meaning when you're looking at an image
> on the screen -- the image is so many pixels by so many pixels.  DPI only
> comes into play when you might actually _print_ the image on paper and you
> can then measure the output.  The same 800 x 600 pixel image can be printed
> at 100 DPI, 200 DPI, or 400 DPI; the difference is in the size of the output
> (8' x 6', 4' x 3', or 2' x 1.5') and the apparent quality of the image on
> the page (the smaller image will appear sharper due to the closeness of the
> pixels).  What you should focus on is generating the original image at the
> highest resolution possible (this is important for any kind of bitmap image
> since you can't re-scale them like vector graphics) and maintaining the same
> image size and color depth during the conversion.
>
>
>  3. R creates images in many formats. I used almost the identical command
>> - basically only changing tiff for png - to create tiff graphs. The
>> dimensions (though the same) aren't coming out right. (I don't know if
>> this is an R issue or something I don't understand about graphics.)
>>
>
> I haven't used R, so I can't address this question.  Sorry.
>
>
>  Thank you for your time,
>>
>> D Davis
>>
>
> I hope this helps.
>
> Al Lesmerises
>
> --
> ______________________________**_________________
> SATLUG mailing list
> SATLUG at satlug.org
> http://alamo.satlug.org/**mailman/listinfo/satlug<http://alamo.satlug.org/mailman/listinfo/satlug>to manage/unsubscribe
> Powered by Rackspace (www.rackspace.com)
>


More information about the SATLUG mailing list