Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings

[Liam R E Quin]

On Tue, 2014-03-11 at 15:45 -0300, Gez wrote:

> There are three possible workflows for print:
> Early binding: All the assets are converted to CMYK and editing is done
> in CMYK. The files you send to the print shop are CMYK.
> Late Binding: Everything is worked in RGB. The print shop converts to
> CMYK.
> Intermediate Binding: Creative work is done in RGB, the files are
> converted to CMYK prior sending them to the print shop.
> 
> GIMP can't edit CMYK directly, but it can serve to the other two
> possible workflows.

Note that the case I mentioned the other day as seeming to be out of
scope is when you *are* the print shop, and you (sometimes) receive the
cmyk files, or need to edit them. E.g. remove an impression number from
the imprint page and then send to imposition... but it seems it's in
scope and just not there yet.

[...]

> > Having the title/status bar(s) show which display filters are active 
> > would be very useful, especially given that if you close the display 
> > filter window, any activated filters (or deactivated, in the case of the 
> > Color Management filter) are still applied to the image.
> 
> That would be an interesting addition, but I wonder if the current model
> of having multiple "working profiles" can't be replaced by something
> more useful.
> This is probably off-topic, but having to worry about the file profile,
> a working profile, a print preview profile and a print profile in the
> preferences as global settings seems messy and inefficient. And in GIMP
> 2.9 it probably doesn't make so much sense as it used to.

The world is messy, I'm afraid.


> From a user point of view having all the imported stuff converted
> automatically to a high quality internal model (high bit depth linear
> scRGB?) and having per-image output/proof settings seems more
> straightforward and less error prone than the current mixture of
> profiles.

Are you going to pay for the extra memory I'll need? I only have 32G and
already with 2.9 I sometimes am swapping.

> It may or may not be a problem for keeping legacy compatibility, but I
> can imagine how simplified the UI and common workflows would be (no
> bit-depth "modes", no assign/convert to profile, no profile-mismatch
> warnings, simplified CM preferences, etc).

You might not always be able to do round-tripping, because a colour in
the input image's colour model might be out of gamut for the working
profile. I don't know how big an issue that would be. Similarly you'd
end up using colours that wouldn't come out at all right on your output
device. The warnings are there for a reason...

Best,

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Question about 2.8.11

[Michael Bauer]

Paka was right though, I should have mentioned, sorry!

Michael

11/03/2014 23:54, sgrìobh gimp-developer-list-requ...@gnome.org:

We already know Michael:)  He's our Scottish Gaelic guy:)

Alexandre


--
*Akerbeltz *
Goireasan Gàidhlig air an lìon
Fòn: +44-141-946 4437
Facs: +44-141-945 2701

*Tha Gàidhlig aig a' choimpiutair agad, siuthad, feuch e!*
Iomadh rud eadar prògraman oifis, brabhsairean, predictive texting,
geamannan is mòran a bharrachd. Tadhail oirnn aig www.iGàidhlig.net 


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Two questions about updating GIMP from git

[Michael Henning]

Here are two scripts that I use to help keep git up to date. The first
updates my git checkouts, and the second cleans out any build files
(which is useful to run from time to time). They require $SRC_DIR to
be set to the directory that your babl/gegl/gimp checkouts are under,
and $INSTALL_PREFIX must be the location of your install prefix.

The main key to these script is that the first line is "#!/bin/bash
-e". The -e argument to bash means that if any command in the script
fails, then the script will exit immediately, instead of continuing to
the next command.

upd.sh:

#!/bin/bash -e

build () {
cd $SRC_DIR/$1

git pull --rebase

if [ ! -f ./Makefile ];
then
./autogen.sh --prefix=$INSTALL_PREFIX --enable-fast-install $2
fi

make
make install
}

build babl
build gegl "--enable-gtk-doc --enable-debug"
build gimp

clean.sh:

#!/bin/bash

rm -r $INSTALL_PREFIX
mkdir $INSTALL_PREFIX

clean () {
cd $SRC_DIR/$1
git clean -Xdf
git pull --rebase
}

clean babl
clean gegl
clean gimp

Hopefully this helps.

  -- drawoc

On Tue, Mar 11, 2014 at 7:37 AM, Elle Stone
 wrote:
> Shlomi Fish and SorinN,
>
> Thanks! With examples to work from, hopefully it won't be too hard to write
> a script that makes updating GIMP easier.
>
> Elle
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings

