Re: [Gimp-developer] lgm talk, part 2...

[peter sikking]

Chris Mohler wrote:

>>>  I would
>>> also manually "choke" the white plate - this means making the white
>>> areas a point or two smaller than the colored areas, thereby
>>> preventing the white from poking out at the edges of the colored
>>> areas.
>>
>> this looks like trapping to me. is there a difference?
>> trapping set-up for each plate would be in the projection set-up.
>
> A "choke" is a trap of negative amount.  This is probably just jargon
> -  I suspect that it should in fact be called a negative trap.
> Automatic trapping (and overprinting) has never lived up to my
> expectations - I would love to hear from anyone who has used
> auto-trapping software with acceptable results though.

would you call setting for each plate the amount (in points or  
micrometers,
etc) of choking or trapping to be automatic or manual?

>>>  Icing on the cake would be a mechanism to
>>> combine/subtract plates using the available blending modes.
>>
>> to generate plates from channels/layers that is needed, but
>> generating plates from plates? sounds like a creative kind
>> of workflow to me.
>
> I remember one specific instance:  printing two blue colors - one
> light, one medium - on very dark blue.  We originally placed the light
> blue color behind the medium blue color (overprint).  The client
> changed their mind,  and I needed to remove the overprint.  Merging
> the (inverted) contents of med blue into the contents of lt blue
> removed the overprint in one step.  I basically masked one plate with
> another and applied the mask.

and now it looks like a plate set-up change

>>>  During
>>> the process, it is fairly critical to have an ink density/opacity
>>> setting for each plate, to simulate (roughly) how the final print is
>>> going to look.  EG, set the white plate at approx 90%, the colors at
>>> approx 70% - and you can see which portions of the colors are  
>>> falling
>>> on the white underlay, and which portions are falling on the black
>>> shirt.
>>
>> hmmm, tricky that one. it is natural for the plate stack to work
>> sort-of like the layer stack. eye symbols to switch plates on/off.
>> then there is the opacity slider of the layer stack. coverage slider
>> for the plates? ay be does the dual purpose of previewing like you
>> need and absolute print balancing.
>
> Indeed - the stack of plates should function more or less like the
> layer stack.  Yes - I envision a visibility toggle for each layer, and
> also an opacity slider.  But here's another murky area  (as if we
> needed more ;) - if I set a plate's opacity to 50%, does 100% black on
> that plate print out at 50% or 100%?  I would expect 100% - but that's
> from past experience, and not very intuitive.  Perhaps you are right
> that we need both a opacity and coverage control - that makes more
> sense to me,  but I have never seen it implemented and may well prove
> confusing.

no it would have to be a slider with results, so it would really
scale the whole plate coverage. and similar to layer opacity today
you can use it in between to peek though a layer. that should be enough

>>> and to be able to add new layers that could
>>> later be applied to new or existing plates, but this could be worked
>>> around.
>>
>> add layers where, image side or press projection side?
>
> My guess is image-side.  One possible scenario:

OK, all clear there.

> 1. Design artwork in GIMP - RGB, 3 colors, 1 color per layer - 3
> layers (or maybe 4 with a bg color)
> 2. Create print projection, map layers to plates
> 3. Done, hit print/export - OR
> 4. Go back to RGB, duplicate two layers, merge them, apply curves, etc
> - whatever needs adjustment
> 5. Manually apply the contents of the new layer to one or more of the
> plates in the projection
> 6. Done, print/export
>
> I guess to summarize: in addition to the initial layer(or color?) ->
> plate mapping, it should be possible to re-apply contents of one or
> more RGB layer to the plates without re-mapping the entire projection
> (if that makes sense).

well, if you want some layers to do something special to some plates
you will have to map them. this does not mean re-doing your mapping,
just updating it a bit.

> Things like overprints and trapping can get very complicated, esp if
> the colors are not solid and/or you are mixing spot colors.  Often
> fine-tuning is required.  I would love to see automatic trapping
> (complicated!), but not without being able to manually tune the
> results


for instance using the (perpetual) upcoming iWarp tool on the plate
would a cool way to do thet, no?

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Graeme Gill]

peter sikking wrote:
> Chris Mohler wrote:

>>  I would
>> also manually "choke" the white plate - this means making the white
>> areas a point or two smaller than the colored areas, thereby
>> preventing the white from poking out at the edges of the colored
>> areas.
> 
> this looks like trapping to me. is there a difference?
> trapping set-up for each plate would be in the projection set-up.

Note that "trapping" has two meanings in the printing world.

One relates to the way the inks stick to what it's being printed
over :- ie. if one plate printed on paper achieves 100% trap (coverage),
then when it's printed on top of a previous plate it might
have 90% trap because it doesn't stick as well to ink as paper, etc.

The other relates to "choke and spread", used to create
plate alignment (registration) tolerance.

Graeme Gill.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Chris Mohler]

On Sun, Jun 21, 2009 at 11:22 AM, peter sikking wrote:


