Re: grayscale vs. color

[Martin Schultz <martin.schultz(at)dkrz.de>]

Hi Struan,

   yep! I guess that was shooting a little too fast, but the ensuing
discussion
(i.e. mostly your series of comments) put it onto the right track.
Although there may be workarounds (Liam), it still would be much
preferrable to see 24bit postscript colors produced by the postscript
driver. And I can't see a major difficulty in providing a (linearily
translated) CMYK output format in addition to RGB. True enough, RSI
should not start dealing with all these nitty details of color
adjustments etc., but I think one should be able to produce a postscript
file that you can forward to your favorite professional print shop and
they should be able to apply the necessary color corrections etc and get
the right colors out. What appals me about Photoshop, Coreldraw etc. is
that most of these are only available for Windows or Mac, so it is not
just firing up another application if you sit on a unix system. And the
learning curves are steep enough, although this is certainly also true
for color handling in general (why would there be professional graphic
studios otherwise?).

   I definitively agree with you that IDL seems to lag behind its
competitors in several fundamental ways, high ranking among these is
more transparent color handling and the mapping inconsistencies. From
what I have seen from the object graphics so far, this seems a much
better implementation - so perhaps they can at some point replace all
direct graphics stuff with procedure interfaces to the object graphics
routines? I am waiting for the IDLgrMAP object ...

   Yes: Let them do more important stuff!

Cheers,
Martin

Struan Gray wrote:
> 
> Martin Schultz, martin.schultz@dkrz.de writes:
> 
> > who says they must compete? If they can license
> > a bad editor, they should be able to license some
> > software to generate CMYK.
> 
>     They are competing in the sense that you're trying to make
> IDL do something that Adobe applications (among others) already
> do very well and at a cheaper price.  It is only worthwhile if
> you absolutly insist that your computer only ever runs one single
> program.
> 
>     As I pointed out, IDL already generates perfectly
> good-looking CYMK every time it uses a colour printer driver.  If
> I need more control than the printer driver allows me, any modern
> graphics or page layout program can turn out professional-quality
> seperations.  If I'm publishing a book or a thesis with colour
> plates the seperations are done by the printer and I just have to
> supply my monitor profile and check a proof or two.
> 
>     It would be helpful to make IDL able to use colour profiles
> and to warn about out-of-gamut colours, particularly when sharing
> visualisations with other users, but I don't want a half-assed
> implementation that I then have to second guess the whole time
> and I vastly prefer that IDL stick to its knitting and fix more
> serious problems.
> 
>     I'm not trying to be argumentative.  I'm genuinely baffled as
> to why you and David feel IDL has no CYMK abilities at all, and
> what exactly you feel should be added.  I'm interested to hear
> about specific problems you have had.
> 
> Struan

-- 
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[
[[ Dr. Martin Schultz   Max-Planck-Institut fuer Meteorologie    [[
[[                      Bundesstr. 55, 20146 Hamburg             [[
[[                      phone: +49 40 41173-308                  [[
[[                      fax:   +49 40 41173-298                  [[
[[ martin.schultz@dkrz.de                                        [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[