Hal V. Engel wrote:
I would like to get back to the original question that started this
thread. What CM workflows are currently being used in Linux? What
tools are used and where? How are they integrated to bring automation
to the workflow?
I'm doing colour on Linux with a mix of LCMS and m
On Thu, 27 May 2004, Hal V. Engel wrote:
I would like to get back to the original question that started this
thread. What CM workflows are currently being used in Linux? What
tools are used and where? How are they integrated to bring automation
to the workflow?
I do know that GraphicsMagick/Imag
I would like to get back to the original question that started this
thread. What CM workflows are currently being used in Linux? What
tools are used and where? How are they integrated to bring automation
to the workflow?
It seems when I asked this question initially most of the replies
ba
John Hee Soo Lee wrote:
> sony artisan monitors have unsupported calibration software for linux.
> I believe 7.1 and 7.3 redhat will work.
> unfortunately they have stopped developing for linux and their entire
> consumer (non-broadcasting) CRT monitors will be phased out by LED
> backlit LCD monit
Am 24.05.04, 10:32 - schrieb [EMAIL PROTECTED]:
>
>
> Gerhard Fuernkranz <[EMAIL PROTECTED]> said:
>
> > Karl Heinz Kremer schrieb:
> >
> > > ... and using LCMS in Gimp's display layer was too slow.
> >
> > Yes, LCMS unfortunately is a bit slow (sorry to say that, Marti) :-(
>
> No offence, it
sony artisan monitors have unsupported calibration software for linux.
I believe 7.1 and 7.3 redhat will work.
unfortunately they have stopped developing for linux and their entire
consumer (non-broadcasting) CRT monitors will be phased out by LED
backlit LCD monitors in the near future.
Anothe
Am 26.05.04, 18:11 +0200 schrieb Gerhard Fuernkranz:
> I guess it's a very similar situation as with Windows GDI printers. The
> manufacturers attempt to make the instrument as dumb as possible and to do
> the more complicated computations in software on the host, since this makes
> the devices ch
On Wed, 26 May 2004, Kai-Uwe Behrmann wrote:
Ok so Your can manage muliple hosts. Just we want to see the display not
the computer. I expect is is hard to circumvent X. Displays need names or
identifiers to assign profiles. Think about one big display
consisting of mulitple displays - all individua
Am 24.05.04, 19:23 -0500 schrieb Bob Friesenhahn:
> As I mentioned before, GraphicsMagick is planning to add rules-based
> automated color management support. We plan to configure color
> management via an XML file. There is no reason why the same XML
> configuration file format can't be used by
> It seems even gcc3.2 and 3.3 must not be ABI compatible.
Oh really, and I was hoping, that starting with gcc3, C++ would be ABI
compatible (of course only as long as the API remains the same) :-(
> Hard, to call this freedom of choice ;) Shurely the most relyable way
> >from user side is to g
Am 26.05.04, 00:23 +0200 schrieb Gerhard Fuernkranz:
> For instance, Avantes (http://www.avantes.com) provides a Linux SDK for
> their Spectrocam. Basically it appears to work, but IMO it's nasty that
> even the low level API library (distrubuted as binary) is compiled with
> g++, although it appe
On Mon, 24 May 2004 22:35:10 +0200
Gerhard Fuernkranz <[EMAIL PROTECTED]> wrote:
> Hi Marti,
>
> since you made me curious, I did now a brief test on an
> AMD XP 2600+:
>
> - LCMS compiled with "make CFLAGS=-O6"
*snip*
Are you using gcc to compile this? If you are... there is no such
flag as -O6
David Bevan schrieb:
Is there the same performance difference between lcms and Argyll cms
with an RGB_8 -> CMYK_8 conversion?
Yes, I get a similar difference: 11.7 (IMDI) vs. 2.1 (LCMS)
(sRGB -> EuroscaleCoataed)
Here are my Argyll IMDI numbers for several combinations of input
dimensions (id), o
Kai-Uwe Behrmann schrieb:
Am 24.05.04, 10:58 -0700 schrieb Troy Wu:
Unfortunately, being able to measure output values only solves half the
problem. For a full color-correction workflow, I need to be able to
soft-proof, which requires that my monitor is profiled and calibrated.
To do so requires a
On Tuesday 25 May 2004 11:27, John Cupitt wrote:
snip
> An alternative is to buy a display with a built-in colour calibrator.
I know Barco sell a few of these, there are probably others. Not very
cheap though :-(
>
> http://www.barco.com/prepress/en/products/product.asp?gennr=1215
>
> They h
On Tue, 25 May 2004, Marti Maria wrote:
I guess the best move would be to optimize the algorithm whatever
possible, which is proven to be the best optimization at all, and then
make things easy for the compiler, but without going too deep. Just
an example, 8-bit transforms are using lookup tables,
On Tuesday 25 May 2004 02:28, Kai-Uwe Behrmann wrote:
> Am 24.05.04, 10:58 -0700 schrieb Troy Wu:
>
> > Unfortunately, being able to measure output values only solves half
the
> > problem. For a full color-correction workflow, I need to be able
to
> > soft-proof, which requires that my monitor
Friesenhahn" <[EMAIL PROTECTED]>
To: "Marti Maria" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, May 25, 2004 5:21 PM
Subject: Re: [Lcms-user] ICC workflow in Linux
On Tue, 25 May 2004, Marti Maria wrote:
>
> In recent versions, I'm try
On Tue, 25 May 2004, Marti Maria wrote:
In recent versions, I'm trying to reduce the amount of asm to minimum.
Don't even discard eliminating it completely, since the speed gain is
almost null and definitively not worth of the induced complexity. Most times
you can do same in C, the trick is, writ
Troy Wu wrote:
I believe the lack of measurement hardware support (i.e., not
video cards) is the biggest deterrent to Linux-based color
management and image proofing.
I got around this by telling Minolta I was interested in buying a TV analyser (not
something I can really a
Am 24.05.04, 10:58 -0700 schrieb Troy Wu:
> Unfortunately, being able to measure output values only solves half the
> problem. For a full color-correction workflow, I need to be able to
> soft-proof, which requires that my monitor is profiled and calibrated.
> To do so requires a colorimeter--or
Gerhard Fuernkranz wrote:
Gerhard Fuernkranz schrieb:
For the AMD XP 2600+ the right numbers are
lcms 1.12: circa 1.2 Mpixel/s
lcms 1.13: circa 2.8 Mpixel/s
But as you said, unfortunately still (much) slower than Argyll
(by a factor of approx. 30).
So it's only a factor of approximately 5 :
Hi,
>(Btw, it looks like Marti has also coded some stuff in assembly
>language, but appearently for Windows only. So I'm also wondering how
>much LCMS runs faster on Windows than on Linux)
Almost nothing. That comes from an early version of lcms, which was
windows only. These routines does ver
I would like to add that one goal of an ICC workflow is to visually match
the endpoints; i.e., the images presented by display and output devices.
As someone has already duly noticed, simply having files tagged with ICC
profiles--while important--misses the mark of "color management," which is
t
On Tue, 25 May 2004, Gerhard Fuernkranz wrote:
Photoshop's CMS implementation has no need for a general purpose
data-marshaller like LCMS provides.
I understand what you mean, but I'm not sure if the overhead is really that
big.
Everything is relative. The faster/tighter computations become, th
Bob Friesenhahn schrieb:
Argyll is GPL, which prevents its use for some situations. I am a bit
concerned that it seems that Argyll is "experimental" software so
releases may not occur very often.
I agree.
The reason why I think so is that since Photoshop's CMS is designed
specifically for use i
On Tue, 25 May 2004, Gerhard Fuernkranz wrote:
Bob Friesenhahn schrieb:
I am not familiar with Argyll's architecture (is there even an API?), but
clearly a general-purpose solution like LCMS will be substantially slower
than an implementation which is directly optimized for a single usage.
it's b
Bob Friesenhahn schrieb:
I am not familiar with Argyll's architecture (is there even an API?),
but clearly a general-purpose solution like LCMS will be substantially
slower than an implementation which is directly optimized for a single
usage.
Bob,
it's basically a general purpose solution as we
As I mentioned before, GraphicsMagick is planning to add rules-based
automated color management support. We plan to configure color
management via an XML file. There is no reason why the same XML
configuration file format can't be used by other open-source
applications (e.g. GIMP) and accesse
Gerhard Fuernkranz schrieb:
For the AMD XP 2600+ the right numbers are
lcms 1.12: circa 1.2 Mpixel/s
lcms 1.13: circa 2.8 Mpixel/s
But as you said, unfortunately still (much) slower than Argyll
(by a factor of approx. 30).
So it's only a factor of approximately 5 :-)
I've tried the same again
On Mon, 24 May 2004, Gerhard Fuernkranz wrote:
For the AMD XP 2600+ the right numbers are
lcms 1.12: circa 1.2 Mpixel/s
lcms 1.13: circa 2.8 Mpixel/s
But as you said, unfortunately still (much) slower than Argyll
(by a factor of approx. 30).
So it's only a factor of approximately 5 :-)
Presumab
Gerhard Fuernkranz schrieb:
Result:
lcms 1.12: circa 165.000 pixel/s
lcms 1.13: circa 380.000 pixel/s
I have to apologize, I'm an idiot, I ran the program on the wrong
machine ...
For the AMD XP 2600+ the right numbers are
lcms 1.12: circa 1.2 Mpixel/s
lcms 1.13: circa 2.8 Mpixel/s
Bu
[EMAIL PROTECTED] schrieb:
Yes, LCMS unfortunately is a bit slow (sorry to say that, Marti) :-(
No offence, it *was* so slow :-) However, things have changed after that.
lcms still does not reach Argyll levels, but 1.13 incarnation is
faster that, say, Windows ICM.
It would be interesting to know
Gerhard Fuernkranz <[EMAIL PROTECTED]> said:
> Karl Heinz Kremer schrieb:
>
> > ... and using LCMS in Gimp's display layer was too slow.
>
> Yes, LCMS unfortunately is a bit slow (sorry to say that, Marti) :-(
No offence, it *was* so slow :-) However, things have changed after that.
lcms sti
On Sun, 23 May 2004, Karl Heinz Kremer wrote:
> Gerhard is correct, the CMS in X11 is not based on ICM profiles. You
> can find some information in the man page to xcmsdb. Sun did implement
> a CMS system based on ICM profiles (using a Kodak system) for Solaris.
> This proofs that it can be done,
Karl Heinz Kremer schrieb:
... and using LCMS in Gimp's display layer was too slow.
Yes, LCMS unfortunately is a bit slow (sorry to say that, Marti) :-(
However, with Argyll's (http://web.access.net.au/argyll/argyllcms.html)
IMDI (Integer Multi-Dimensional Interpolation) routines I could obtain a
Gerhard is correct, the CMS in X11 is not based on ICM profiles. You
can find some information in the man page to xcmsdb. Sun did implement
a CMS system based on ICM profiles (using a Kodak system) for Solaris.
This proofs that it can be done, it's just a matter of time and
know-how.
I looked
Hal V. Engel schrieb:
X11 seems to have support for ICM profiles. I stumbled across it
yesterday while researching this on the web and even looked at some of
the man pages for it on my SuSE 9.1 box. There are about 43 ICM
related X11 commands. I don't know if it works. And I am sure that
no
Bob,
You are right that the Windows model for ICM display support is in the
video card driver. I believe that this is a poor model since it
leaves it up to the video vendors to do a good job of implementing
this. Some of them will and others are likely not to. This can and
does lead to a n
On Sat, 22 May 2004, Hal V. Engel wrote:
> I have been seriously considering moving to Linux but find myself
> stymied by the primitive state of color management support. Both at
> the system level and in the image acquisition, editing and printing
> tools.
You have hit the nail on the head.
We
40 matches
Mail list logo
