On Mon, Jun 21, 2010 at 7:18 PM, Ken Warner wrote:

Is it still being worked on?  If so, is there any word on availability?

"When it's ready" is the best you can get :)

Alexandre Prokoudine http://libregraphicsworld.org

On 06/21/2010 05:31 PM, Alexandre Prokoudine wrote:

On Mon, Jun 21, 2010 at 7:18 PM, Ken Warner wrote:

Is it still being worked on? If so, is there any word on availability?

"When it's ready" is the best you can get :)

There is more to say.

Right now the top priority is to get GIMP 2.8 released. The current goal is late 2010. GIMP 2.8 does not have support for high bit depths.

Once GIMP 2.8 is out, we will start phasing out the legacy 8-bit-per-channel code and replace it with GEGL. In other words, we will start for real to introduce support for high bit depths in GIMP. There is no schedule of this work, so a date cannot be given. It is reasonable though to expect this work to go on for say 2-4 years.

Regards, Martin

On Monday 21 June 2010 12:49:00 Martin Nordholts wrote:

On 06/21/2010 05:31 PM, Alexandre Prokoudine wrote:

On Mon, Jun 21, 2010 at 7:18 PM, Ken Warner wrote:

Is it still being worked on? If so, is there any word on availability?

"When it's ready" is the best you can get :)

There is more to say.

Right now the top priority is to get GIMP 2.8 released. The

current goal

is late 2010. GIMP 2.8 does not have support for high bit depths.

Once GIMP 2.8 is out, we will start phasing out the legacy 8-bit-per-channel code and replace it with GEGL. In other words,

we will

start for real to introduce support for high bit depths in GIMP.

There

is no schedule of this work, so a date cannot be given. It is

reasonable

though to expect this work to go on for say 2-4 years.

Regards, Martin

And what is the priority/schedule for CMYK?

On Mon, Jun 21, 2010 at 8:00 PM, John Culleton wrote:

And what is the priority/schedule for CMYK?

I think 2-4 years is more than enough for CMYK (hopefully).

Meanwhile, give separate+ a go. It gets the job done, and very reliable. Latest version supports clipping paths, and saving to CMYK TIFF, JPEG, and PSD. I'm not sure about reading those files back into Gimp, but I think it was mentioned somewhere it can be done. I've never needed to do it myself, though, so you're on your own.

I've given an overview of the color management in Gimp and part of it covers basic separate+ usage:

http://www.brankovukelic.com/post/513356271/gimp-color-management-for-dtp

On 06/21/2010 08:00 PM, John Culleton wrote:

And what is the priority/schedule for CMYK?

We know we need CMYK sooner or later, but higher bit depths and non-destructiveness is much more important. So first good support for the latter, then we can begin looking into proper support for the former IMO. Maybe in a stable version 6-8 years from now with the current pace of development.

/ Martin

On 6/21/10, Branko Vukelic wrote:

Meanwhile, give separate+ a go.

Or CMYKTool

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Jun 21, 2010 at 9:53 PM, Alexandre Prokoudine wrote:

On 6/21/10, Branko Vukelic wrote:

Meanwhile, give separate+ a go.

Or CMYKTool

Prokudine,

Veering a bit OT now, I've tried to use CMYKTool, and got an impression it was a bit redundant for separate+ users. Does it have anything to add (or do anything differently)?

On 6/22/10, Branko Vukelic wrote:

Meanwhile, give separate+ a go.

Or CMYKTool

Prokudine,

Vukelic? :)

Veering a bit OT now, I've tried to use CMYKTool, and got an impression it was a bit redundant for separate+ users. Does it have anything to add (or do anything differently)?

Well, if you *have* used CMYKTool, you couldn't possibly fail to notice the big thing called live soft proof or the small thing called displaying per-channel ink density value for the point under mouse pointer (right below the big thing) :-) Or how CMYKTool allows creating CMYK files in a color-unmanaged way, which is also desirable in some cases (implemented by a request, in fact).

I don't see how either of them make the other one redundant. Wise people use both, depending on what they are trying to achieve.

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Jun 21, 2010 at 10:12 PM, Alexandre Prokoudine wrote:

On 6/22/10, Branko Vukelic wrote:

Meanwhile, give separate+ a go.

Or CMYKTool

Prokudine,

Vukelic? :)

Sure.

I don't see how either of them make the other one redundant. Wise people use both, depending on what they are trying to achieve.

I will take your advice to heart, oh wise one! :)

On Monday 21 June 2010 14:11:58 Martin Nordholts wrote:

On 06/21/2010 08:00 PM, John Culleton wrote:

And what is the priority/schedule for CMYK?

We know we need CMYK sooner or later, but higher bit

depths and

non-destructiveness is much more important. So first

good support for

the latter, then we can begin looking into proper support

for the former

IMO. Maybe in a stable version 6-8 years from now with

the current pace

of development.

/ Martin

Hey, I may not live that long :

On Mon, Jul 12, 2010 at 5:02 PM, John Culleton wrote:

Hey, I may not live that long :

The debate on what ID lifted and what it didn't will never stop, eh?

There seems to be a recently growing trend to solve GIMP's bottlenecks by introducing external plug-ins that do some fancy stuff and run in 16bpc mode, e.g.:
http://www.mm-log.com/blog/2010-07-09/adaptive-saturation-curve-labcurves

You might like getting Mike to code quick patch-ups, no?

Of course, mating the goat and the wilber would be preferable.

Alexandre Prokoudine http://libregraphicsworld.org

/ Martin

Hey, I may not live that long :

Well, this January marks a chronological milestone for me, and, at this stage, six to eight years seems like something close to a life sentence for me. I guess I need to resign my open source editing sights for long-term (for me) 8-bit. I do like version 7.1 very much, though.

Keep up the good work.

Caruso