[Gez]

El mar, 11-03-2014 a las 07:16 -0400, Elle Stone escribió:

> I don't know anything about CMYK printing and I've never used the CM+ 
> plugin, so please bear with me while I ask a couple of questions:
> 
> Putting *editing* CMYK channels to one side, is it useful to modifythe 
> RGB channels while soft proofing to a CMYK profile (or even n-channel 
> profile whether color or black and white)? I thought that was what the 
> CM+ plugin made possible? Is this an example of what Gez calls "late 
> binding"?

Not exactly, but related.
There are three possible workflows for print:
Early binding: All the assets are converted to CMYK and editing is done
in CMYK. The files you send to the print shop are CMYK.
Late Binding: Everything is worked in RGB. The print shop converts to
CMYK.
Intermediate Binding: Creative work is done in RGB, the files are
converted to CMYK prior sending them to the print shop.

GIMP can't edit CMYK directly, but it can serve to the other two
possible workflows.
soft proofing to a CMYK profile is useful because you can work in RGB
with all the freedom it allows, but at the same time you can "preview"
how the target gamut and rendering intent will affect your image. I
think this is specially useful when using colorimetric intents, where
all the out-of-gamut values get clamped.

CM+ allowed that. Iirc, it did more or less the same than the current
color proof filter with some extra goodies (individual CMYK channels
preview, black ink/paper white simulation, etc.)

Check this video from 1:40
https://www.youtube.com/watch?v=Q99MeymK7wA&feature=youtu.be&hd=1
(if you can endure the disturbing music, it shows the filter in action).

> Having the title/status bar(s) show which display filters are active 
> would be very useful, especially given that if you close the display 
> filter window, any activated filters (or deactivated, in the case of the 
> Color Management filter) are still applied to the image.

That would be an interesting addition, but I wonder if the current model
of having multiple "working profiles" can't be replaced by something
more useful.
This is probably off-topic, but having to worry about the file profile,
a working profile, a print preview profile and a print profile in the
preferences as global settings seems messy and inefficient. And in GIMP
2.9 it probably doesn't make so much sense as it used to.
From a user point of view having all the imported stuff converted
automatically to a high quality internal model (high bit depth linear
scRGB?) and having per-image output/proof settings seems more
straightforward and less error prone than the current mixture of
profiles.
It may or may not be a problem for keeping legacy compatibility, but I
can imagine how simplified the UI and common workflows would be (no
bit-depth "modes", no assign/convert to profile, no profile-mismatch
warnings, simplified CM preferences, etc).

Gez.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings

[Omari Stephens]

On 03/11/2014 11:16 AM, Elle Stone wrote:

On 03/10/2014 04:06 PM, Liam R E Quin wrote:

On Mon, 2014-03-10 at 08:55 -0400, Elle Stone wrote:

::snip? SNIP!::

I agree 100% that soft proofing requires the ability to quickly switch
gamut checks on and off, and also quickly enable/disable soft proofing.

+1 although for print work at this point you have to move to Krita or
Photoshop, most likely photoShop with a "preflight" plugin, so that you
can adjust individual plates (e.g. with dodge) for the different ink
colours (CMYK at the most basic, or two plates for a duotone).

The decision is (as I understand it) for GIMP to stay out of the print
shop so this all gets a little fuzzy for me.


I don't know anything about CMYK printing and I've never used the CM+
plugin, so please bear with me while I ask a couple of questions:

Putting *editing* CMYK channels to one side, is it useful to modifythe
RGB channels while soft proofing to a CMYK profile (or even n-channel
profile whether color or black and white)? I thought that was what the
CM+ plugin made possible? Is this an example of what Gez calls "late
binding"?


early binding == "you send CMYK to the person who prints your work"
late binding == "you send RGB to the person who prints your work, and 
they convert to CMYK"


You are correct that CM+ supports "separations" (which is the word for 
looking at each channel individually).  But in that case, this would be 
part of an early-binding workflow, because you're touching CMYK rather 
than just RGB.


That said, I think your question touches on something that I'm pretty 
ignorant about, which is how color profiles deal with different numbers 
and types of channels.  I know there is a thing called a GRAY profile, 
but I have no idea what makes it special or different than a standard 
profile.  Is it basically an RGB profile with R==G==B?


In the New GEGL World, converting between different channel layouts is 
going to be a reality, and we should at least put _some_ thought into 
what that means for color management.  Of course, this is way out of my 
depth, and I have no idea.