>> Imagine I'm designing a black t-shirt with say five spot colors,
>> including white.  After completing the artistic design, I enable the
>> 'projection screen'.  This theoretically would result in my five
>> "plates".  However, the white plate will need special attention.
>>
>> Here's my workflow for this in PS: I would use the (badly named)
>> 'Apply Image' command to take the contents of each color plate and
>> combine them into the white plate using the mode 'multiply'.
>
> this looks analogue to me to black generation in cmyk, but now
> inverted because we are on a black background. interesting concept,
> the media color (makes note). since it is going to work for black,
> it can be made to wok for any other color, with reversed logic also.

Yes, I think media color should be taken into account when designing
this system - even though I suspect the vast majority of media will be
white or very light.

>>  I would
>> also manually "choke" the white plate - this means making the white
>> areas a point or two smaller than the colored areas, thereby
>> preventing the white from poking out at the edges of the colored
>> areas.
>
> this looks like trapping to me. is there a difference?
> trapping set-up for each plate would be in the projection set-up.

A "choke" is a trap of negative amount.  This is probably just jargon
-  I suspect that it should in fact be called a negative trap.
Automatic trapping (and overprinting) has never lived up to my
expectations - I would love to hear from anyone who has used
auto-trapping software with acceptable results though.

>> Now, I am quite interested in learning new workflows - so I am not
>> bound to the "how" of the method above, but I hope I have explained
>> the "why" well enough.  In addition to being able to interact with
>> each plate as a grayscale drawable, it would be useful to create
>> temporary areas for doing work - be they layers, channels, plates,
>> whatever - on which to create paths, selections, etc to in turn use to
>> modify the plates manually.
>
> everything of that will work on plates like working on layers today.
> I am sure that global concepts like paths and selection will be
> applicable to layers and plates without limits. a selection created
> on a layer and applied to a plate: sure.

OK - thanks for clarifying.

>>  Icing on the cake would be a mechanism to
>> combine/subtract plates using the available blending modes.
>
> to generate plates from channels/layers that is needed, but
> generating plates from plates? sounds like a creative kind
> of workflow to me.

I remember one specific instance:  printing two blue colors - one
light, one medium - on very dark blue.  We originally placed the light
blue color behind the medium blue color (overprint).  The client
changed their mind,  and I needed to remove the overprint.  Merging
the (inverted) contents of med blue into the contents of lt blue
removed the overprint in one step.  I basically masked one plate with
another and applied the mask.

While I doubt that function is necessary, it would certainly be very
useful on occasion.

>>  During
>> the process, it is fairly critical to have an ink density/opacity
>> setting for each plate, to simulate (roughly) how the final print is
>> going to look.  EG, set the white plate at approx 90%, the colors at
>> approx 70% - and you can see which portions of the colors are falling
>> on the white underlay, and which portions are falling on the black
>> shirt.
>
> hmmm, tricky that one. it is natural for the plate stack to work
> sort-of like the layer stack. eye symbols to switch plates on/off.
> then there is the opacity slider of the layer stack. coverage slider
> for the plates? ay be does the dual purpose of previewing like you
> need and absolute print balancing.

Indeed - the stack of plates should function more or less like the
layer stack.  Yes - I envision a visibility toggle for each layer, and
also an opacity slider.  But here's another murky area  (as if we
needed more ;) - if I set a plate's opacity to 50%, does 100% black on
that plate print out at 50% or 100%?  I would expect 100% - but that's
from past experience, and not very intuitive.  Perhaps you are right
that we need both a opacity and coverage control - that makes more
sense to me,  but I have never seen it implemented and may well prove
confusing.


>> After re-reading the notes on the talk, if we have a Layer->Plate
>> mapping, I think that will cover most situations.  I would prefer a
>> way to "mix" the plates,
>
> "mixing" channels + layers -> plates is a starting point for the
> development of the design of the plate set-up.

OK - thanks.

>> and to be able to add new layers that could
>> later be applied to new or existing plates, but this could be worked
>> around.
>
> add layers where, image side or press projection side?

My guess is image-side.  One possible scenario:

1. Design artwork in GIMP - RGB, 3 colo

Re: [Gimp-developer] lgm talk, part 2...

[peter sikking]

last one:

(peter) yahvuu wrote:

>>> there's one thing i don't understand, may be a misconception:
>>> why is it necessary to have separate modes for editing the RGB data
>>> and the plates?
>>
>> mainly because creating art on a RGB monitor, to be used on
>> many media, is not the same _activity_ as bringing this art to
>> _one_ particular printing press.
>>
>> also, it is better when the art itself is separated from the  
>> adaptation of
>> it for one press run.
>
> ah, that helps. So it is deprecated to create single-ink 'light blue  
> text'
> directly on  the 'light blue' plate, as the text would then not be  
> known to
> be part of the artwork.

yes, but then I would not stop anybody from doing that. sometimes it  
will
be necessary like applying a ghost image in matte varnish on top
of a glossy full color image: it may be most efficient to do the
matte varnish plate from scratch by itself...

> Can you give an outline how the print color for that text will be  
> specified?

specify a color (pantone, RAL, etc.) for the plate.

> The RGB color isn't useful here and the text layer can't be accessed  
> while
> the press projection is pulled over, IIUC. So each artwork layer  
> will have
> a custom color separation setting resp. color mapping?

no the other way around, each plate gets "mixed" from channels + layers.
I know this is not simple nor solved at the moment. since the plate
is a momochrome drawable, we need to look at the text layer and  
determine
per pixel "how much is there", where 'how much' can be a choice or
combination of the (inverse of) value/lightness/alpha/layer opacity,
and perhaps more.

