Photoshop EPS - JPG encoding
Hallvard Fagerland
JPG medium, the file will be decreased DRASTICALLY. Is there any reason you
shouldn't use this for "professional" use? Does anyone of you use it or do
you stay away from it?
Hallvard
Aandi Inston
>On Photoshop EPS, you have the encoding JPG option. If you use, let's say
>JPG medium, the file will be decreased DRASTICALLY. Is there any reason you
>shouldn't use this for "professional" use?
Two reasons.
1. JPEG is a "lossy" compression, so quality can be degraded. JPEG
format and JPEG compression of EPS or PDF files should therefore be
used with caution, with some experiment to confirm quality is
adequate. Some reject it out of hand, which at least saves having to
do any analysis.
2. JPEG-compressed EPS files cannot be colour separated by QuarkXPress
or similar programs (but can be separated once Distilled to PDF in the
usual way).
----------------------------------------
Aandi Inston qu...@dial.pipex.com http://www.quite.com
Please support usenet! Post replies and follow-ups, don't e-mail them.
Tacit
>JPG medium, the file will be decreased DRASTICALLY.
It will also decrease in quality.
JPEG gets such dramatic file size savings because it discards information from
the image. When you save with JPEG encoding, the quality of the image is
degraded; this can never be undone.
Furthermore, it's cumulative. If you need to make changes to the image, so you
open it and save it again, your image is degraded further. Open and save it
again,a nd your image is degraded still more. At every step along the way, you
damage the information in a manner that is irreversible.
In this day and age, storage space is cheap, cheap, cheap. There's little
reason for a pre-press or graphics professional to be so concerned about file
size that he is willing to accept inferior quality.
--
Literary forums; Onyx, a game of sexual exploration; Xero, the industrial
magazine of art, fiction and photography; fine-art photo gallery--all at
http://www.xeromag.com/franklin.html
Grafit
master file) and keep it at maximum quality/minimum compression, you will
still gain an average 1:10 compression with no visible loss of quality, and
the separations will ouput correctly from any app that supports DCS files
(at least with later Level2 RIPs).
If you use the Photoshop scenario where you keep the original layered images
in PSD format, this route is well recommended (though file folders might get
cluttered since each image contains 5 different files as opposed to a single
TIFF or EPS file plus additional confusion with file naming conventions).
Media is cheap these days, but it is not relevant if your single job file
doesn't fit on a single recordable CD.
Igor Draca
Studio Grafit
Split, Croatia
J. Costello
>Media is cheap these days, but it is not relevant if your single job file
>doesn't fit on a single recordable CD.
>
Wow, I cannot even conceive of a job that one file would not fit onto
one CDR.
Because...... I cannot imagine, one file, one graphic, or one page
from a layout application requiring more than 650 MB. And I say "one"
because if it were two graphics or two pages in a layout app, then
they could simply be put on separate disks.
Someone, anyone, tell me of a situation in which a job would contain
one (hugh) file that then would not fit onto one CDR.
J. Costello
Jono Moore
cost...@nac.net wrote on 10/23/01 11:08:
> Wow, I cannot even conceive of a job that one file would not fit onto
> one CDR.
You gotta get out more. ;)
> Someone, anyone, tell me of a situation in which a job would contain
> one (hugh) file that then would not fit onto one CDR.
We have one client who ftps us up to 10gigs a week in postscript files.
...Jono
Del Tree
<cost...@nac.net> wrote
>Someone, anyone, tell me of a situation in which a job would contain
>one (hugh) file that then would not fit onto one CDR.
Yeah... we had wun last year: 6 feet by 4 feet 144 dpi exhibition
poster.
Whilst the flattened EPS would (just) fit on a CD the bloody layered PSD
wouldn't. In the end we cheated and downsampled the PSD to something
like 105dpi and squeezed it on :-)
Eggspurts will know that with most graphics you can sample back up again
by this small amount without much problem - at least that's what we told
the client!
But this *IS* a rarity. I think it's the only image we've ever had that
wouldn't fit on a CD <G>
Best wishes,
--
Del Tree
Del Tree
<prep...@hillsideprinting.com> wrote
>We have one client who ftps us up to 10gigs a week in postscript files.
Well you can turn 'em into jpegs then, can't you and save 'em at
compression level 2!!! :-)
--
Del Tree
Tacit
>one (hugh) file that then would not fit onto one CDR.
I once did a job for a client who manufactured large-scale trade-show displays.
They wanted to show off a high-resolution, large-format printing device they
used, so they created a display that had four image panels, each 7 feet tall at
300 pixels per inch. Each image for the four panels weighed in at well over a
gigabyte.
The job was delivered on DLT tape, not on CD.
Grafit
For instance, I run a small but highly effective prepress studio. I have
limited equipment needs, because for all extras I have where to turn - most
of A4 or smaller scans I perform on my Powerlook II flatbed scanner, but
when needed, I go to scanning service and roll the slide(s) onto the Hell
drum scanner. When it comes to producing final film separations, I go to the
imagesetting bureau service, and I carry along ready-made postscript print
files. The same goes for final Cromalin proofs.
Let's say, for the sake of the arguments, that we're talking about A4 full
color (CMYK) photo-monography at some 150 pages, with 20 pages covered to
bleed with full sized CMYK photos, ranging (at 300 dpi) from 35-70 MB each.
If we were talking TIFFs here, that would easily mean 20x50 MB=1 GB of pure
bitmap data.
Or, we may talk about the 13-pages calendar at B2 size (that's 50x70cm).
Umm, let's see... at 300 dpi CMYK, each full bleed image weighs about 180
MB... times 13...
Now, I prefer to do the imposition myself - I like to have things under full
control. My degree didn't fall into my lap out of the blue sky - I worked
hard and learned hard. And I resent the idea that some semi-educated
under-paid prepress operator would ever get a chance to peek into my
publications, install my fonts and have my high-res scans stored on his hard
disk. I paid for those fonts, I paid for those slides. I don't want them
anywhere else but on my hard drive.
Yeah, I like to take charge and full responsibility for all the separation
issues, trapping settings, bleeds and trim marks. And I like to bring the
people at the imagesetting bureau ready-made PS files, so they cannot mess
anything up.
If I use TIFF images, that translates into huge print files, huge temporary
storage requirements, multiple CDR spanning, and splitting large imposed
printfiles into sections, in other words, a lot of time and resources wasted
just like that. Not to mention the creepy situation where imposition
software gets to handle half a gig of image data on crash-prone computers...
On the other hand, if I use separated DCS with JPEG compression, I get
compact printfiles at average 1/10 size or better in MB compared to TIFFs.
Screen redraw times in layout app are indefinitely faster. Zoom in, pan,
zoom out. Printfiles get printed in seconds, imposition gets done in seconds
(since images are pre-separated), and the whole procedure takes just under
an hour - from finished layout via printifles and imposition to burning CDR.
And it all happens on a weak Celeron 466 (256 MB RAM, 40GB HD).
It works flawlessly, keeps me ahead of my deadlines, saves me a lot of
post-production headaches. No gigahertzes and gigabytes of expensive
hardware can cut the production times as much as the clever workflow setup.
Yes, it takes a bit of expert-level knowledge, but, hell, isn't that degree
worth something?
Tacit
I find that part of your post very, very interesting.
Now, granted, buying a new computer every year shouldn't be necessary for a
home user, and shouldn't even be necessary for a business.
But if you make your living with your computer, why use an inferior tool? Yes,
you can use a Celeron 466 for professional prepress, but why? It's like a
mechanic who uses a pocketknife intead of a full toolkit to do his job.
A system roughly double in power to the one you describe can be had for about
$600. That seems to me to be a reasonable, rational, and justifiable expense
for a professional shop. Computers are cheap. Storage is cheap.
Sure, you can spend many thousands of dollars on a high-end system. But even a
cheap, commodity, low-end computer by today's standards still offers far more
power than the computer you describe.
If your computer is forcing your hand in your workflow pattern--if you must
adjust your working habits to accomodate an antiquated piece of hardware, far
inferior to a bottom-line modern machine--I submit that an upgrade is long
overdue. We're talking about less capital outlay than you'll make on a single
job!
Grafit
muscle of the machine.
I started using this method back in 1992/3, when the brand new
top-of-the-line pro machine was Mac PPC @ 120 MHz with 256 MB RAM. It
shipped with 2 GB hard drive. Business needs were far beyond the currently
available single disks, and SCSI RAID solutions were priced at 3-10 times
the price of the computer itself. CD recorder was Pinnacle 2x speed, and
blank CDR were sold at retail prices around $20-$30. I bought Iomega Jaz
instantly as it become available on the market, and used either Jaz or 2 GB
external hard drive to transfer print files to service bureau.
So, where does it put your comments in this story?
Yes, there will always be a faster processor and more RAM and larger disks.
But buying twice as fast processor doesn't mean that you will do your work
twice as fast. No, the speed gain with 2x faster megahertzes will translate
into hardly 20% faster overall operation. In order to really cut the
operation time down by half on the hardware side, you will need at least
4-6x faster hardware. We're not talking single pass of Photoshop filter
here, but the cumulative time from start to the finish of the whole job,
including numerous file copy procedures, reopening files, layout adjustments
etc. You don't type 10 times faster on 10x faster hardware. Neither do you
layout pages 10 times faster. Hardware speed relates to very few actual
steps while doing the job. Prepress life is not contained within a single
Photoshop filter pass or a single file save...
On the other hand, changing the method of work is capable of cutting the
production times in factors 10x, 20x or more.
I custom programmed a tool that helped solve one specific issue in preparing
the layout of the huge medical book (2500+ pages), cutting what used to be 3
months of work right into 30 minutes of waiting for a 'done' msgbox.
Deciding on doing the automated imposition (as opposed to the manual pasteup
at the printer's) in the pioneer age of imposition (early 90's) - actually
it was the first time imposition was ever used in my country - replaced some
600 pasteup working hours (of tedious manual labor) with an 8-hours
imposition procedure (of unattended automated operation).
I resort to this kind of tricks all the time.
Now tell me, which hardware can I buy out there to achieve such time
savings?
I replace hardware platform every 2-3 years, carefully weighing what to buy.
Yes, in a couple of weeks this Celeron will retire, and probably brand new
Athlon or Duron at 1 GHz will be ticking in its place. It will cost 2-3x
more, it will be 2-3 times as fast as the Celeron, but the job I do will be
20% faster done, if so.
The money you spend on MHz is far better spent on RAM or media or other
hardware or software or better yet - learning.
It's the brain that rules, not the muscle.
J. Costello
<prep...@hillsideprinting.com> wrote:
>in article 6rDVO0Tq2T+OiS...@4ax.com, J. Costello at
>cost...@nac.net wrote on 10/23/01 11:08:
>
>We have one client who ftps us up to 10gigs a week in postscript files.
>
>
>...Jono
Yeah, but I said ONE FILE, admittedly an entire job that includes a
lot of files can be hugh.
J. Costello
J. Costello
>>Someone, anyone, tell me of a situation in which a job would contain
>>one (hugh) file that then would not fit onto one CDR.
>
>I once did a job for a client who manufactured large-scale trade-show displays.
>They wanted to show off a high-resolution, large-format printing device they
>used, so they created a display that had four image panels, each 7 feet tall at
>300 pixels per inch. Each image for the four panels weighed in at well over a
>gigabyte.
>
>The job was delivered on DLT tape, not on CD.
Ok, now that example I can accept.
J. Costello
John Doherty
> Wow, I cannot even conceive of a job that one file would not fit onto
> one CDR.
Sure you can. Just imagine a big old stinking book with a few hundred
full-color scans in it.
> Someone, anyone, tell me of a situation in which a job would contain
> one (hugh) file that then would not fit onto one CDR.
Publisher: Academic Press
Author: Baltimore, David, et al., eds.
Title: Frontiers of Life, Vol. 4
ISBN: 0-12-077344-9
The book is 1,104 pages, four-color throughout. The uncompressed
PostScript files total about 7,151 MB. That's obviously not going
to fit on one CD.
A PDF of the book with zip compression for the images is about 1,670 MB.
That's not going to fit on one CD, either.
A PDF with maximum-quality JPEG compression is about 133 MB. That
you can fit on one CD.
So this job can be fit on one CD, but if and only if you use JPEG
compression.
--
Jono Moore
cost...@nac.net wrote on 10/24/01 8:34:
> Yeah, but I said ONE FILE, admittedly an entire job that includes a
> lot of files can be hugh.
That's easy - each file is up to a gig or so in size. ;)
...Jono
J. Costello
wrote:
>In article <6rDVO0Tq2T+OiS...@4ax.com>, J. Costello <cost...@nac.net> wrote:
>
>
>> Wow, I cannot even conceive of a job that one file would not fit onto
>> one CDR.
>
>Sure you can. Just imagine a big old stinking book with a few hundred
>full-color scans in it.
>
But, youeach chapter could be ONE PM file andlonger chapters could be
two or more PM files.
I guess what I meant was "show me ONE FILE that is more than 650 MB
and MUST BE only one file." The post above about the high res poster
for a meeting display was an example.
J. Costello
Badia Software
> 2. JPEG-compressed EPS files cannot be colour separated by QuarkXPress
> or similar programs (but can be separated once Distilled to PDF in the
> usual way).
Actually, you can print color separations of JPEG-compressed EPS from
DTP programs with no problems. I once worked for a company where
JPEG-compressed EPS was a standard image format. They usually saved it
as DCS but I don't remember if it was a requirement.
Best,
Leo Revzin
Badia Software
==
Coming soon: Badia BigPicture XT
The Complete Picture Management Suite for QuarkXPress
http://www.badiaxt.com
Scott Falkner
> They usually saved it
> as DCS but I don't remember if it was a requirement.
That works when printing separations, but then you can't print a colour
composite. IMO there's rarely a reason not to use TIFF.
Aandi Inston
>Aandi Inston wrote:
>
>> 2. JPEG-compressed EPS files cannot be colour separated by QuarkXPress
>> or similar programs (but can be separated once Distilled to PDF in the
>> usual way).
>
>Actually, you can print color separations of JPEG-compressed EPS from
>DTP programs with no problems. I once worked for a company where
>JPEG-compressed EPS was a standard image format. They usually saved it
>as DCS but I don't remember if it was a requirement.
DCS is not EPS. I haven't investigated what happens with DCS - really,
it's an obsolescent format because it doesn't work in composite
workflows.
Tacit
>it's an obsolescent format because it doesn't work in composite
>workflows.
DCS *IS* EPS. It's an extension to the EPS format; check the headers of a DCS
file some time.
DCS is not obsolescent. At the moment, it's the only raster format which
supports spot colors, for example.
--
"Quand la morale triomphe, il se passe des choses tres vilaines."
Literature. Art. Photography. Forums. Shareware. Kink. Sex.
All at: http://www.xeromag.com/franklin.html
Aandi Inston
>>DCS is not EPS. I haven't investigated what happens with DCS - really,
>>it's an obsolescent format because it doesn't work in composite
>>workflows.
>
>DCS *IS* EPS. It's an extension to the EPS format; check the headers of a DCS
>file some time.
No, it is not. It is a collection of files, either separate or
together, each of which is an EPS. Due to bad design decisions it
looks very like an EPS, but a program has to be written to handle DCS
separately from EPS. Furthermore, many bad user interface design
decisions make it appear that DCS is a "flavour" of EPS.
But neither the EPS nor DCS specifications would make that claim.
>
>DCS is not obsolescent. At the moment, it's the only raster format which
>supports spot colors, for example.
No EPS is perfectly capable of that. The irony is that Adobe don't
sell a product to make that kind of EPS.
Jono Moore
qu...@dial.pipex.com wrote on 10/31/01 0:26:
> DCS is not EPS. I haven't investigated what happens with DCS - really,
> it's an obsolescent format because it doesn't work in composite
> workflows.
It used to be obsolete. I hadn't seen a DCS file in years until the newer
versions of Photoshop came out.
It's making a comeback.
...Jono
Odysseus
>
> It used to be obsolete. I hadn't seen a DCS file in years until the newer
> versions of Photoshop came out.
>
> It's making a comeback.
>
only way I know of to save spot colours in a raster file, saving a great
deal of time lining up multiple greyscale images, suppressing all but
one to print each plate separately, &c. But even DCS1 lets me print
laser proofs of picture-heavy files in seconds instead of minutes, and
cuts the size of PS files going through our imposition program by a
factor of (nearly) four -- a big savings when one considers that pages
going through the imposition workstation do about three times as much
'network travelling' as do direct-output jobs.
--Odysseus
Scott Falkner
> many bad user interface design
> decisions make it appear that DCS is a "flavour" of EPS.
DCS "appear"s to be flavour of EPS, just as Peppermint appears to be a
flavour of gum.
DCS IS a type of EPS.
-It cannot be printed without a PS printer.
-It's file type is EPS.
-It contains PS code.
Scott Falkner
> many bad user interface design
> decisions make it appear that DCS is a "flavour" of EPS.
DCS "appear"s to be flavour of EPS, just as Peppermint appears to be a
flavour of gum.
DCS IS a type of EPS.
-It cannot be printed without a PS printer.
-It's file type is EPS.
-It contains PS code.
--
Scott Falkner
tel: 604.708.1900
e-mail: sfal...@vcn.bc.ca
web: http://www.vcn.bc.ca/~sfalkner
Aandi Inston
>Aandi Inston <qu...@dial.pipex.com> wrote:
>
>> many bad user interface design
>> decisions make it appear that DCS is a "flavour" of EPS.
>
>DCS "appear"s to be flavour of EPS, just as Peppermint appears to be a
>flavour of gum.
>
>DCS IS a type of EPS.
>-It cannot be printed without a PS printer.
>-It's file type is EPS.
>-It contains PS code.
Are you arguing from actual knowledge of the EPS and DCS
specifications, or just some (flawed) intuition based on the above
points?
You can find the DCS specification on
http://www.jahn.org/dcs/default.htm, the EPS specification is probably
not needed to see that DCS does not claim to be DCS, only to contain
EPS data.
As long as this damaging misinformation is repeated, people will keep
trying to use DCS in ways it does not work, was never intended to
work, and blame their tools for failing to do something that was not
supposed to happen.