But there are plenty of non-print use cases for soft proofing, of
course, including e.g. targeting a specific mobile device (even though
there's huge variation between individuals, there are basic limits on
the colour you can usefully work with) or for projection at a conference
or in an art gallery.


There's also converting from a camera input profile to an RGB working
space, and from one RGB working space to another, and from a larger RGB
working space to sRGB for display on the web. Also, some commercial
printers (for example, some print shops with Chromira and Frontier
printers) provide RGB printer profiles to customers to use when soft
proofing.


These are the usecases that matter to me, so yes :o)


A common way to soft proof requires having the image open twice to
compare the original with the soft proofed version.


Yes. It's unfortunate that Single Window Mode makes this hard.



The current GIMP preferences allow you to choose "Print Simulation" in
"Preferences/Color Management/Mode of operation". But that sets *all*
open images to Print Simulation mode, for which I can't think of any use
cases.

No - a display filter makes more sense, agreed. Then you could maybe
make the filter apply be default to all images if you really wanted?
There should be (is??) a way to include something in the title bar
and/or status bar to show which display filters are active.


Having the title/status bar(s) show which display filters are active
would be very useful, especially given that if you close the display
filter window, any activated filters (or deactivated, in the case of the
Color Management filter) are still applied to the image.


Sounds reasonable.

--xsdg

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Question about 2.8.11

[Alexandre Prokoudine]

On Tue, Mar 11, 2014 at 4:49 PM, Paka wrote:

> You might have better luck if you actually define "our language" ???

We already know Michael :) He's our Scottish Gaelic guy :)

Alexandre
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Question about 2.8.11

[Michael Bauer]

11/03/2014 14:12, sgrìobh Michael Natterer:
Odd micro version are git versions, there is no release with .11 Even 
micro versions are tarball releases, the next one will be 2.8.12 
Mmmm I'm mainly a localizer, I have to admit I didn't understood most of 
that but .11 was just me working off the current version being .10, if 
it's going to be another number, I really don't mind, it's the locale 
release I'm after not a specific number ;)

In the next couple of weeks, if I find the time/motivation to
make a release. If you are on Windows, you can always use
That would be great but yes, I understand the time/motivation 
constraints we're all under

the nightly builds from http://nightly.darkrefraction.com/gimp/
I know about those, thanks, it's just that I know the moment word gets 
out people will start looking - and misquoting. Just had that two days 
ago when I posted about an *upcoming* release and within 3 reposts on 
Facebook it had become a "released game". And then I'm answering 
questions along the lines of "where is it" >.<


So I tend to wait until there's a proper release. But yes, hand for demos.

Cheers

Michael
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Question about 2.8.11

[Michael Natterer]

On Tue, 2014-03-11 at 11:23 +, Michael Bauer wrote:
> Hi
> 
> I'm going to a school tomorrow to advise them on using open software in 
> our language. I'd like to include GIMP in the equation but it would be 
> helpful if I could have a very rough idea about when our language is 
> likely to get released (localization completed and in the repo as of ~3 
> weeks ago)? I'm guessing it would be 2.8.11 and I've looked for a 
> release schedule but found nothing concrete or up to date (but I may be 
> looking in the wrong places).

Odd micro version are git versions, there is no release with .11
Even micro versions are tarball releases, the next one will be 2.8.12

> Does someone have a very rough estimate of timescale we're looking at?

In the next couple of weeks, if I find the time/motivation to
make a release. If you are on Windows, you can always use
the nightly builds from http://nightly.darkrefraction.com/gimp/

Regards,
--Mitch


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Question about 2.8.11

[Paka]

* Michael Bauer  [03-11-14 07:25]:
> I'm going to a school tomorrow to advise them on using open software in
> our language.  I'd like to include GIMP in the equation but it would be
> helpful if I could have a very rough idea about when our language is
> likely to get released (localization completed and in the repo as of ~3
> weeks ago)?  I'm guessing it would be 2.8.11 and I've looked for a
> release schedule but found nothing concrete or up to date (but I may be
> looking in the wrong places).
> 
> Does someone have a very rough estimate of timescale we're looking at?

You might have better luck if you actually define "our language" ???

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2
Registered Linux User #207535@ http://linuxcounter.net
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Two questions about updating GIMP from git

[Elle Stone]

Shlomi Fish and SorinN,