>>> Is it correct that there's no 'live preview' of the effects that RGB
>>> manipulations have on the plates?
>>
>> if that is really needed by some users (see the two activities above
>> and also "no substitute for experience") then a second view of the
>> file (View->New view) can be run with the projection pulled down.
>> might be hard on the processor.
>
> Regarding the use-case of matching one color from a photo with a
> predetermined ink combination, i think this will be useful.


reading this again I am getting confused what you really mean here.

> yep, that's the desired effect here. For the single-ink text  
> example, a bit more
> than filling the light blue plate to 100% is required, though, as  
> the other
> plates have to be set to 0% for that area.

yeah, I realised that. must be part of the set-up to do that.

> My question is how and where such a layer->plate mapping will be  
> specified,
> for example when i want my text to be (0, 0, 50%, 50% ,0) on the  
> five plates.

well, plates 3 and 4 need to be set up (in the projection set-up) to  
take

0.5 * "the (inverse of) value/lightness/alpha/layer opacity"

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[peter sikking]

more gluing:

Chris Mohler wrote:

>> I am curious why you want to do something like that, because you
>> are then going against the grain of the whole plan: freedom to  
>> develop
>> the artistic concept further without (much) rework on the plates.
>
> Imagine I'm designing a black t-shirt with say five spot colors,
> including white.  After completing the artistic design, I enable the
> 'projection screen'.  This theoretically would result in my five
> "plates".  However, the white plate will need special attention.
>
> Here's my workflow for this in PS: I would use the (badly named)
> 'Apply Image' command to take the contents of each color plate and
> combine them into the white plate using the mode 'multiply'.

this looks analogue to me to black generation in cmyk, but now
inverted because we are on a black background. interesting concept,
the media color (makes note). since it is going to work for black,
it can be made to wok for any other color, with reversed logic also.

>  I would
> also manually "choke" the white plate - this means making the white
> areas a point or two smaller than the colored areas, thereby
> preventing the white from poking out at the edges of the colored
> areas.

this looks like trapping to me. is there a difference?
trapping set-up for each plate would be in the projection set-up.

> Now, I am quite interested in learning new workflows - so I am not
> bound to the "how" of the method above, but I hope I have explained
> the "why" well enough.  In addition to being able to interact with
> each plate as a grayscale drawable, it would be useful to create
> temporary areas for doing work - be they layers, channels, plates,
> whatever - on which to create paths, selections, etc to in turn use to
> modify the plates manually.

everything of that will work on plates like working on layers today.
I am sure that global concepts like paths and selection will be
applicable to layers and plates without limits. a selection created
on a layer and applied to a plate: sure.

>  Icing on the cake would be a mechanism to
> combine/subtract plates using the available blending modes.

to generate plates from channels/layers that is needed, but
generating plates from plates? sounds like a creative kind
of workflow to me.

>  During
> the process, it is fairly critical to have an ink density/opacity
> setting for each plate, to simulate (roughly) how the final print is
> going to look.  EG, set the white plate at approx 90%, the colors at
> approx 70% - and you can see which portions of the colors are falling
> on the white underlay, and which portions are falling on the black
> shirt.

hmmm, tricky that one. it is natural for the plate stack to work
sort-of like the layer stack. eye symbols to switch plates on/off.
then there is the opacity slider of the layer stack. coverage slider
for the plates? ay be does the dual purpose of previewing like you
need and absolute print balancing.

> After re-reading the notes on the talk, if we have a Layer->Plate
> mapping, I think that will cover most situations.  I would prefer a
> way to "mix" the plates,

"mixing" channels + layers -> plates is a starting point for the
development of the design of the plate set-up.

> and to be able to add new layers that could
> later be applied to new or existing plates, but this could be worked
> around.

add layers where, image side or press projection side?

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2

[Andrew A. Gill]

On Sun, 21 Jun 2009, peter sikking wrote:
>
> OK, I see that I was not clear enough in my blog:
>
> "When further fine?tuning for the printing press is the goal,
>  then the solution is to shove the CMYK file straight into a
>  press projection, as a static, pre-defined separation. Each
>  plate is then still fully editable as outlined before."
>
> what i tried to say is that users will have a choice to _not_
> convert a CMYK file to RGB, but to load it straight into a
> press projection. the resulting file will have an empty RGB part,
> and a static base separation that comes straight from the file.
> I fully intent here that GIMP will be able to set up the press
> projection from the file, including the number of plates, their
> colors used and their order. maybe users will have to help with
> saying that spot plate #2 uses pantone 1234 (say).
>
> so now we have the CMYK file as lossless as it gets in to GIMP,
> every plate can be touched up, or a block of text added..., or
> all plates together get a curves applied for more oomph, or...
>
> the result can be saved again to a separation file.

OK.  I think you addressed my concern.

-- 
| Andrew A. Gill To ensure continued quality of service,   |
|this e-mail is being monitored by the NSA |
|   |
   --
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2

[peter sikking]

I am gluing some posts together:

Guillermo Espertino wrote:

>> It seems to me you completely misunderstood the whole thing. What  
>> makes
>> you think there is any CMYK -> RGB conversion involved here?
>
> I think he's talking about the procedure to perform when the source  
> file
> is CMYK. The proposal is to convert it to RGB (in the "what about CMYK
> files" section of the Peter's document).
...
> What if I want to touch up an image that a client sent me, already
> separated?


OK, I see that I was not clear enough in my blog:

"When further fine‐tuning for the printing press is the goal,
  then the solution is to shove the CMYK file straight into a
  press projection, as a static, pre-defined separation. Each
  plate is then still fully editable as outlined before."

what i tried to say is that users will have a choice to _not_
convert a CMYK file to RGB, but to load it straight into a
press projection. the resulting file will have an empty RGB part,
and a static base separation that comes straight from the file.
I fully intent here that GIMP will be able to set up the press
projection from the file, including the number of plates, their
colors used and their order. maybe users will have to help with
saying that spot plate #2 uses pantone 1234 (say).

so now we have the CMYK file as lossless as it gets in to GIMP,
every plate can be touched up, or a block of text added..., or
all plates together get a curves applied for more oomph, or...

the result can be saved again to a separation file.

Hal V. Engel wrote:

>>> When a received CMYK file is to be used in new creative work, we  
>>> already
>>> saw that ‘it needs to be imported and converted to RGB.’
>
> And I am not sure that this is the correct approach.  Why would this  
> be
> needed?  Is this so that we can deal with GIMPs limited  
> functionality to
> handle anything beyond RGB color spaces?  If so then the focus  
> should be on
> supporting other color spaces directly.

I forgot to write in my blog that besides

"When a received CMYK file is to be used in new creative work,
  we already saw that ‘it needs to be imported and converted to  
RGB.’"

I see the whole process like taking a scanned image or an image from
a digital camera and include it in new creative work. similar to
those situations the MYK file import will need to be tuned up for
color balance and contrast before adding it to the creative work.

> I also have not any anything in the thread related to how color  
> management
> fits.   After all how do you create the printer specific separations  
> from an
> RGB (or other non-device specific) image into the correct device  
> values
> without involving the color management engine?

I did include that:

"Note also that the colors in the press projection are already
  slightly different than that of the normal view, because the
  color profile of the printing press is taken into account."

I am aware that color profiling is a very serious thing in
the world of printing presses.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2

[Andrew A. Gill]

On Sat, 20 Jun 2009, Martin Nordholts wrote:
>
> To me it sounded as if he thought there would be constant lossy RGB ->
> CMYK -> RGB conversions when you do adjustments after having pulled down
> the CMYK projection, but the adjustment you do with the CMYK projection
> is already is in the CMYK space, they just get reapplied all the time
> (this is where the non-destructiveness comes in). The edits you do in
> RGB is a one way transform only to CMYK, so there is no destructive RGB
> -> CMYK -> RGB -> CMYK -> RGB -> CMYK involved here either.

Conversion from RGB to CMYK with any sort of color management is 
inherently lossy.  RGB is a ginormous gamut, capable of 
expressing 16.8 million colors at 8 bits per channel. 
Theoretically, CMYK should be able to express 4 Gi-colors, but in 
practice, it is only able to express a fraction of them.

Many CMYK colors (I'm thinking rich blacks, but there may be 
others) are identical to the human eye, and only become important 
when you are looking at what colors are next to them.

I'm presently working with an imagesetter that outputs at 2540 
dpi.  Assuming that I use a linescreen of 127 lpi (150 lpi is a 
pretty common low-resolution setting), and assuming that I use 
symmetrical halftone dots, and figuring in an ink limit of around 
250% (normal for plain paper) I'm lucky to get 50 shades of gray 
per color--giving me around 6 million colors total.

I don't know enough about CMS to know if it would work to have a 
fake gamut for CMYK that would simply transform RGB losslessly.

What I do know is that if you intend to transfer any changes you 
make in the press projection back to the RGB image, loss will 
occur in those rich blacks.  I don't know if he's still 
advocating that, but he seemed to be at one point.

-- 
| Andrew A. Gill To ensure continued quality of service,   |
|this e-mail is being monitored by the NSA |
|   |
   --
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Hal V. Engel]

On Saturday 20 June 2009 09:40:22 am Daniel Hornung wrote:
> Hello Martin!
>
> On Saturday 20 June 2009, Martin Nordholts wrote:
> > It seems to me you completely misunderstood the whole thing. What makes
> > you think there is any CMYK -> RGB conversion involved here?
> >
> >  / Martin
>
> I think Andrew referred to this part from Peter's article:
> > what about CMYK files?
> >
> > When a received CMYK file is to be used in new creative work, we already
> > saw that ‘it needs to be imported and converted to RGB.’

And I am not sure that this is the correct approach.  Why would this be 
needed?  Is this so that we can deal with GIMPs limited functionality to 
handle anything beyond RGB color spaces?  If so then the focus should be on 
supporting other color spaces directly.  

I also have not any anything in the thread related to how color management 
fits.   After all how do you create the printer specific separations from an 
RGB (or other non-device specific) image into the correct device values 
without involving the color management engine?

Hal
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Chris Mohler]

On Sat, Jun 20, 2009 at 12:07 PM, yahvuu wrote:
> hi,
>
> Chris Mohler schrieb:
>> On Sat, Jun 20, 2009 at 11:27 AM, yahvuu wrote:
>>> i assume the temporary layers are mostly grayscale?
>>
>> Usually RGB layers, or grayscale channels.
>
> sorry, imprecise question. I mean, if you use a temporary RGB layer,
> it's content will still usually be just grayscale, effectively used
> as a mask. Assumed correctly?

Not necessarily - consider another scenario: mixing two spot colors to
create a third color.  More accurately, consider an image (RGB) that
is primarily three colors, and then attempting to print that image in
two colors, getting as close to the original RGB artwork as possible
(the number of spot colors is a major factor in printing cost).

In that scenario, I may end up duplicating the original RGB artwork
several times before getting the selection that I want - then
ultimately filling or erasing that selection on the spot channel(s).
The process can be very non-intuitive at times, and sometimes you just
have to dive in and do some trial and error - esp. if the original RGB
image is something flat that was not originally intended to be printed
in such a way or is "damaged" (eg, not on layers, suffers from JPEG
compression, etc.).

Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[yahvuu]

hi,

Chris Mohler schrieb:
> On Sat, Jun 20, 2009 at 11:27 AM, yahvuu wrote:
>> i assume the temporary layers are mostly grayscale?
> 
> Usually RGB layers, or grayscale channels.

sorry, imprecise question. I mean, if you use a temporary RGB layer,
it's content will still usually be just grayscale, effectively used
as a mask. Assumed correctly?


greetings,
peter

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Chris Mohler]

On Sat, Jun 20, 2009 at 11:27 AM, yahvuu wrote:
> hi,
>
> Chris Mohler schrieb:
>> Imagine I'm designing a black t-shirt with say five spot colors,
>> including white.
> [..]
>> Whew ;)
>
> Whew, too ;) Makes me wonder if it has to be that hard or if
> it points to some missing software improvements. Trying to understand
> the example, i hope you don't mind some uninformed questions (and also
> some out-of-sequence quoting).
>
> Besides anticipating printing press idiosyncrasies ('choke'),
> it seems to me you're manually creating kind of a color separation.
> Quite naively: doesn't photoshop know you're printing on black?

Yes - I end up doing a lot of it manually, and no it does not know -
having a 'target' or 'base' would be a step forward.

>> Here's my workflow for this in PS: I would use the (badly named)
>> 'Apply Image' command to take the contents of each color plate and
>> combine them into the white plate using the mode 'multiply'.
>
> this is to create the white underpinning, resp. the beginning thereof.
> 'Apply Image' is short-hand for 'blend anything with anything',
> but doesn't do any tricks that could not be achieved with layer stacks
> in combination with proper channel masking. On track?

Yes.

>
>> I would
>> also manually "choke" the white plate - this means making the white
>> areas a point or two smaller than the colored areas, thereby
>> preventing the white from poking out at the edges of the colored
>> areas.  This process can get a bit tricky, especially if the original
>> artwork is very complex.
>
> if the artwork was fully vectorized, say a pure inkscape job,
> would that make things easier?

Of course, but when photographic-type artwork comes into play, it's
usually easier/faster to do the whole thing in a raster editor.

>
>> Often, create temporary layers (or plates),
>> perform selection/drawing functions, then combine the result back into
>> a plate in one of two ways - either making a selection on the temp
>> layer and going to the plate and filling or erasing, or using the
>> 'Apply Image' command to take the RGB channel of the current layer and
>> combine it with a plate using a mode such as Multiply, Screen, or Add.
>
> i assume the temporary layers are mostly grayscale?

Usually RGB layers, or grayscale channels.

> the temporary layers serve as 'mixing stage' because it takes
> several steps to create a desired mask, or is it more
> to keep selections/drawings for reuse?

A little of both.  Sometimes I just need a very complex selection, but
I need to do some work to create the selection.  Other times I need to
store a selection for later use  (that's generally when I make an
extra channel).


After re-reading the notes on the talk, if we have a Layer->Plate
mapping, I think that will cover most situations.  I would prefer a
way to "mix" the plates, and to be able to add new layers that could
later be applied to new or existing plates, but this could be worked
around.

Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[yahvuu]

hi,

Tobias Ellinghaus schrieb:
> Am Samstag, 20. Juni 2009 schrieb yahvuu:
> 
> [...]
> 
>> Can you give an outline how the print color for that text will be
>> specified? The RGB color isn't useful here and the text layer can't be
>> accessed while the press projection is pulled over, IIUC. So each artwork
>> layer will have a custom color separation setting resp. color mapping?
> 
> From Peter's blog post:
> 
> "However there will be full flexibility to map the content of any layer 
> directly to any plate. For instance that light blue text in our example: it 
> can be directly mapped from its text layer to the light blue plate, bypassing 
> the composite."
> 
> 
> I understand that you can use layers as plates.

yep, that's the desired effect here. For the single-ink text example, a bit more
than filling the light blue plate to 100% is required, though, as the other
plates have to be set to 0% for that area.

My question is how and where such a layer->plate mapping will be specified,
for example when i want my text to be (0, 0, 50%, 50% ,0) on the five plates.


greetings,
peter

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Daniel Hornung]