Thanks! With examples to work from, hopefully it won't be too hard to 
write a script that makes updating GIMP easier.


Elle
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Question about 2.8.11

[Michael Bauer]

Hi

I'm going to a school tomorrow to advise them on using open software in 
our language. I'd like to include GIMP in the equation but it would be 
helpful if I could have a very rough idea about when our language is 
likely to get released (localization completed and in the repo as of ~3 
weeks ago)? I'm guessing it would be 2.8.11 and I've looked for a 
release schedule but found nothing concrete or up to date (but I may be 
looking in the wrong places).


Does someone have a very rough estimate of timescale we're looking at?

Thanks

Michael
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings

[Elle Stone]

On 03/10/2014 04:06 PM, Liam R E Quin wrote:

On Mon, 2014-03-10 at 08:55 -0400, Elle Stone wrote:


The odd behavior of the display filters came to my attention because
I've been working on rewriting some of the GIMP color management
documentation and so took a closer look at what all the display filters do.


Documenting (briefly) the wrongness might help demonstrate what needs to
be done, too.


In the original post, e - i and especially e, f, g describe odd and 
wrong results:


On 03/02/2014 12:51 PM, Elle Stone wrote:

e. If the "Mode of operation" is set to "Print simulation" in the
globally applied "Edit/Preferences/Color Management" settings dialog,
and if the user also chooses to activate the per image "Color Proof"
display filter, then the global choices made in the Color Management
settings are applied on top of the per image choices made in the
Color Proof Display filter, and the results are wrong.



f. Multiple active copies of the Color Proof Display Filter in turn
apply each copy's soft proofing choices, with increasingly wrong results.



g. One active copy of the Color Management display filter acts as
expected. But multiple active copies of the Color Management display
filter each in turn apply the conversion from the image ICC profile
to the monitor ICC profile.  . . .
when using an actual monitor profile (sRGB doesn't adequately
describe LCD monitors), successively applying multiple copies of the
Color Management filter results in increasingly noticeable and wrong
color and tonality changes.



e is just wrong behavior.

f and g could be considered the result of users not thinking about what 
they are doing. But the display filter gui shouldn't allow dragging 
multiple copies of the Color Management or Soft Proofing display filters 
over to the active pane as doing so makes no sense at all.



I agree 100% that soft proofing requires the ability to quickly switch
gamut checks on and off, and also quickly enable/disable soft proofing.

+1 although for print work at this point you have to move to Krita or
Photoshop, most likely photoShop with a "preflight" plugin, so that you
can adjust individual plates (e.g. with dodge) for the different ink
colours (CMYK at the most basic, or two plates for a duotone).

The decision is (as I understand it) for GIMP to stay out of the print
shop so this all gets a little fuzzy for me.


I don't know anything about CMYK printing and I've never used the CM+ 
plugin, so please bear with me while I ask a couple of questions:


Putting *editing* CMYK channels to one side, is it useful to modifythe 
RGB channels while soft proofing to a CMYK profile (or even n-channel 
profile whether color or black and white)? I thought that was what the 
CM+ plugin made possible? Is this an example of what Gez calls "late 
binding"?



But there are plenty of non-print use cases for soft proofing, of
course, including e.g. targeting a specific mobile device (even though
there's huge variation between individuals, there are basic limits on
the colour you can usefully work with) or for projection at a conference
or in an art gallery.


There's also converting from a camera input profile to an RGB working 
space, and from one RGB working space to another, and from a larger RGB 
working space to sRGB for display on the web. Also, some commercial 
printers (for example, some print shops with Chromira and Frontier 
printers) provide RGB printer profiles to customers to use when soft 
proofing.



A common way to soft proof requires having the image open twice to
compare the original with the soft proofed version.


Yes. It's unfortunate that Single Window Mode makes this hard.



The current GIMP preferences allow you to choose "Print Simulation" in
"Preferences/Color Management/Mode of operation". But that sets *all*
open images to Print Simulation mode, for which I can't think of any use
cases.

No - a display filter makes more sense, agreed. Then you could maybe
make the filter apply be default to all images if you really wanted?
There should be (is??) a way to include something in the title bar
and/or status bar to show which display filters are active.


Having the title/status bar(s) show which display filters are active 
would be very useful, especially given that if you close the display 
filter window, any activated filters (or deactivated, in the case of the 
Color Management filter) are still applied to the image.


Elle
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list