Sorry, I just saw that Guillermo cleared up that misunderstanding already. 
(Though it was not detected as part of the same thread by my mail client.)

Daniel


signature.asc
Description: This is a digitally signed message part.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Daniel Hornung]

Hello Martin!

On Saturday 20 June 2009, Martin Nordholts wrote:
> It seems to me you completely misunderstood the whole thing. What makes
> you think there is any CMYK -> RGB conversion involved here?
>
>  / Martin

I think Andrew referred to this part from Peter's article:
> what about CMYK files?
>
> When a received CMYK file is to be used in new creative work, we already
> saw that ‘it needs to be imported and converted to RGB.’

Daniel


signature.asc
Description: This is a digitally signed message part.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[yahvuu]

hi,

Chris Mohler schrieb:
> Imagine I'm designing a black t-shirt with say five spot colors,
> including white. 
[..]
> Whew ;)

Whew, too ;) Makes me wonder if it has to be that hard or if
it points to some missing software improvements. Trying to understand
the example, i hope you don't mind some uninformed questions (and also
some out-of-sequence quoting).

Besides anticipating printing press idiosyncrasies ('choke'),
it seems to me you're manually creating kind of a color separation.
Quite naively: doesn't photoshop know you're printing on black?


> Here's my workflow for this in PS: I would use the (badly named)
> 'Apply Image' command to take the contents of each color plate and
> combine them into the white plate using the mode 'multiply'.  

this is to create the white underpinning, resp. the beginning thereof.
'Apply Image' is short-hand for 'blend anything with anything',
but doesn't do any tricks that could not be achieved with layer stacks
in combination with proper channel masking. On track?


> I would
> also manually "choke" the white plate - this means making the white
> areas a point or two smaller than the colored areas, thereby
> preventing the white from poking out at the edges of the colored
> areas.  This process can get a bit tricky, especially if the original
> artwork is very complex. 

if the artwork was fully vectorized, say a pure inkscape job,
would that make things easier?


> Often, create temporary layers (or plates),
> perform selection/drawing functions, then combine the result back into
> a plate in one of two ways - either making a selection on the temp
> layer and going to the plate and filling or erasing, or using the
> 'Apply Image' command to take the RGB channel of the current layer and
> combine it with a plate using a mode such as Multiply, Screen, or Add.

i assume the temporary layers are mostly grayscale?

the temporary layers serve as 'mixing stage' because it takes
several steps to create a desired mask, or is it more
to keep selections/drawings for reuse?


thanks for your patience,
peter




___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2

[Martin Nordholts]

Guillermo Espertino wrote:
>> It seems to me you completely misunderstood the whole thing. What makes 
>> you think there is any CMYK -> RGB conversion involved here?
>> 
> I think he's talking about the procedure to perform when the source file
> is CMYK. The proposal is to convert it to RGB (in the "what about CMYK
> files" section of the Peter's document). 
>   

To me it sounded as if he thought there would be constant lossy RGB -> 
CMYK -> RGB conversions when you do adjustments after having pulled down 
the CMYK projection, but the adjustment you do with the CMYK projection 
is already is in the CMYK space, they just get reapplied all the time 
(this is where the non-destructiveness comes in). The edits you do in 
RGB is a one way transform only to CMYK, so there is no destructive RGB 
-> CMYK -> RGB -> CMYK -> RGB -> CMYK involved here either.

Anyway, I apologize if I misinterpreted you Andrew.

BR,
Martin
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2

[Guillermo Espertino]

> It seems to me you completely misunderstood the whole thing. What makes 
> you think there is any CMYK -> RGB conversion involved here?

I think he's talking about the procedure to perform when the source file
is CMYK. The proposal is to convert it to RGB (in the "what about CMYK
files" section of the Peter's document). 

I have to say that after reading the whole proposal I'm pretty
enthusiastic about these changes (even though I wasn't very convinced at
first).
It looks like a totally different way to manage the workflow and it
lools very promising.
However, the "what about CMYK files" sounds destructive, since the
original separations will be discarded and a new separation will be
created.
The projections thing sounds great for new artwork, where you can
actually define what layer will go in each plate, but sounds tricky for
flattened artwork.
What if I want to touch up an image that a client sent me, already
separated?

Gez

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Tobias Ellinghaus]

Am Samstag, 20. Juni 2009 schrieb yahvuu:

[...]

> Can you give an outline how the print color for that text will be
> specified? The RGB color isn't useful here and the text layer can't be
> accessed while the press projection is pulled over, IIUC. So each artwork
> layer will have a custom color separation setting resp. color mapping?

From Peter's blog post:

"However there will be full flexibility to map the content of any layer 
directly to any plate. For instance that light blue text in our example: it 
can be directly mapped from its text layer to the light blue plate, bypassing 
the composite."


I understand that you can use layers as plates.


signature.asc
Description: This is a digitally signed message part.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[yahvuu]

hi,

peter sikking schrieb:
> (peter) yahvuu wrote:
> 
>> there's one thing i don't understand, may be a misconception:
>> why is it necessary to have separate modes for editing the RGB data
>> and the plates?
> 
> mainly because creating art on a RGB monitor, to be used on
> many media, is not the same _activity_ as bringing this art to
> _one_ particular printing press.
> 
> also, it is better when the art itself is separated from the adaptation of
> it for one press run.


ah, that helps. So it is deprecated to create single-ink 'light blue text'
directly on  the 'light blue' plate, as the text would then not be known to
be part of the artwork.

Can you give an outline how the print color for that text will be specified?
The RGB color isn't useful here and the text layer can't be accessed while
the press projection is pulled over, IIUC. So each artwork layer will have
a custom color separation setting resp. color mapping?



>> For example, if i have an RGB image in the composition and want to apply
>> 'value curves', that has to be done in the RGB area, for after
>> separation the plates are treated individually.
> 
> the question is what is the curve for? is it artistic? then RGB is your
> space. getting the plates right? then chain them together and do a curve.
> 
>> Now only after manually pulling over the 'press projection' again i
>> can discover that this operation drove my plates out of gamut.
> 
> there is going to be no substitute for experience with printing presses
> and especially the particular press one is working towards.

sure. Gamut warnings can only ease the first step, by guiding
the color separation process.



>> Is it correct that there's no 'live preview' of the effects that RGB
>> manipulations have on the plates?
> 
> 
> if that is really needed by some users (see the two activities above
> and also "no substitute for experience") then a second view of the
> file (View->New view) can be run with the projection pulled down.
> might be hard on the processor.

Regarding the use-case of matching one color from a photo with a
predetermined ink combination, i think this will be useful.


greetings,
peter

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Martin Nordholts]

Andrew A. Gill wrote:
> On Fri, 19 Jun 2009, peter sikking wrote:
>   
>> guys,
>>
>> the second part of my lgm talk is blogged now:
>>
>> > 
>> enjoy,
>> 
>
> I have to go somewhere, so I haven't read evreything 
> yet, but I'd like to make this point.  Converting from CMYK to 
> RGB and vice versa are not lossless by a long shot.  This is by 
> necessity and the fact that GEGL is non-destructive has nothing 
> to do with it

Isn't it a good idea to first read what you are commenting on?

It seems to me you completely misunderstood the whole thing. What makes 
you think there is any CMYK -> RGB conversion involved here?

 / Martin
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Andrew A. Gill]

On Fri, 19 Jun 2009, peter sikking wrote:

> guys,
>
> the second part of my lgm talk is blogged now:
>
>  >
>
> enjoy,

I do appreciate your work on this, but I have to say that I still 
have some concerns.

I have to go somewhere, so I haven't read evreything 
yet, but I'd like to make this point.  Converting from CMYK to 
RGB and vice versa are not lossless by a long shot.  This is by 
necessity and the fact that GEGL is non-destructive has nothing 
to do with it, since large porions of image data will have to be 
tossed when converting.

The gamut for RGB is far larger in the bright colors, and CMYK 
can produce effects that cannot be produced in RGB.

See, for example: 


I am very concerned that your overlay concept would simply 
degrade the image over successive conversions.

-- 
| Andrew A. Gill To ensure continued quality of service,   |
|this e-mail is being monitored by the NSA |
|   |
   --
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Chris Mohler]

On Fri, Jun 19, 2009 at 12:41 PM, peter sikking wrote:
> Chris Mohler wrote:
>
>>>
>>> >
>> I like this approach.
>>
>> I have a few questions:
>>
>> Will each plate have a density or opacity attribute?  (some inks are
>> more opaque than others)
>
> I guess that the complexities of ink simulation start showing here.

Yes - although transparency/opacity would be enough for me to use GIMP
for professional separation work.  I'm reasonably sure that PS uses a
variant of the blending mode Multiply for spot channels, and this
works fairly well.

>> Will it be possible to edit an individual plate in grayscale?
>
> well, as pippin said: the individual plates _are_ grayscale/monochrome
> drawables. they will be editable just like layer masks or selections.

Excellent.

>> And finally, will it be possible to perform operations on the RGB
>> portion of the image that do not take (immediate) effect on the
>> projection?  For example, if I want to go back and add a portion of my
>> RGB artwork to a plate, I might want to clone and existing RGB layer,
>> perform some modifications, then apply the contents of that new layer
>> to one of the plates.
>
>
> I am curious why you want to do something like that, because you
> are then going against the grain of the whole plan: freedom to develop
> the artistic concept further without (much) rework on the plates.

Imagine I'm designing a black t-shirt with say five spot colors,
including white.  After completing the artistic design, I enable the
'projection screen'.  This theoretically would result in my five
"plates".  However, the white plate will need special attention.

Here's my workflow for this in PS: I would use the (badly named)
'Apply Image' command to take the contents of each color plate and
combine them into the white plate using the mode 'multiply'.  I would
also manually "choke" the white plate - this means making the white
areas a point or two smaller than the colored areas, thereby
preventing the white from poking out at the edges of the colored
areas.  This process can get a bit tricky, especially if the original
artwork is very complex.  Often, create temporary layers (or plates),
perform selection/drawing functions, then combine the result back into
a plate in one of two ways - either making a selection on the temp
layer and going to the plate and filling or erasing, or using the
'Apply Image' command to take the RGB channel of the current layer and
combine it with a plate using a mode such as Multiply, Screen, or Add.

Now, I am quite interested in learning new workflows - so I am not
bound to the "how" of the method above, but I hope I have explained
the "why" well enough.  In addition to being able to interact with
each plate as a grayscale drawable, it would be useful to create
temporary areas for doing work - be they layers, channels, plates,
whatever - on which to create paths, selections, etc to in turn use to
modify the plates manually.  Icing on the cake would be a mechanism to
combine/subtract plates using the available blending modes.  During
the process, it is fairly critical to have an ink density/opacity
setting for each plate, to simulate (roughly) how the final print is
going to look.  EG, set the white plate at approx 90%, the colors at
approx 70% - and you can see which portions of the colors are falling
on the white underlay, and which portions are falling on the black
shirt.

I realize that this is just one corner case, but if you visualize each
plate being printed separately, in order, you may be able to recognize
some of the many 'gotchas' inherent in separating the artistic artwork
into something suitable to send to the press.  That's why (in my
opinion) it is important to have as much control as possible over each
plate.

Whew ;)

If I explained any of this poorly, I am sorry and will happily try to do better.

All in all, I am very pleased with the direction that this is taking
and I would certainly like to use GIMP for even more of my production
work. :)

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Øyvind Kolås]

On Fri, Jun 19, 2009 at 6:56 PM, Alexandre
Prokoudine wrote:
> On Fri, Jun 19, 2009 at 8:05 PM, yahvuu wrote:
>
>> there's one thing i don't understand, may be a misconception:
>> why is it necessary to have separate modes for editing the RGB data
>> and the plates?
>>
>> For example, if i have an RGB image in the composition and want to apply
>> 'value curves', that has to be done in the RGB area
>
> In 21st century there are no RGB curves :) There are LAB and L*c*h* ones ;)

Not that the difference really matter as both linear light RGB and CIE
Lab are fully mutually transformable into each other. For CIE Lab or
Lch it would only make proper sense to control the L, other controls
can be used for tuning white point etc in those color models though.

/Øyvind K.
-- 
«The future is already here. It's just not very evenly distributed»
 -- William Gibson
http://pippin.gimp.org/http://ffii.org/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[peter sikking]

Chris Mohler wrote:

>> 
> I like this approach.
>
> I have a few questions:
>
> Will each plate have a density or opacity attribute?  (some inks are
> more opaque than others)

I guess that the complexities of ink simulation start showing here.

> Will it be possible to edit an individual plate in grayscale?

well, as pippin said: the individual plates _are_ grayscale/monochrome
drawables. they will be editable just like layer masks or selections.

> And finally, will it be possible to perform operations on the RGB
> portion of the image that do not take (immediate) effect on the
> projection?  For example, if I want to go back and add a portion of my
> RGB artwork to a plate, I might want to clone and existing RGB layer,
> perform some modifications, then apply the contents of that new layer
> to one of the plates.


I am curious why you want to do something like that, because you
are then going against the grain of the whole plan: freedom to develop
the artistic concept further without (much) rework on the plates.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Chris Mohler]

On Fri, Jun 19, 2009 at 10:37 AM, peter sikking wrote:
> guys,
>
> the second part of my lgm talk is blogged now:
>
> 

Re: [Gimp-developer] lgm talk, part 2...

[Alexandre Prokoudine]

On Fri, Jun 19, 2009 at 8:05 PM, yahvuu wrote:

> there's one thing i don't understand, may be a misconception:
> why is it necessary to have separate modes for editing the RGB data
> and the plates?
>
> For example, if i have an RGB image in the composition and want to apply
> 'value curves', that has to be done in the RGB area

In 21st century there are no RGB curves :) There are LAB and L*c*h* ones ;)

Alexandre
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[peter sikking]

(peter) yahvuu wrote:

> there's one thing i don't understand, may be a misconception:
> why is it necessary to have separate modes for editing the RGB data
> and the plates?

mainly because creating art on a RGB monitor, to be used on
many media, is not the same _activity_ as bringing this art to
_one_ particular printing press.

also, it is better when the art itself is separated from the  
adaptation of
it for one press run.

> For example, if i have an RGB image in the composition and want to  
> apply
> 'value curves', that has to be done in the RGB area, for after
> separation the plates are treated individually.

the question is what is the curve for? is it artistic? then RGB is your
space. getting the plates right? then chain them together and do a  
curve.

> Now only after manually pulling over the 'press projection' again i
> can discover that this operation drove my plates out of gamut.

there is going to be no substitute for experience with printing presses
and especially the particular press one is working towards.

> Is it correct that there's no 'live preview' of the effects that RGB
> manipulations have on the plates?


if that is really needed by some users (see the two activities above
and also "no substitute for experience") then a second view of the
file (View->New view) can be run with the projection pulled down.
might be hard on the processor.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[yahvuu]

Hi all,

there's one thing i don't understand, may be a misconception:
why is it necessary to have separate modes for editing the RGB data
and the plates?

For example, if i have an RGB image in the composition and want to apply
'value curves', that has to be done in the RGB area, for after
separation the plates are treated individually.
Now only after manually pulling over the 'press projection' again i
can discover that this operation
drove my plates out of gamut.

Is it correct that there's no 'live preview' of the effects that RGB
manipulations have on the plates?


greetings,
peter
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer