Re: [Gimp-user] [Gimp-developer] GIMP-2.10 and GIMP2.99 are still sRGB-only image editors

[Elle Stone]

On 2/4/21 11:27 PM, Alexandre Prokoudine via gimp-user-list wrote:

On Fri, Feb 5, 2021 at 3:00 AM Elle Stone wrote:


Participating in GIMP development used to be challenging and enjoyable.
But over the last couple of years my interest in and patience with the
slow pace of progress regarding GIMP color management have dwindled to
the point of disappearing altogether.


Two years ago we had three active developers hacking on GIMP like
there was no tomorrow.

We lost one of them entirely, it seems, and another one is mostly
preoccupied with family business, so we are down to one active
developer and a few new active contributors. We are also approaching
the end of very long and tiresome work on refactoring which is not
done yet. Also, a lot of time of that one active developer was spent
figuring out ways to make development of GIMP sustainable (no details
at this point in time, sorry). So yes, there are several critical
areas where help is needed. Color management is clearly one of them.

I guess if you adjust your expectations accordingly, you will see that
there is no acting in bad faith here.


Alexandre, I'm not sure why you felt obligated to introduce the idea of 
"acting in bad faith". It has not escaped my notice that various 
developers have cut back or ceased altogether from participating in GIMP 
development. I'm not even completely unaware of some of the reasons.


Life happens, sometimes good, sometimes not good. Speaking for myself, I 
knew two years ago that I had a limited timeframe in which to hopefully 
help bring GIMP color management to the state of being reliable for 
color spaces other than sRGB. My family is dealing with some serious 
problems, has been for a long time now and will be for the foreseeable 
future.


It's good to hear that someone on the team is trying to figure out how 
to make GIMP development sustainable. Hopefully that effort includes 
figuring out how to prioritize goals based on the editing needs of 
potential and actual users.


To the members of the GIMP team who've worked with me over the years on 
various color-management/color-science topics - you know who you are, so 
I won't name any names - you went out of your way to help with my coding 
efforts and you made me feel like a part of the team - that meant a lot. 
Thank you.


Speaking of "thank you", Michael Schumacher's "Concepts: Color Science" 
tag will be a big help to whichever current or future devs turn their 
attention to making GIMP finally be fully and reliably color-managed. 
One of the first things I did when starting to work on GIMP color 
management, was to compile a list for all open and closed GIMP bug 
reports having to do with color management, then read through and 
categorize all the bugs, to get an idea of what was already done, what 
was left to do, and most importantly to figure out what concerns 
motivated the users who filed the bug reports. A "Concepts: Color 
Science" tag would have been a big help.


GIMP is important in the free-libre universe of image-editing programs. 
But without good color management GIMP is seriously flawed as a 
professional-level editing program.


Best wishes to GIMP team members past, present, and future.
Elle

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

Re: [Gimp-user] GIMP-2.10 and GIMP2.99 are still sRGB-only image editors

[Elle Stone]

On 2/4/21 8:31 PM, Gloria Lassich via gimp-user-list wrote:

Is GIMP no longer being actively improved on, then? Is it worth it to use
GIMP at this point? In other words, are most of the developers no longer
paying attention to feature requests users need/want? Sorry if I sound
dramatic, that’s not my intent. 藍 --


Yes GIMP is being actively developed. Yes GIMP needs more developers. 
The current main goal is getting GIMP converted to GTK3. Supposedly at 
some point in the future fixing color management will be a priority.


I'm not sure what a good way to respond to feature requests that users 
need/want actually is. I think maybe Krita devs have a handle on the 
problem but I don't know for sure. The problem is that everyone has "an 
interest" that they think should be "the most important feature".


I'm not sure that currently there is enough teamwork and planning for 
GIMP as a whole, with respect to needs of users. I think there might be 
a bit too much "What developer A wants and what developer B wants".


Personally I've run out of time and interest to devote to GIMP color 
management. It's a lot closer to being truly useful than it used to be. 
It's still got a long way to go.


I'm hoping some new developers/contributors to GIMP show up who have a 
good knowledge of color management/color science plus the time, energy, 
and patience that I used to have. Even if you can't write code, if you 
have the ability to compile GIMP from source and test new code carefully 
and systematically, and report problems with color management, that is a 
good contribution, a necessary contribution.


Elle






http://www.instagram.com/thecrazyloop
Deeply discounted ebooks:
https://bit.ly/3ghjL1s
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list




--
https://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] GIMP-2.10 and GIMP2.99 are still sRGB-only image editors

[Elle Stone]

On 2/4/21 7:14 PM, Michael Schumacher via gimp-user-list wrote:



On February 5, 2021 12:59:50 AM GMT+01:00, Elle Stone 
 wrote:


I was able to write code that fixed some of the bugs I reported for
GIMP-2.99 color management. But once I reached the point where further
coding requirements exceeded my coding ability, progress simply
stopped,
with everyone else saying "some day" proper color management for GIMP
would be a priority. I began to feel like the best way to make sure a
bug would never get fixed, was to have the dreaded "Concepts: Color
Science" tag attached to it.


You make it sound like introducing this tag was a wrong decision. As I 
introduced it as a way to group thhese issues together, did I do something 
wrong there?



Of course you didn't do anything wrong. It's an excellent tag to let 
people know what the topic is.


It's been stated over and over again by a particular GIMP dev that GIMP 
development works best if people do what they are interested in doing. 
The question is which current GIMP devs other than myself have an 
*interest* in dealing bugs tagged with "Concept: Color Science"?


It would be great if you could find the time to go through the links I 
provided in my post and add the tag as appropriate to any relevant bug 
reports that don't yet have the tag. Someday when GIMP has found another 
developer with an interest in color management and color science, that 
person will find the "Concepts: Color Science" tag very useful.


Best,
Elle

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

[Gimp-user] GIMP-2.10 and GIMP2.99 are still sRGB-only image editors

[Elle Stone]

A misconception I keep seeing on various forums needs to be corrected:

GIMP-2.10 does *NOT* produce correct editing results in color spaces 
other than sRGB. Neither does GIMP-2.99.


Editing in AdobeRGB, ProPhotoRGB, Rec2020, etc WILL produce *wrong* 
results for many operations, and unless you are thoroughly conversant 
with the underlying code, or else have a way to compare results with a 
properly color-managed editing application, you don't have any way to 
know what's right and what's wrong. It's best to stick with editing only 
in GIMP's built-in sRGB color spaces.


The same is true if you are using GIMP-2.99: Some things that don't work 
in GIMP-2.10, do work in GIMP-2.99. Other things that actually do work 
in GIMP-2.10, don't work in GIMP-2.99.


About two years ago major changes were made in babl and additional 
changes were made in GIMP-2.99, messing up stuff that still works in 
GIMP-2.10. For awhile progress was being made in GIMP-2.99 on extending 
the arena of "what actually works", some of which progress is from bug 
reports I filed and in some cases helped to fix - it seems nobody else 
was testing the new code to see what actually did work.


I was able to write code that fixed some of the bugs I reported for 
GIMP-2.99 color management. But once I reached the point where further 
coding requirements exceeded my coding ability, progress simply stopped, 
with everyone else saying "some day" proper color management for GIMP 
would be a priority. I began to feel like the best way to make sure a 
bug would never get fixed, was to have the dreaded "Concepts: Color 
Science" tag attached to it.


Since autumm of 2013 I've been participating in GIMP development, mostly 
in the area of color management (editing in color spaces other than 
sRGB) and color science (making sure GIMP code produces correct results 
for things like layer blend modes, Curves and Levels, AutoStretch, 
Luminance, and so on; and adding code for things like LCh color pickers 
and blend modes).


Participating in GIMP development used to be challenging and enjoyable. 
But over the last couple of years my interest in and patience with the 
slow pace of progress regarding GIMP color management have dwindled to 
the point of disappearing altogether.


If someone else feels like helping with GIMP color management and color 
science, here's a list of still-open bug reports that I reported after 
the migration to gitlab, most of which have to do with color 
management/color science:


https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all=%E2%9C%93=opened_username=ellestone

Here are bugs that I opened before the migration to gitlab:
https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all=%E2%9C%93=opened_username=bugzilla-migration=ellestone

The most important color management bugs still open from before the 
migration to gitlab are these:


* Replace hard-coded sRGB parameters to allow editing in other RGB 
working spaces (opened 6 years ago): 
https://gitlab.gnome.org/GNOME/gimp/-/issues/594 - in some ways this bug 
is obsolete as current GIMP color management issues are less about 
actual hard-coded values and more about a lack of any way to convey the 
required "not sRGB" color space information to various sections of code 
that need this information.


* Decomposed to LAB images have the wrong ICC profile assigned (opened 4 
years ago): https://gitlab.gnome.org/GNOME/gimp/-/issues/883


* Address various limitations of LCMS soft proofing (opened 4 years 
ago): https://gitlab.gnome.org/GNOME/gimp/-/issues/976

the
and hoping very much that GIMP will find new developers that them a lot 
of energy and some interest and expertise in color management and color 
science.
* Support for high bit depth RGB (and LCH?) color palettes for painting 
(opened 2 years ago): https://gitlab.gnome.org/GNOME/gimp/-/issues/1328


Similar searchs in https://gitlab.gnome.org/GNOME/gegl/ and 
https://gitlab.gnome.org/GNOME/babl/ will turn up a few additional color 
management issues.


Best of luck to all,
Elle Stone

--
https://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] GIMP Version 2.8.16

[Elle Stone]

On 9/5/20 10:27 AM, Elle Stone wrote:

Hi Kenny,

In case Alex's suggestion to activate the legacy theme doesn't actually 
fix enough of the differences between "new gimp" and "old gimp", another 
possibility might be to install VirtualBox in your newest version of 
Mint, and then install in a virtual machine the last version of Mint 
that will install and run GIMP 2.8.


Two more possibilities for getting an older version of GIMP to run on 
current Mint:


* Try an appimage for GIMP-2.9 - the older the appimage, the closer it 
is to being more like GIMP-2.8. I used GIMP 2.9 since just about the 
beginning of its existence and it always ran just fine, very stable. 
Here's a link - scroll down to the files with "2.99" in the file name:

https://github.com/aferrero2707/gimp-appimage/releases/tag/continuous

Here's a link for asking about possibly older versions of GIMP-2.9 
appimage: 
https://discuss.pixls.us/t/gimp-appimage-continuous-integration/1959



* If GIMP for Windows runs on WINE (anyone know?), then try installing 
WINE and download an older precompiled version of GIMP for Windows. Just 
make sure the download site is reliable as many distributors of GIMP for 
Windows just want to distribute malware. "Partha's Place" is good place 
to download Windows versions of GIMP - scroll down on the right side, 
two versions of 2.8 are available:

https://www.partha.com/




Maybe you've already considered using a virtual machine, but if not, 
VirtualBox does allow to open/export/save files back and forth between 
the virtual machine's and real machine's hard drives. Once everything is 
running properly, make a backup copy of the virtual machine 
configuration files and especially the VDI (virtual disk image) in case 
the one you use every day somehow gets corrupted.


VirtualBox can be set up to run seamlessly inside the host Linux 
installation. I haven't used VirtualBox in several years, but back when 
I did use it regularly, it worked flawlessly to allow running an old 
operating system and software. I transferred that virtual machine 
through quite a few hardware and operating system changes, and it always 
worked like a charm.


I did find a pre-made, downloadable virtual machine for Mint 19:
https://www.linuxvmimages.com/images/virtualbox/
https://www.linuxvmimages.com/images/linuxmint-19/

Maybe somewhere there is a pre-made image for Mint 18 if Mint 19 won't 
work. But if you can install an operating system on bare metal, 
installing the same operating system in a virtual machine involves just 
about the exact same procedure - the difficult part is setting 
everything up to get to the point of actually being able to start 
installing the selected operating system.


Fortunately the VirtualBox forums are pretty good, or at least they used 
to be. Also there used to be (and probably still are) a lot of "how 
to's" on the internet, but at least in the past the "how to's"  were 
outdated almost as soon as they were written as VirtualBox itself was 
changing rapidly. So it's necessary to make sure the "how to" applies to 
the more recent versions of VirtualBox.


Probably the Mint forums could help, and the Arch Linux documentation 
always seem to have good, up-to-date "how tos" that often apply to other 
versions of Linux.


Best regards,
Elle


On 9/4/20 8:01 PM, Alexandre Prokoudine via gimp-user-list wrote:

But Kenny,

You do not have to go back to 2.8 to get back the old user interface.

'Edit > Preferences > Interface > Theme / Icon Theme' will give you
legacy options.

Alex

On Sat, Sep 5, 2020 at 2:46 AM Kenny Mann  
wrote:


I don't have the skills to compile GIMP from 
<https://download.gimp.org/mirror/pub/gimp/v2.8/gimp-2.8.22.tar.bz2>


The new interface in GIMP 2.10 is a problem somewhat unique to me. I 
have a neurological disorder. Navigating anything -- walking to the 
grocery store and back, traveling by trains, buses, airplanes, 
sometimes even finding the kitchen in my house -- is dependent on 
life-long-learned tricks that are based in objective visible 
familiarity. This neural disorder is worsening.


After using Photoshop since v. 2.2, I've been using GIMP 2.8 in Linux 
Mint 17 and 18 for years. I work in GIMP 2.8 for hours every day. 
Samples: <https://nowvthen.tumblr.com/archive> No prob.


The threshold for gaining use of GIMP 2.10 would take unknown weeks 
of mostly failure, due to the lack of neural mapping I have for the 
interface. Read: It looks only similar to anyplace I've ever been and 
it's a place I have no readable map for. To me, the (neural) map has 
blots that most people will easily read in the GIMP 2.10 interface as 
easily recognizable information.


The app manager in Mint 20 will only install GIMP 2.10 -- and 
<https://www.gimp.org/downloads/> has only a button for a flatpack of 
GIMP 2.10


GIMP 2.8 is available to install from the app manager in Mint

Re: [Gimp-user] GIMP Version 2.8.16

[Elle Stone]

Hi Kenny,

In case Alex's suggestion to activate the legacy theme doesn't actually 
fix enough of the differences between "new gimp" and "old gimp", another 
possibility might be to install VirtualBox in your newest version of 
Mint, and then install in a virtual machine the last version of Mint 
that will install and run GIMP 2.8.


Maybe you've already considered using a virtual machine, but if not, 
VirtualBox does allow to open/export/save files back and forth between 
the virtual machine's and real machine's hard drives. Once everything is 
running properly, make a backup copy of the virtual machine 
configuration files and especially the VDI (virtual disk image) in case 
the one you use every day somehow gets corrupted.


VirtualBox can be set up to run seamlessly inside the host Linux 
installation. I haven't used VirtualBox in several years, but back when 
I did use it regularly, it worked flawlessly to allow running an old 
operating system and software. I transferred that virtual machine 
through quite a few hardware and operating system changes, and it always 
worked like a charm.


I did find a pre-made, downloadable virtual machine for Mint 19:
https://www.linuxvmimages.com/images/virtualbox/
https://www.linuxvmimages.com/images/linuxmint-19/

Maybe somewhere there is a pre-made image for Mint 18 if Mint 19 won't 
work. But if you can install an operating system on bare metal, 
installing the same operating system in a virtual machine involves just 
about the exact same procedure - the difficult part is setting 
everything up to get to the point of actually being able to start 
installing the selected operating system.


Fortunately the VirtualBox forums are pretty good, or at least they used 
to be. Also there used to be (and probably still are) a lot of "how 
to's" on the internet, but at least in the past the "how to's"  were 
outdated almost as soon as they were written as VirtualBox itself was 
changing rapidly. So it's necessary to make sure the "how to" applies to 
the more recent versions of VirtualBox.


Probably the Mint forums could help, and the Arch Linux documentation 
always seem to have good, up-to-date "how tos" that often apply to other 
versions of Linux.


Best regards,
Elle


On 9/4/20 8:01 PM, Alexandre Prokoudine via gimp-user-list wrote:

But Kenny,

You do not have to go back to 2.8 to get back the old user interface.

'Edit > Preferences > Interface > Theme / Icon Theme' will give you
legacy options.

Alex

On Sat, Sep 5, 2020 at 2:46 AM Kenny Mann  wrote:


I don't have the skills to compile GIMP from 


The new interface in GIMP 2.10 is a problem somewhat unique to me. I have a 
neurological disorder. Navigating anything -- walking to the grocery store and 
back, traveling by trains, buses, airplanes, sometimes even finding the kitchen 
in my house -- is dependent on life-long-learned tricks that are based in 
objective visible familiarity. This neural disorder is worsening.

After using Photoshop since v. 2.2, I've been using GIMP 2.8 in Linux Mint 17 and 18 
for years. I work in GIMP 2.8 for hours every day. Samples: 
 No prob.

The threshold for gaining use of GIMP 2.10 would take unknown weeks of mostly 
failure, due to the lack of neural mapping I have for the interface. Read: It 
looks only similar to anyplace I've ever been and it's a place I have no 
readable map for. To me, the (neural) map has blots that most people will 
easily read in the GIMP 2.10 interface as easily recognizable information.

The app manager in Mint 20 will only install GIMP 2.10 -- and 
 has only a button for a flatpack of GIMP 2.10

GIMP 2.8 is available to install from the app manager in Mint 18.

For now, I can boot a drive that's fully set up in Mint 18 with GIMP 2.8. I can 
use that for as long as it hasn't gotten corrupted on my computer. I can do a 
fresh install of Mint 18 for as long as that version is supported. I'd like to 
get ahead on having a fresh OS install. Becoming cognizant of GIMP 2.10 would 
be a big delay. At my age, that's real iffy.

I've been doing okay with Mint 20 -- having spent weeks making the Cinnamon 
version appear as much like Mint 18 Cinnamon as possible.

Which will hold on longer -- Mint 18/GIMP 2.8 or me? Should I spend that time 
mapping-out a new territory or do I get to keep working along the road that has 
what I need to recognize where I am?

Legacy is something that app developers have a long harsh history of overlooking. 
(Among others, I once worked closely with Apple Newton developers, for instance. 
 May Steve rest in peace.) Viable available legacy is important. We're 
all legacy, sooner or later.


On Fri, Sep 4, 2020 at 3:03 PM Alexandre Prokoudine 
 wrote:


On Sat, Sep 5, 2020 at 1:00 AM Kenny Mann wrote:


Why is GIMP 2.8.16 not available?


Source code: 

Re: [Gimp-user] Downloading Images from Internet

[Elle Stone]

On 06/26/2019 10:34 AM, scyr123 wrote:

I use Windows 10.  Recently updated to GIMP 2.10.12.  I search for an image
online, then use right mouse click to get to "Save Image As" option.  When I
select this option, the window pops up for me to name the file, but the only
"Save As Type" option I get is GIMP 2.10.12.  I no longer see options of .jpg,
.png, etc.  I have no idea where the setting might be to change the option so I
can save these files in other formats.  I don't want every file to be saved for
use in GIMP.  Any assistance is greatly appreciated.  Image attached to show
issue.

Attachments:
* 
https://www.gimpusers.com/system/attachments/1202/original/GIMP_Issue_Screen_Shot.png



Instead of "Save", try "Export". GIMP "Save" only allows to save as an 
XCF file. "Export" allows to "export" to disk png, jpeg, tiff, etc.


Best,
Elle

--
https://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Disable image thunbnail from the title bar

[Elle Stone]

On 06/20/2019 12:02 PM, sudipto wrote:

No way that I know of. You will have to go and request as a feature
here:

https://gitlab.gnome.org/GNOME/gimp/issues/

Otherwise, you can see and switch to  what is there in the Windows
menu. Also the alt-number swaps between open images as wll.


Thanks, I will request the feature in the gimp gitlab



There is a fairly long discussion on the gimp-gui mailing list 
(https://mail.gnome.org/mailman/listinfo/gimp-gui-list) of just this 
request. The thread is here - second topic down - see #6 in the 
reference image:


thread: 
https://mail.gnome.org/archives/gimp-gui-list/2017-December/thread.html


reference image: 
https://ninedegreesbelow.com/files/possible-places-to-save-vertical-space-in-single-window-mode.png


Best,
Elle Stone




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

Re: [Gimp-user] Gimp Plugins

[Elle Stone]

On 06/09/2019 05:45 PM, Carusoswi wrote:


So, I checkded all my GIMP menus and found nothing about Lens Fun, for example.
Nothing about G’MIC, either, so I must be doing something wrong.



Yesterday I downloaded the Linux GIMP g'mic plugin from this page:

https://gmic.eu/download.shtml

and put it in my GIMP-2.10 config folder, in the plug-ins sub-folder, 
and it runs just fine, shows up in GIMP-2.10 under the Filters menu.


I build GIMP in a prefix, and my config folder is also in the prefix. My 
apologies, I don't know where the config folder is located for 
installing GIMP directly from a repository. But once you've located the 
"plug-ins" folder, put the downloaded G'MIC-qt in that folder, and 
restart GIMP.


I don't know about Lens Fun.

Best,
and hope this helps,
Elle

--
https://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Can't browse directories in GIMP 2.10

[Elle Stone]

Is this bug report relevant? If so, the fix might be in glib 2.56.2.

https://github.com/Alexpux/MINGW-packages/issues/3584
Since last updates gtk filechooser appears broken.

Steps:

run gedit
Open -> Other documents ...
Dialog shows, try to change drive to "Label (D:)"
No content to bowse


On 05/12/2018 10:14 AM, Partha Bagchi wrote:

This is a problem with glib. You have to downgrade to 2.53.1 I had to do
that when I ran into this problem with RC2.

On Sat, May 12, 2018 at 10:11 AM Poptop <for...@gimpusers.com> wrote:


Although Gimp 2.10 uninstalls Gimp 2.8 there are parts left behind.
The Gimp 2.8 profile remains and if any third-party plugins/add-ons
were added in the past to the main Gimp 2.8 installation, they will
remain.

What you can try is:

1. Use the windows uninstaller to uninstall Gimp 2.10

2. If any of C:\Program Files\GIMP 2\ remains delete it.

3. Disable the Gimp 2.8 profile, rename or move out to a backup
folder.

4. Now install Gimp 2.10, run it to make a default Gimp 2.10 profile.

If that does not work then consider a different Gimp 2.10 package,
maybe the one from www.partha.com


I'm having the same problem.  I did  a clean install of Gimp 2.10 and
deleted
the previous 2.8 install directory before the new installation.  When I
click on
my different hard drives and directories in the Save As dialog the only
files or
folders shown are in Pictures, Documents and the current User directory,
all of
the hard drives show blank and I cannot navigate them.  It's hard to
imagine
that one would need to install a different package other than the official
Gimp
one to get something as simple as save directories to show up when trying
to
save.  Any help would be appreciated, thank you.

Attachments:
* http://www.gimpusers.com/system/attachments/908/original/Untitled1.jpg

--
Poptop (via www.gimpusers.com/forums)
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list


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




--
Elle Stone
https://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] [Gimp-developer] Curious about GIMP-2.10 bugs on Windows

[Elle Stone]

On 05/11/2018 10:36 AM, Tom Williams wrote:

On 05/11/2018 07:24 AM, Elle Stone wrote:



I have no clue whether more people use GIMP on Windows than on Linux.
But either way my questions remain:

Are most of these "post release of 2.10" bug reports specific to GIMP
on Windows? or do they also affect GIMP on Linux?

Was there such an influx of Windows(-only?) bug reports for 2.8,
compared to 2.10?



My initial reaction to the GIMP 2.10 bugs on Windows vs Linux is:  have
many Linux distros started offering GIMP 2.10 as an upgrade/update?   I
run Mint 18.3, on my laptop, and GIMP 2.10 isn't available as an update,
yet.  I don't have the time to try updating GIMP manually, so I wait for
the distribution to update the software for me.  Now that I think about
it, my mom's Ubuntu 16.04 system hasn't received a GIMP 2.10 update either.

Maybe as the distros start making GIMP 2.10 available, more Linux users
will use it.  I'm just thinking out loud.  :)


OK, that makes sense. Maybe a flood of bug reports from Linux users will 
come in when/as GIMP-2.10 is included in more Linux distributions.


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

Re: [Gimp-user] [Gimp-developer] Curious about GIMP-2.10 bugs on Windows

[Elle Stone]

On 05/11/2018 10:35 AM, Kevin Payne wrote:

On 05/11/2018 09:06 AM, Elle Stone wrote:


Are some/many/most of the problems being reported for GIMP-2.10 on
Windows, only specific to Windows?

Or are these bug reports by Windows users simply bugs that weren't
detected by various people running GIMP-2.9/GIMP-2.10-rc/GIMP-2.10 on
Linux?


I'd suggest that one of the reasons is the relative lack of availability of 
executables during the 2.9 development 
phase<https://mail.gnome.org/archives/gimp-user-list> - self compilation not 
really being an option on Windows.




That would explain a lot. Though people do manage to compile GIMP on 
Windows, it's apparently not easy to do.


Partha's 2.9/2.10 builds for Windows have been available for a long time 
(https://www.partha.com/), without giving rise to nearly so many bug 
reports as the official release of 2.10. But maybe most Windows users 
don't know about Partha's builds.


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

Re: [Gimp-user] [Gimp-developer] Curious about GIMP-2.10 bugs on Windows

[Elle Stone]

On 05/11/2018 09:06 AM, Elle Stone wrote:

Are some/many/most of the problems being reported for GIMP-2.10 on 
Windows, only specific to Windows?


Or are these bug reports by Windows users simply bugs that weren't 
detected by various people running GIMP-2.9/GIMP-2.10-rc/GIMP-2.10 on 
Linux?


Someone sent me a private email in response to my list post, suggesting 
that more people use Windows, than use GIMP (I don't know if that person 
actually intended to send a private email or not, so I'm not quoting).


I have no clue whether more people use GIMP on Windows than on Linux. 
But either way my questions remain:


Are most of these "post release of 2.10" bug reports specific to GIMP on 
Windows? or do they also affect GIMP on Linux?


Was there such an influx of Windows(-only?) bug reports for 2.8, 
compared to 2.10?


Best regards,

--
Elle Stone
https://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

[Gimp-user] Curious about GIMP-2.10 bugs on Windows

[Elle Stone]

Before the release of GIMP-2.10, it seems to me that very few bug 
reports were filed for GIMP-2.9/2.10 that were specific to Windows.


Are some/many/most of the problems being reported for GIMP-2.10 on 
Windows, only specific to Windows?


Or are these bug reports by Windows users simply bugs that weren't 
detected by various people running GIMP-2.9/GIMP-2.10-rc/GIMP-2.10 on Linux?


Context of these questions:

Well, mostly I'm just curious. A couple of years ago I subscribed to 
GIMP bug reports, so I've seen all the bugs filed for GIMP-2.9/GIMP-2.10 
for the last couple of years. And since the release of 2.10, it seems 
like almost all the new bug reports are from Windows users.


I didn't see all the bugs filed for GIMP-2.8, neither before nor after 
the initial release of GIMP-2.8. When GIMP-2.8 was released, were there 
as many problems with GIMP-2.8 on Windows, as there are with the release 
of GIMP-2.10?


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

Re: [Gimp-user] Debugging Perf on Linux

[Elle Stone]

On 03/28/2018 12:16 AM, Robert Bieber wrote:
Thanks for that Elle, I followed up personally about the profiles. Going 
back to the list, one thing I should add is that currently for my 
workflow on the same machine I'm using Gimp 2.8 with the same sized 
images, same monitor profiles, and it works more or less okay.  I 
wouldn't say it's _fast_, and it gets a little crashy sometimes, but I 
think it's doing a pretty decent job for a single-threaded program 
processing buffers this big. It's miles faster than the 2.9 RC, so I'm 
guessing there's probably something other than that going on


Hi Robert,

Checking the icc profiles, they are all matrix profiles, so the profiles 
aren't the source of the problem.


From curiosity, is 2.8 also faster on the other machine (the one that's 
OK for 2.10)?

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

Re: [Gimp-user] Debugging Perf on Linux

[Elle Stone]

On 03/27/2018 09:35 PM, Robert Bieber wrote:


How would I tell?  I just generated my monitor profiles with Ubuntu's 
color management control panel section: I'm still not as much of a 
power-user in that area as I'd like to be


So is there any chance that your monitor profile at home is a LUT 
profile? What about the image's assigned profile - was it possibly a 
LUT profile? And/or was soft proofing somehow activated?


Hmm, well, probably the easiest way is to send me a private email with 
your monitor profile attached, and perhaps export a very small jpeg of 
the image you were working on, with the image profile embedded, and I'll 
look at them.


If you are interested in learning more about color management, perhaps 
starting with "how to tell what kind of profile it is, LUT or matrix", 
probably the best thing to do is start a thread on the pixls.us forum.


If you want, you can catch my attention on the pixls.us forum by 
mentioning @elle, but quite a few people there can help with figuring 
out what kind of profiles you are using, and maybe some of them even use 
Ubuntu's color management control panel (I don't).


I'm about to shut down the computer for the evening, so might not see 
your profiles (if you send them) until morning.


Best,
Elle

--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Debugging Perf on Linux

[Elle Stone]

On 03/27/2018 09:11 PM, Robert Bieber wrote:
I assume this has to be a bug, since I'm running the same software and 
getting the exact opposite of the results I'd expect running it on 
different machines, but what can I do to diagnose it and get some data 
that might help resolve it?  The error console isn't showing anything, 
here's what I get in my terminal when opening an image and running 
wavelet decompose, if that helps at all: https://pastebin.com/TCEgYqPr


Seeing color management stuff in the console did make me think to try 
turning color management off, which did make basic image operations run 
faster, but wavelet decompose is still running intolerably slow.  And of 
course retouching with color management disabled isn't an ideal 
long-term solution.  Any ideas?


I looked at the pastebin file, nothing looked out of the ordinary - I 
see similar terminal output. But maybe someone else will spot something.


Earlier today I was doing some soft proofing, switching profiles back 
and forth. At one point I clicked the wrong field in Preferences without 
noticing, so accidently selected the printer profile as the monitor 
profile instead of the soft proofing profile.


GIMP slows down to a crawl when using a LUT monitor profile (even if 
it's really a monitor profile instead of an accidentally selected 
printer profile).


So is there any chance that your monitor profile at home is a LUT 
profile? What about the image's assigned profile - was it possibly a LUT 
profile? And/or was soft proofing somehow activated?


Also, try operating at 32f instead of 16i, which will eliminate some 
internal precision changes. And try disabling opencl and setting the 
number of threads to "1".


Best,
Elle

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

Re: [Gimp-user] [Gimp-developer] ANNOUNCE: GIMP 2.10.0-RC1 released

[Elle Stone]

On 03/26/2018 08:02 PM, Michael Natterer wrote:


There is also a release announcement onwww.gimp.org
with screenshots of new features:

https://gimp.org/news/2018/03/26/gimp-2-10-rc1-released/


At least on my computer, above link leads to 404 page.

This link works:

https://www.gimp.org/news/2018/03/26/gimp-2-10-0-rc1-released/

Oh, and yeah! 2.10 release candidate!

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

Re: [Gimp-user] Any way to resize all the layers in an xcf file to fit the canvas?

[Elle Stone]

Hmm, in GIMP-2.9, in Preferences, under "Dialog Defaults", there is an 
option to always resize all the layers to the canvas size.


Well, that would solve the problem of resizing the layers to fit the 
canvas, at least if the canvas is larger than and includes all the 
content of all the layers. But sometimes layers are offset from the 
canvas, and have content outside the canvas.


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

Re: [Gimp-user] Any way to resize all the layers in an xcf file to fit the canvas?

[Elle Stone]

On 03/11/2018 12:06 PM, Carol Spears wrote:

It is much much easier to resize the canvas to fit all of the layers.

All the layers are different sizes, so I don't think this would work, 
would it? Unless you mean what Ofnuts described, resizing by a pixel, 
and then resizing again to return to the original canvas size. I never 
would have thought of that trick.





Also, does the layer mask resize when the layer is resized?


I just tried this and it does.  You can try this also, Edit -->Undo is a
friend


Thanks! for checking. Actually I did try, but I couldn't tell what was 
happening. I should have spent more time experimenting to determine what 
was really happening.


On 03/11/2018 05:41 PM, Ofnuts wrote:


My trick for this (on 2.8):

- Image>Canvas size and add 1 px, and select "resize all layers"

- Image>Canvas size and remove 1 px, and select "resize all layers"

Otherwise, in the python console:

    image=image=gimp.image_list()[0] # or other ways to obtain image

    for layer in image.layers: layer.resize_to_image_size()

(strike [enter] twice)


Since I have sen this question asked many times, I made a short script 
out of it:


See ofn-layers-to-image-size at 
https://sourceforge.net/projects/gimp-tools/files/scripts/


Hi Ofnuts,

Thanks much! for the trick and the script. Hopefully I won't be resizing 
this particular image any further, but the next time I resize an image 
I'll figure out how to use the script, or at least will use the trick.


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

[Gimp-user] Any way to resize all the layers in an xcf file to fit the canvas?

[Elle Stone]

Hi All,

Of course all the layers can be resized one by one to fit the canvas. 
But I've been doing a *lot* of rearranging/moving of different groups of 
layers, and clicking on each layer one by one to resize it is rather 
time-consuming and involves a lot of clicking. Right now that's 17 
layers and four groups.


Is there a magic command, or maybe an easy script that can be run to 
resize all the layers to fit the canvas, all at once?


Also, does the layer mask resize when the layer is resized?

In case it matters, I'm using GIMP 2.9.8 on Linux.

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

Re: [Gimp-user] Image luminosity

[Elle Stone]

On 03/10/2018 03:55 AM, Ofnuts wrote:

On 03/07/18 15:10, WMusc wrote:

Something like:

Color>Desaturate (luminosity) and check the average or median in the
Histogram dialog.
Thanks for the tip. Do you know whether that approach provides the 
mean (median,
etc.) luminosity value before or after desaturation? It looks to apply 
the
effect so it's unclear to me. If the program applies it uniformly 
across all
images I may be able to use it as a proxy for luminosity but would 
like to avoid

that if possible.

I expect Color>Desaturate>Luminosity to not change the luminosity of the 
pixel. The grey value after is normally the luminosity you would have 
computed from the RGB components you have in the initial image.


This said, in 2018 I'm surprised you are engaging in such manual labor. 
Find someone (intern?) to write a small program that will extract all 
these data directly from the image files and create a spreadsheet with 
the results.


Before finding an intern to write a program, it might be a good idea to 
figure out whether the metrics you've decided to extract are actually 
useful to the task at hand. Garbage in/garbage out, as I've been trying 
to say over in the pixls.us thread on this topic:

https://discuss.pixls.us/t/image-luminosity/6904

As far as extracting information from an image, ImageMagick might be a 
better choice than GIMP - more available metrics, though again it's an 
open question as to whether any of the metrics actually help you decide 
whether an image is "too this" or "not enough that". Remember the red 
square in the middle of an otherwise solid gray image that I posted to 
the pixls.us thread - the relative luminance of the red square is 
exactly the same as the relative luminance of the background, but I'm 
fairly sure just about everyone will say the red square is "brighter", 
as indeed it according to the definition of "brightness" used in current 
color appearance models.



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

Re: [Gimp-user] Photoshop FYI

[Elle Stone]

On 12/10/2017 04:20 PM, Steve Kinney wrote:



On 12/08/2017 11:00 AM, Amira_Cervantes wrote:

Chromebook photoshop cloud soon.  Photoshop in Chrome Ubuntu next
year.


Adobe Photoshop Is also Coming To Linux, Through Chromebooks ... sounds great!


I'm sure its parents are very proud.


Its parents should be ashamed:

Google:


http://www.zdnet.com/article/google-invading-student-privacy-with-chromebooks-eff/


http://news.softpedia.com/news/eff-says-google-chromebooks-are-still-spying-on-students-515015.shtml

Adobe:

Adobe Creative Cloud: Lopsided Legal Agreement
https://macperformanceguide.com/blog/2013/20130508_1a-Adobe-legal-agreement.html

What happens to my work when I cancel my subscription?
https://forums.adobe.com/thread/1206477?start=0=0


Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Gimp channel mixer

[Elle Stone]

On 10/30/2017 06:36 AM, rich404 wrote:

Otherwise the two applications that Gimp recognises by default and will use, are
Rawtherapee and Darktable.


And PhotoFlow, and any other raw processor that chooses to provide a 
plug-in using the same sort of plug-in code that RawTherapee, darktable, 
and PhotoFlow provide.


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

Re: [Gimp-user] Compatibility with PS?

[Elle Stone]

On 10/29/2017 06:06 PM, Jeffry Killen wrote:


Will Gimp open ps files: yes (which versions and what aspects are retained?)


I don't know which versions of PSD files GIMP can open. I do have some 
old CS2 PSD files that I recently spent some time opening with GIMP, 
after having not looked at them for many years.


I use GIMP 2.9, which is the development version of GIMP. Recently there 
have been quite a few new commits to the GIMP code that affect reading 
PhotoShop files. So the following observations are based on GIMP 2.9 and 
PhotoShop CS2. Hopefully someone else will chime in if I made mistakes 
in my observations or left out something important:


You will not be able to open a PSD file and continue editing "just as 
if" you were still using PhotoShop.


GIMP doesn't yet have adjustment layers (Curves, Levels, etc). Even if 
GIMP already did have adjustment layers, that doesn't mean GIMP would be 
able to interpret PhotoShop adjustment layers.


The only actual layers that GIMP can show when you open a PSD file are 
image layers, not adjustment layers. So if your PSD file has one image 
layer at the bottom, and a whole bunch of adjustment layers, then the 
only thing GIMP will retain when you open the PSD file is the image 
layer at the bottom.


So if your computer on which PhotoShop is installed is on the verge of 
not working any more, it might be a good idea to open your most 
important PSD files and use the equivalent of GIMP's "make new from 
visible" to have a record of the result of intermediate editing steps 
that involved adjustment layers.


Also, if you want to use DAM software such as digiKam and you want to 
see a thumbnail for your PSD files, save your PSD files using 
compatibility mode. Back when I used PhotoShop, at some point I stopped 
using compatibility mode and now I have a lot of PSD files for which 
digiKam and Gwenview can't show thumbnails. Again, this is for CS2 - I 
don't have a clue whether CS4 even has compatibility mode.


GIMP doesn't have the ability to play PSD macros (I hope I'm remembering 
the right word). So if your workflow depends heavily on macros, well, 
you can learn to script in GIMP, but there will be a steep learning curve.


GIMP doesn't yet support opening, editing, and saving images in the LAB 
or CMYK color spaces. So if you have any important LAB or CMYK PSD 
files, it might be a good idea while your computer is still running to 
save a copy of these files after converting them to RGB.


Many of the layer blend modes are the same in GIMP and PhotoShop, and 
many are not.


CS2 is pre "smart layer" - is that the right word? so if you used that 
functionality, maybe someone else knows if/how GIMP interprets these 
types of layers. But again, for your important PSD files it would be a 
good idea to use the PS equivalent of "make new from visible" to have a 
record in the PSD file of what the smart layer was supposed to do.


If you find that you simply don't want to edit images without using 
adjustment layers, Krita might work for you better than GIMP. Even 
though Krita is primarily aimed at painting rather than photography, 
people do use Krita for editing photographs. I'm not sure how good 
Krita's support for PSD is. I tried opening a couple of files with Krita 
and the only layer that "survived" was the bottom layer, but I think 
this might be because of some system issues I'm having with KDE image 
file format support.


GIMP is not "free PhotoShop" and your best bet is to approach GIMP for 
what it is, on its own terms. Personally I much prefer GIMP 2.9 over 
PhotoShop CS2. I never used GIMP 2.8 except to prepare files for 
uploading to the web, because 2.8 doesn't support high bit depth editing.


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

Re: [Gimp-user] Is a high bit depth monitor worth getting? (was Re: emerge --emptytree : how to ?)

[Elle Stone]

On 10/20/2017 12:30 PM, Kevin Cozens wrote:
GIMP is moving towards higher colour depth. Would a high bit depth 
monitor be worth it? That would depend on your use case(s). Is GIMP the 
only program you would run that would benefit from a high bit depth 
monitor? Do you run other programs that would benefit from such a 
monitor? Will your computers graphical environment (aka. desktop) 
support full use of a high bit depth monitor?


GIMP 2.9/2.10 does process images at 32-bit floating point. But at this 
point the GIMP code that sends the image to the screen for display works 
at 8-bit integer, using "CAIRO_FORMAT_ARGB32".


Cairo does provide "CAIRO_FORMAT_RGB30  -> like RGB24 but with 10bpc. 
(Since 1.12)".


Which if any editing programs use CAIRO_FORMAT_RGB30? How would it 
impact performance if GIMP started using CAIRO_FORMAT_RGB30?


There's an open darktable issue on the topic:
https://redmine.darktable.org/issues/10197

Over on the ArgyllCMS mailing list is a nice discussion of 30-bit 
displays, distinguishing between calibration and profiling: 
https://www.freelists.org/post/argyllcms/Argyll-and-30bit-colors,3


Not every free/libre image editor uses cairo to send images to the 
screen. Can Krita make use of 10-bit monitor displays, using whatever it 
is that qt apps use?


Will cairo still be used if/once Linux switches over to Wayland?

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

Re: [Gimp-user] Adding color to file

[Elle Stone]

On 10/06/2017 12:39 AM, Guy Stalnaker wrote:

I'd like to suggest an alternative method for coloring an image that has
some great advantages.

Use layers with masks!




5. Add new layer
   1. Fill with a color you want for some part of your image
   2. Give layer name (e.g., face, jacket, etc.)
   3. Set the Mode to Soft light, or some other appropriate Mode (in the
   example Soft Light lets the background show through)




Hope this is as helpful for you, if you have not used this technique
before, as it was, and has been, to me.


I agree with Guy, this approach - which he describes perfectly - is a 
wonderful way to add color to an image. Soft light is a good blend mode, 
probably the best for GIMP 2.8, and useful in any image editor.


If you have access to GIMP-2.9 (preferably GIMP-2.9.6), there are some 
new blend modes, specifically the LCH blend modes, which I use (a lot) 
for coloring/recoloring black and white images. If you might be 
interested, I wrote up an introductory tutorial which has a simple 
example of adding color in Part C: 
https://ninedegreesbelow.com/photography/gimp-lch-blend-modes.html


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

Re: [Gimp-user] Liquid scaler

[Elle Stone]

On 03/26/2017 06:27 PM, Alexandre Prokoudine wrote:

Liquid Rescale is not part of the GIMP project, it's a plugin made by a
third party. We don't have a new download for you, only what you can find
at http://liquidrescale.wikidot.com.



Liquid rescale plug-in is packaged along with GIMP 2.9 in a couple of 
the community builds: 
https://discuss.pixls.us/t/community-built-software/2137.


But as Alex said, liquid rescale is a third party plug-in and isn't part 
of the GIMP project. "Packaged with" doesn't mean "part of".


I haven't tested the liquid rescale plug-in lately, so can't verify how 
well it's currently working.


Best,
Elle

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

Re: [Gimp-user] GIMP 2.9.5 Erase

[Elle Stone]

On 02/18/2017 01:26 PM, programmer_ceds wrote:

One other piece of information - I have just found if the erased path crosses
itself (without releasing the mouse button) the intersection stays erased - for
example if a figure 8 is drawn in one operation the problem doesn't appear.

I don't see the same thing on the same PC (running W7 64-bit) using V2.8.20.


Am I missing something obvious here?

I create a new image, use bucket fill to fill it with the background
colour (not white, although the 'problem' still occurs with white) and
add an alpha channel to the layer.

I then select the eraser tool and erase a strip of the image - this
works fine and I see the chequered/transparent background as expected.

If I then erase another strip that in part crosses the first strip the
intersection of the strips becomes white.

Erasing the intersection again toggles it back to being transparent..

I have tried adjusting various controls for the eraser tool without
success (I consider success to be that the intersection of the two
strips remains erased).

I am using GIMP V2.9.5 commit 7111ead (the portable Windows version
from Partha's site posted 12.2.2017 (many thanks to Partha for posting
these versions))




Probably this bug, which has been fixed in git:
https://bugzilla.gnome.org/show_bug.cgi?id=778597

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

Re: [Gimp-user] Weird forum and layout

[Elle Stone]

On 02/12/2017 01:02 AM, Joel Rees wrote:

On Sat, Feb 11, 2017 at 11:46 PM, Elle Stone
<ellest...@ninedegreesbelow.com> wrote:

[...]
Does anyone have any possible explanations for why different people with a
background using PhotoShop have such wildly diverse reactions to the GIMP
and Krita User Interfaces?


version of Photoshop? OS platform?


Good point -whether a user thinks Krita or GIMP is "more like PhotoShop" 
might depend on which version of Photoshop they've used. I'm only 
familiar with one version of PhotoShop, and that's CS2 on Windows. Maybe 
PhotoShop on Mac has a substantially different UI, and maybe CC looks 
substantially different than CS2.




in addition to user preferences, as you mention.


I'm wondering if people's reactions are linked to GIMP's default
Multi-Window Mode vs Krita's default Single-Window Mode.


in some cases, probably.


I always had PhotoShop configured with the main window as small as possible,
and with a lot of free-floating dockers. So to me GIMP's default
Multi-Window Mode is very comfortable to use (and I don't like Single Window
Mode at all).


Users have a tendency to think the subsection of the UI that they use
most is the app.



Another good point. On Photoshop I only ever edited photographs, mostly 
starting from a raw file, and never tried to paint using PhotoShop. 
Maybe Krita's paint tools resemble PhotoShop's paint tools.


Elle

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

Re: [Gimp-user] Weird forum and layout

[Elle Stone]

On 02/11/2017 09:05 AM, Pat David wrote:

This is not a forum, it's a bridge to a traditional mailing list that can
be found here:

https://mail.gnome.org/mailman/listinfo/gimp-user-list

Or you can use the archives to see threaded conversations:

https://mail.gnome.org/archives/gimp-user-list


Pat, do you know who actually owns/runs gimpusers.com? There doesn't 
seem to be an "about" link anywhere (or else I missed it). Same question 
and comment applies to gimpchat.com - I don't see an "about" link.


It would be nice if these (and similar) sites would supply a little 
clarifying information including a statement about their official or 
unofficial relationship with GIMP.


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

Re: [Gimp-user] Weird forum and layout

[Elle Stone]

On 02/11/2017 08:58 AM, Boxman wrote:

Like GIMP itself, I don't understand why the developers would want
to create something so different from what we are familiar with, and have
invested huge amounts of time learning, so that to use GIMP we now have to
relearn everything we  thought we knew.


I used PhotoShop for several years. When I switched to Linux and started 
using GIMP, to me the GIMP UI seemed "just like PhotoShop".


I've heard people say that the Krita UI seems "just like PhotoShop". 
Personally I disagree - I do use Krita as well as GIMP, but it was a 
long rocky road to get used to the Krita interface.


I know a few other people who think the Krita UI is very different from 
the PhotoShop UI. These same people think the GIMP UI is very similar to 
the PhotoShop UI.


Does anyone have any possible explanations for why different people with 
a background using PhotoShop have such wildly diverse reactions to the 
GIMP and Krita User Interfaces?


I'm wondering if people's reactions are linked to GIMP's default 
Multi-Window Mode vs Krita's default Single-Window Mode.


I always had PhotoShop configured with the main window as small as 
possible, and with a lot of free-floating dockers. So to me GIMP's 
default Multi-Window Mode is very comfortable to use (and I don't like 
Single Window Mode at all).


Elle



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

Re: [Gimp-user] color profiles and gimp-image-convert-color-profile

[Elle Stone]

On 01/21/2017 07:34 PM, Partha Bagchi wrote:

On Sat, Jan 21, 2017 at 7:22 PM, Alexandre Prokoudine <
alexandre.prokoud...@gmail.com> wrote:


On Wed, Dec 21, 2016 at 4:28 AM, Carol Spears wrote:

I read something recently about a color profile from 1966.  It made me
chuckle and think about early US-tv and dramatic books of black and
white photography.


I think the "color profile from 1966" is actually a reference to sRGB, 
which was created in 1996 and "standardized by the IEC as IEC 
61966-2-1:1999" to quote Wikipedia (https://en.wikipedia.org/wiki/SRGB).


As far as I know, there weren't any color profiles as we know them today 
before the ICC was established, which wasn't until 1993 
(http://www.color.org/abouticc.xalter).



Then, gimp-9 or 10 was released and I am going to have to reacquaint
myself with some words or learn about them for the first time before I
am going to be able to convert rgb to grayscale via any script
available.
Any body got a link or a book recommendation or a paper to read?


"Real World Color Management" by the late Bruce Fraser et al. is quite
good.

Alex


Real Wold Color Management is a great book and everyone should read it.


I would also recommend Elle Stone's website http://ninedegreesbelow.com/
which has a wealth of information about color management and more
specifically as it relates to GIMP.


The first section on this page has links to introductory tutorials in a 
suggested "order of reading": 
http://ninedegreesbelow.com/photography/articles.html#icc-profile-color-management-tutorials


As Partha notes, there are also some articles specifically about GIMP 
color management in the section on high bit depth GIMP.


But neither my articles nor Real World Color Management will have any 
suggestions for a script for converting from RGB to Grayscale.


Best,
Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] color management -- basic question

[Elle Stone]

On 01/12/2017 01:12 PM, Elle Stone wrote:

On 01/11/2017 02:00 PM, Casey Connor wrote:

Ok, thanks -- I was just confused because you said "LCMS soft proofing
will report that all the colors are in gamut" but when I soft proofed to
that profile it showed lots of colors that are out of gamut... this link
<https://sourceforge.net/p/lcms/mailman/message/35271294/> makes me
think it's just more complicated than that, so I won't worry about it.


No, my apologies, you are right, you will see out of gamut colors
indicated in the test situation you describe. I was trying too hard to
not cover a lot of cases in detail. To try to summarize the relevant
details:

1. If you are editing at integer precision (8-bit integer, 16-bit
integer, etc)

2. and the TRC of the source image ICC profile is reasonably close to
being perceptually uniform

3a. and the image color gamut completely encompasses the soft proofing
profile color gamut, or else 3b. if the soft proofing profile doesn't
support unbounded ICC profile conversions,

* then the gamut check will be reasonably accurate.



Above is true.

Below is wrong:


So for example let's say you assign "Rec2020-elle-V4-labl.trc" to one of
those very nice "all colors" images,  and you've chosen
"sRGB-elle-V4-srgbtrc.icc" as the soft proofing profile. The gamut
checks will be accurate.

Now assign Rec2020-elle-V4-srgbtrc.icc to the source image. The gamut
checks will still be very, very close to accurate.

Now assign Rec2020-elle-V4-g18.icc to the source image. The gamut checks
won't be quite as accurate. Gamma=1.8 is the standard TRC for
ProPhotoRGB color space.

Now assign Rec2020-elle-V4-g10.icc to the source image. The gamut checks
will be completely inaccurate.

The appearance of the image will keep changing as you assign the
different profiles - in fact getting lighter and lighter as the TRC gets
closer to gamma=1.0. But the thing to pay attention to is the gamut
checks. It helps to have the gamut check color set to magenta so the
gamut check areas stand out from the image colors.

Assuming conditions 1 and 3a or 3b, then most accurate gamut check is
when the TRC is the labl trc, but the sRGB trc is also pretty accurate.
Both of these TRCs are close to gamma=2.2, and profiles such as
AdobeRGB1998 (which has the gamma=2.2 TRC) will also show an accurate
gamut check.



Below is true:


If you change the precision to high bit depth floating point precision,
and/or if the source color gamut doesn't entirely encompass the soft
proofing profile color gamut, and/or if the soft proofing profile
supports unbounded ICC profile conversions, then a whole other set of
LCMS soft proofing issues comes into play. For example, assign
sRGB-elle-V4-srgbtrc.icc to the "all colors" test image. Change the
precision to 32-bit floating point. Do "Colors/Saturation" and set the
slider to 2. Now almost all the colors are exceedingly out of gamut with
respect to the sRGB color space. And yet the gamut checks will have
disappeared.

As an added complication, what you see partly depends on what version of
LCMS2 is installed, but I'm not sure if the first relevant change came
before or after LCMS 2.7, which is the minimum version of LCMS2 that
will work when compiling GIMP 2.9.




And my apologies for the confusion!

Elle

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

Re: [Gimp-user] color management -- basic question

[Elle Stone]

On 01/12/2017 01:12 PM, Elle Stone wrote:

No, my apologies, you are right, you will see out of gamut colors
indicated in the test situation you describe. I was trying too hard to
not cover a lot of cases in detail. To try to summarize the relevant
details:


No, drat, I still got some of the details wrong. I'll correct them in a 
later email.


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

Re: [Gimp-user] color management -- basic question

[Elle Stone]

On 01/11/2017 02:00 PM, Casey Connor wrote:

Ok, thanks -- I was just confused because you said "LCMS soft proofing
will report that all the colors are in gamut" but when I soft proofed to
that profile it showed lots of colors that are out of gamut... this link
 makes me
think it's just more complicated than that, so I won't worry about it.


No, my apologies, you are right, you will see out of gamut colors 
indicated in the test situation you describe. I was trying too hard to 
not cover a lot of cases in detail. To try to summarize the relevant 
details:


1. If you are editing at integer precision (8-bit integer, 16-bit 
integer, etc)


2. and the TRC of the source image ICC profile is reasonably close to 
being perceptually uniform


3a. and the image color gamut completely encompasses the soft proofing 
profile color gamut, or else 3b. if the soft proofing profile doesn't 
support unbounded ICC profile conversions,


* then the gamut check will be reasonably accurate.

So for example let's say you assign "Rec2020-elle-V4-labl.trc" to one of 
those very nice "all colors" images,  and you've chosen 
"sRGB-elle-V4-srgbtrc.icc" as the soft proofing profile. The gamut 
checks will be accurate.


Now assign Rec2020-elle-V4-srgbtrc.icc to the source image. The gamut 
checks will still be very, very close to accurate.


Now assign Rec2020-elle-V4-g18.icc to the source image. The gamut checks 
won't be quite as accurate. Gamma=1.8 is the standard TRC for 
ProPhotoRGB color space.


Now assign Rec2020-elle-V4-g10.icc to the source image. The gamut checks 
will be completely inaccurate.


The appearance of the image will keep changing as you assign the 
different profiles - in fact getting lighter and lighter as the TRC gets 
closer to gamma=1.0. But the thing to pay attention to is the gamut 
checks. It helps to have the gamut check color set to magenta so the 
gamut check areas stand out from the image colors.


Assuming conditions 1 and 3a or 3b, then most accurate gamut check is 
when the TRC is the labl trc, but the sRGB trc is also pretty accurate. 
Both of these TRCs are close to gamma=2.2, and profiles such as 
AdobeRGB1998 (which has the gamma=2.2 TRC) will also show an accurate 
gamut check.


If you change the precision to high bit depth floating point precision, 
and/or if the source color gamut doesn't entirely encompass the soft 
proofing profile color gamut, and/or if the soft proofing profile 
supports unbounded ICC profile conversions, then a whole other set of 
LCMS soft proofing issues comes into play. For example, assign 
sRGB-elle-V4-srgbtrc.icc to the "all colors" test image. Change the 
precision to 32-bit floating point. Do "Colors/Saturation" and set the 
slider to 2. Now almost all the colors are exceedingly out of gamut with 
respect to the sRGB color space. And yet the gamut checks will have 
disappeared.


As an added complication, what you see partly depends on what version of 
LCMS2 is installed, but I'm not sure if the first relevant change came 
before or after LCMS 2.7, which is the minimum version of LCMS2 that 
will work when compiling GIMP 2.9.


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

Re: [Gimp-user] color management -- basic question

[Elle Stone]

On 01/10/2017 05:44 PM, Casey Connor wrote:


I had planned to use
Argyll/displaycal, and make a matrix profile per your suggestions. I
think I read on your site that a LUT version would also be handy also
for using occasional perceptual rendering intent to get a feel for all
the detail in an image?


Yes, but depending on your monitor, normally it's better to not use the 
LUT profile for actual editing. And if you do use the LUT profile when 
editing, use relative colorimetric intent to convert to the monitor 
profile. Use perceptual intent for exploration, but not for editing, 
unless you know exactly what you are doing and why.


Truthfully I've only used my LUT monitor profile a couple of times to 
explore what might be hiding in the portions of an image that are 
clipped by a relative colorimetric conversion - in one image I was very 
surprised to see a whole lot of unexpected detail in areas that looked 
like there wasn't any detail at all.



So currently trying to soft proof to the built-in GIMP sRGB profile is
a waste of time as LCMS soft proofing will report that all the colors
are in gamut.


Hmmm... so if I have a wide-gamut image and set soft-proofing profile to
sRGB-elle-V4-srgbtrc.icc, soft proofing works -- that's because your
version of gimp's sRGB is amended in the necessary ways to make it so?


Soft proofing to sRGB-elle-V4-srgbtrc.icc (which is the exact same 
profile as the GIMP built-in sRGB profile) also doesn't work. The 
problem is in LCMS, not in the profiles. All software that uses LCMS and 
supports high bit depth and floating point editing is affected, and all 
the more so if the source color space has a linear gamma TRC. Follow the 
links in the GIMP bug report for more information: 
https://bugzilla.gnome.org/show_bug.cgi?id=772266


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

Re: [Gimp-user] color management -- basic question

[Elle Stone]

On 01/09/2017 04:41 PM, Casey Connor wrote:


The only reason I was playing with the output profile and monitor
profiles was mainly to test my understanding of it, not because I was
developing a particular workflow.



The "colorful image" I was using was one of the test images here:
http://joco.name/2014/03/02/all-rgb-colors-in-one-image/
I used one of the 4096x4096 8-bit-per-channel images, which I scaled to
1024x1024 -- I just wanted an image to play with that I could be sure
would show me a shift when/if it happened -- in other words, it's just a
test image and I just assigned a randomly-chosen larger-than-sRGB gamut
to it so I could see how the rendering intents looked --  so it has no
associated color space, afaik, it's just "all the values" (or was, until
I scaled it down.)


Thanks! for the link - those are some seriously cool and beautiful 
images. The only "all colors" images I knew of is Bruce Lindbloom's 
image here, and it's strictly utilitarian: 
http://brucelindbloom.com/index.html?RGB16Million.html (as an aside, 
there is much useful color management information on Bruce Lindbloom's 
website).


It seems to me that the kind of experimenting you are doing is the best 
way to acquire a hands-on understanding of color management.




I now understand that with the generic sRGB profile I was using I
shouldn't expect the rendering intents to look any different from each
other.

Longer-term, I was interested to work in wider color spaces for the sake
of photography. I'd just be exporting to Wide Gamut (or whatever larger
space) and opening that up in gimp. The hope was to possibly retain some
more detail, soft-proof to check what's out-of-gamut, experiment, and
otherwise possibly get better results with certain transformations in
Gimp.


I recommend using Rec2020 or ACEScg as your "go to" wide gamut color 
space (but not when using default GIMP, for reasons already mentioned) - 
ACEScg is used by people making images for cinema, Rec2020 is the 
up-and-coming standard for monitors, and both of these spaces are good 
all-around editing color spaces.


If you edit in wide gamut color spaces, it's important to keep in mind 
the color gamut of your monitor profile, as your monitor simply can't 
show you colors that are out of gamut with respect to your monitor 
profile (and unless your monitor profile is accurate, the colors you see 
aren't a reliable guide to editing).


When I work with interpolated raw files, I use Rec2020 for initial 
editing (specifically a linear gamma version of Rec2020, 
"Rec2020-elle-V4-g10.icc"). But I also try very hard to make sure that 
the colors I produce while editing will fit into the sRGB color gamut 
for display on the web.


When affordable Rec.2020 monitors finally reach the consumer desktop 
(and if browsers ever are properly color-managed), editing and soft 
proofing will both be a lot easier.



From what you said it sounds like the CCE is the version to use if
I'm going to go through with that plan, since it amends certain tools to
not assume sRGB under the hood, but maybe the default version of gimp
would still be useful just to get a feel for what's out-of-gamut, and I
could still use g'mic tools if they work in Lab/Lch/etc, right?


Currently g'mic also is hard-coded to use the sRGB Y and XYZ values for 
calculating things like Luminance and for converting to LAB/LCH/etc. I 
did a bit of testing, and as far as I can tell there is something not 
quite right about the g'mic conversions to LAB even for sRGB images. So 
yes, g'mic has some really nice transforms. And no, those transforms 
can't be counted on to be accurate. Useful, yes. But not accurate.



(Also, I hope to profile my monitor soon.)


Profiling your monitor is a good thing to do. If your monitor is 
relatively new and has a good sRGB preset, then what you see right now 
is probably a pretty good guide to what your images actually look like. 
But not all monitors come with good sRGB presets.


If you use ArgyllCMS to profile your monitor, you have the option to 
make a LUT profile for exploring out of gamut colors. But I would 
recommend also making a matrix profile and using the matrix profile for 
normal image editing. If you have questions about making monitor 
profiles, the ArgyllCMS mailing list is a good place to start.





There are many versions of the sRGB ICC profile
(http://ninedegreesbelow.com/photography/srgb-profile-comparison.html). Most
of these versions are matrix profiles. Where did you get the sRGB
profile that you are using as the monitor profile, and what's its
exact file name?


From color.org, I think, judging by metadata? Not actually sure where it
came from -- sRGB_IEC61966-2-1_black_scaled.icc


Yes, that is one of the older color.org sRGB profiles. You might want to 
put that profile somewhere where you'll never accidentally use it.




But yeah, nothing carefully-chosen, whatever it is -- I did read up a
bit on the variety of sRGB profiles (thanks again to your 

Re: [Gimp-user] color management -- basic question

[Elle Stone]

On 01/08/2017 07:47 PM, Partha Bagchi wrote:

Try Elle Stone's color corrected experimental version. See if that helps.
CCing her in case.


Hi Casey,

My apologies, I'm not sure exactly what you are describing below, so 
I've asked a couple of questions to try to figure out what procedures 
you are using.



On Sun, Jan 8, 2017 at 6:37 PM, Casey Connor 

Re: [Gimp-user] color management -- basic question

[Elle Stone]

On 01/08/2017 09:13 PM, Casey Connor wrote:

Thanks again, Partha! As a recent convert to LCH, Elle's version looks
pretty amazing. I'm a little nervous to mess with my gimp install, as a
non-sysadmin expert, but if Elle has the time to respond maybe she can
let me know if there'd be value in trying her version. (I get the
impression from her page on the subject that 2.9.5 has all the same
color management stuff in it that her version does.)

It's not at all crucial to my workflow that the rendering intent be
obeyed, I was just curious what was going on, because I thought I
understood it and the results seemed to imply that I didn't. I wasn't
sure if this was a flaw in my thinking or gimp.


Hi Casey,

I sent an answer to your previous email regarding rendering intents to 
the gimp user's list (and to also directly to you and Partha). But it 
might not reach the list for awhile because I hadn't yet resubscribed to 
the GIMP users mailing list when I sent the email. So the post is in 
moderation "awaiting approval".


Anyway, if you only ever edit sRGB images, then default GIMP 2.9 will 
work just fine for your editing needs. The only exception would be if 
you want complete control over the TRC encoding for specific operations. 
For example, default GIMP doesn't yet provide for linearized RGB for 
Curves and Levels. Whereas in CCE, if you want to make a Curves or 
Levels adjustment using linear RGB, you can convert the image to a 
linear gamma ICC profile.


But if you edit in RGB working spaces other than sRGB, it's better to 
use CCE 
(http://ninedegreesbelow.com/photography/patched-gimp-compared-to-default-gimp.html) 
because of the hard-coded sRGB parameters in default GIMP 2.9.


Just keep in mind that CCE has a fair number of quirks and gotchas, for 
example in CCE the LCH operations, Luminance conversions to black and 
white, proper linear gamma down-scaling, and so forth only work as 
expected when the image is in a linear gamma RGB working space. Also CCE 
doesn't provide any decompose/compose operations, default GIMP supports 
importing many more file types than CCE, exchanging XCF files between 
default GIMP and CCE is tricky, and so forth.


I absolutely agree with you that LCH is amazing, and now that it's 
available, I can't imagine ever trying to edit without LCH. Default GIMP 
and CCE both provide the LCH blend modes. In addition CCE provides LCH 
color pickers and an LCH Hue-Chroma tool. So if even if you only ever 
edit sRGB images, you might find CCE worth using until these 
capabilities are added to default GIMP 2.9.


To avoid issues with installing two versions of GIMP on the same 
computer (which requires using prefixes and compiling from source), you 
can use a CCE AppImage, which are made by the author of the PhotoFlow 
raw processor and are available for download from here: 
https://pixls.us/files/


Best,
Elle

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

Re: [Gimp-user] Most current version of GIMP

[Elle Stone]

On 09/24/2016 07:24 AM, Patrick Shanahan wrote:

* FPC Music Ministry  [09-24-16 05:55]:

In order to ensure I have the latest version of GIMP, should I uninstall 
previous versions before downloading and installing the most recent version?

I currently have 2.8.4 on my computers.


Whether you need to uninstall previous versions probably depends on what 
operating system you are running. On Linux your package manager takes 
care of making sure there are no file clashes between the old and new 
versions.


On Windows, at least for Partha's builds (http://www.partha.com/, 
right-hand column notes - Partha has 2.8.14 available for 64-bit 
Windows), yes you should uninstall the old version (the portable version 
can be run without interfering with previous installations).


If you have a lot of custom settings in your configuration folder, you 
might want to make a backup of the config folder. People running GIMP on 
Windows would hopefully have more details.



-



CONFIDENTIAL: The contents of this email, including attachments, is intended 
only for the person(s) or entity to which it is addressed and may contain 
confidential and/or privileged material.  Any review, retransmission, 
dissemination or other use of, or taking of any action in reliance upon this 
information by persons or entities other than the intended recipient is 
prohibited.  If you received this in error, please contact the sender and 
destroy any copies of this information.




returning this to you per your posted instructions although i find it
impossible to completely comply as i do not have possession of many of the
copies.  if this was not your intention, you should post w/o the *stupid*
trailer, or stop using work related product for personal reasons.




Trailers such as the above do seem oddly out of place when posted to an 
open mailing list that's duplicated many times over on many servers.


But it's entirely possible that the OP uses GIMP at work and *for* work, 
so assumptions to the contrary aren't really warranted.


If someone else already answered the OP's original question, please 
excuse my two-cent's worth!


Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Adding Hotspots

[Elle Stone]

On 06/20/2016 04:18 PM, Pat David wrote:



On Mon, Jun 20, 2016 at 1:28 PM Elle Stone
<ellest...@ninedegreesbelow.com <mailto:ellest...@ninedegreesbelow.com>>
wrote:

You can do "on hover text" without using javascript. Do an internet
search on keywords such as: css image on hover text

For example using css3:
http://geekgirllife.com/place-text-over-images-on-hover-without-javascript/


Except I think the OP was asking about regional hover areas on an image
overlaying information:

 > I want to add hotspots to my drawing where I can hover the mouse over
an item and while it is there some additional information will pop up nearby


I think this is closer to what the op is looking for (I remember this 
link from trying to do something similar awhile back):


http://green-beast.com/experiments/css_map_pop.php




This is different than an image rollover, which is more of what is being
described in your link.  Technically you _could_ create a text area near
an image that could show different text varying based on context of
mouse position (possibly triggered through :hover, :focus, or :blur
events).  But that's outside the scope of what OP was asking for I
think.  At least in the context of an image editing program.



What the OP wants isn't part of any imaging program that I'm aware of.


tldr; sure you can do this - pick a programming language or
html/css/possibly-js combination and augment your image in that way.
Images themselves don't do this normally.



Best,
Elle

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

Re: [Gimp-user] Adding Hotspots

[Elle Stone]

You can do "on hover text" without using javascript. Do an internet 
search on keywords such as: css image on hover text


For example using css3: 
http://geekgirllife.com/place-text-over-images-on-hover-without-javascript/


There are also quite a few tutorials on the internet using css2.

On 06/20/2016 02:15 PM, Joao S. O. Bueno wrote:

actually, if you as much as create image maps, and replcae the
relevant URLs by javascript URLs you should get as close as waht you
wanta s possible.

Of course, images on themselves do not perform any action - actions
are all performed by the viewer program. Few programas will be more
feature-rich than a browser anyway.

Just beware the  "image map" thing is an arcane html constrcut from
the 90's - I am not sure it even works in a modern html5 borwser, but
if it does, replacing the link targets with javascript actions should
work just fine.


On hover text isn't necessarily arcane or outdated. It can be a nice way 
to preset text information.


Best,
Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Can't open nef images in gimp 2.9.3

[Elle Stone]

On 12/21/2015 09:18 AM, Alexandre Prokoudine wrote:

On Mon, Dec 21, 2015 at 5:11 PM, Alex Vergara Gil wrote:

Hello

One of the greatest things of the new gimp 2.9.3 is the handling of
nef files (raw camera images), they even appear in the file format
list, great! But in my windows 8 x64 bits with Partha's build it just
doesn't open, when trying to do that GIMP says image can't be opened,
but i can open the image even on windows photo software (the one that
is fullscreen) and it is ok. I dont know if this is a bug of GIMP or
something specific to windows so i'll wait until someone else can
duplicate this issue.


Or something specific to the unofficial build that you use on Windows.

Alex


Using default GIMP 2.9.3 updated a couple of days ago on Linux, and 
opening a CR2 file, the resulting image is the correct size, and only 
8-bits, so I'm assuming the raw file is being opened by UFRaw, yes?


Opening a NEF file using GIMP, the resulting image is just a 160px by 
120px thumbnail, though the file on disk is 17MB. So NEF doesn't seem to 
be working through the UFRaw plug-in.


I'm using UFRaw version 0.22, compiled with the GIMP plug-in, FWIW, and 
in case the UFRaw version makes a difference.


Some GEGL code suggests that there might be raw file support independent 
of UFRaw (rawload.c). Is this available through GIMP?


Elle

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

Re: [Gimp-user] Can't open nef images in gimp 2.9.3

[Elle Stone]

On 12/21/2015 11:12 AM, Alex Vergara Gil wrote

On Mon, Dec 21, 2015 at 5:44 PM, Elle Stone wrote:


Using default GIMP 2.9.3 updated a couple of days ago on Linux, and
opening
a CR2 file, the resulting image is the correct size, and only 8-bits


Yes Elle, thats a bit different error, but still an error. Is there
some official suport for NEF files inside GIMP, maybe through GEGL?


The error to which I was actually referring was the fact that when 
opening a NEF file, all I get using default GIMP 2.9.3 on Linux is the 
thumbnail, not the full image.


If you can't open a NEF file using GIMP (on Windows),

and all I get when opening a NEF file using GIMP (on Linux) is a tiny 
little thumbnail,


then it seems to me that these might be related errors. But of course 
they might be two entirely separate errors.


Elle


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

Re: [Gimp-user] Idea/Request: Fast start mode for GIMP

[Elle Stone]

On 12/18/2015 01:11 PM, Ross Martinek wrote:

Bottom line, if you want it to handle like a sports car,
don't load it like a dump truck.


GIMP comes with a whole lot of default installed plug-ins. I've compiled 
GIMP from source with most of the plug-ins disabled (there aren't very 
many "installed by default" plug-ins that I actually use in day-to-day 
editing). Not only does GIMP start faster, but it compiles faster, too.


So the many default GIMP plug-ins can be added to the list of things 
that cause GIMP to take longer to load, that it might be nice for users 
to have the option to not load.


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

Re: [Gimp-user] Idea/Request: Fast start mode for GIMP

[Elle Stone]

On 12/18/2015 02:40 PM, Simon Budig wrote:

Actually querying is usually not happening (except on the first startup,
then querying the plugins really is a drag).

However, there have been reports, that under some circumstances all
plugins get re-queried, AFAIK it is not clear what might cause this.


On my old (ten-year-old) computer modifying the source code to not 
compile the plug-ins made a big difference in compile time, and also in 
start-up time. FWIW I'm pretty sure startup time with fewer plugins was 
always quicker, even when I hadn't just finished rebuilding GIMP.


Elle

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

Re: [Gimp-user] Please help, small problem.

[Elle Stone]

On 12/16/2015 09:16 PM, Alexandre Prokoudine wrote:

Painting with mirror symmetry hasn't landed to any GIMP release yet.
Hopefully it will make it to 2.10.


In the meantime, Krita (https://krita.org/features/highlights/) provides 
for symmetric painting.


Elle

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

Re: [Gimp-user] Hiding tabs

[Elle Stone]

On 12/16/2015 03:32 PM, Simon Budig wrote:

But how would that work? When these tabs are not there - how would it be
visible that there are other tabs beneath it, and how would you switch
to one of the tabs beneath?


My apologies if I don't understand the real topic of this thread. But I 
think it's about having the option to not show the image tabs at the top 
in single window mode.


I don't use single-window mode, and one reason why I don't use single 
window mode is because the tabs are really big and there's no way to 
hide them so the image can take up more space vertically. Those tabs 
result in wasted screen real estate.


If there were a way to hide the tabs, then to switch images, the user would:

1. right-click to bring up the menu bar (assuming the menu bar is not 
already shown - I hide the menu bar even in multi-window mode to provide 
more vertical screen real estate)


2. click on the desired image.

Or else use alt-# to switch between image windows.

Best,
Elle

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

Re: [Gimp-user] Save and automatically apply a series of editing steps

[Elle Stone]

I'd like to be able to open an image file in GIMP (GIMP 2.9, not sure if
the version makes a difference) and have a series of editing steps
performed automatically.


If I were asking this question just for myself, I'd probably assume that 
figuring out "how to" is too much trouble.


However, in addition to my own interest in being able to automate 
applying a series of editing steps, recently two other people have sent 
me emails asking the same question.


Both of these people are new to GIMP and using my patched version GIMP 
2.9 from git. They both seem to like high bit depth GIMP quite a lot. 
And both of them are looking for ways to automate steps for faster 
throughput when there are a lot of images to edit all at once.


I'm in a total state of confusion as to what Pat's and Kevin's answers 
actually mean in practical "how to" terms, so my apologies but I'll try 
asking again:


Is it possible right now for users to automate a series of editing steps 
in high bit depth GIMP? If yes, is there a guide somewhere? Will the 
resulting images be high bit depth images or only 8-bit images?


Best regards,
Elle

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

Re: [Gimp-user] Save and automatically apply a series of editing steps

[Elle Stone]

On 12/07/2015 11:43 AM, Kevin Payne wrote:

  Yes it is possible to automate a sequence of steps, BUT it's a programmatic 
solution - you have to write scripts in Scheme, Python or maybe Perl.

At present (in 2.8.x) the support for scripts is firmly based around low 
bit-depth. I was asking if the API has been updated to incorporate the high-bit 
depth features (and all the GEGL operations), but perhaps that question (and 
the multitude of associated questions) would be better placed on the developers 
mailing list.


Kevin, thanks! I'll go ask on the developer's list.

Elle

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

[Gimp-user] Save and automatically apply a series of editing steps

[Elle Stone]

I'd like to be able to open an image file in GIMP (GIMP 2.9, not sure if 
the version makes a difference) and have a series of editing steps 
performed automatically.


I found the following tutorial: 
https://www.gimp.org/tutorials/Automate_Editing_in_GIMP/


That's a long, complicated tutorial (probably how people feel when they 
read some of the articles on my website :) ).


Is there a short "push these buttons" version of how to save and then 
automatically apply a series of editing steps?


Best,
Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Layer addition - bug, feature, or user misunderstanding?

[Elle Stone]

On 10/13/2015 12:25 AM, Richard wrote:

The problem is that a layer's opacity doesn't add -- it multiplies, like
this:

Result = (opacity) * (this layer) + (100%-opacity) * (result of layers
below)

This formula holds true regardless of the layer's assigned blending mode
(and it's recursive, with the "result of layers below" defined by
inserting the next layer down into the same formula).


Hmm, I tried setting the layer blend mode for the three layers to 
Addition, Normal, Lighten only, and Dodge, and regardless of the chosen 
blend mode, the result was always 79%. But these identical results are 
because each layer is white, R=G=B=1.0f or 255 at 8-bit integer. Change 
to some lower value, such as R=G=B=0.5f or 128 at 8-bit integer, and the 
result of blending the three layers over black does depend on the chosen 
blend mode.




= (22.2% + 55.8% + 1.3%) * (white)
= 79.3% white

Doesn't that 79% look rather familiar? :)


Many thanks! for explaining this math. The math behind Normal blend mode 
isn't exactly intuitively obvious, at least not to me.


But as explained below, I think that's not the right math for Addition 
blend mode. I think something might be wrong in the Addition layer blend 
mode code.



Aside - the left half of your image is totally reproducible on GIMP 2.8
.  (I can't seem to reproduce the right half in 2.8, but I haven't
examined the actual XCF either, so I don't have all the details.)


I uploaded a GIMP 2.8 version of the xcf file:
http://ninedegreesbelow.com/bug-reports/gimp29/layer-addition/gimp28-addition.xcf



Now to fix the values ... first, Red is on top so it can keep the 22.2%;
this leaves a translucency of 77.8% for everything below it.
For Green, below Red, divide its opacity by Red's translucency (above):
Green's opacity should be (71.7% / 77.8%) = 92.1%.  This, in turn,
leaves 7.9% of translucency for Blue below it.
For Blue (which is below both Green and Red), divide its opacity by the
overall translucencies of both Red and Green.  You can do the math if
you want (6.1% / 77.8% / 7.9%), but it conveniently works out to exactly
100% opacity -- i.e. Blue doesn't need any translucency for itself
because with both Red and Green on top of it (at the above opacities)
only 6.1% of Blue will be visible anyway.

To prove it, just plug the new opacities back into the above formula:

Image = 22.2% * (red) + 77.8% * (92.1% * (green) + (100% - 92.1%) *
(100% * blue) )
= 22.2% * (red) + 77.8% * (92.1% * (green) + 7.9% * (blue) )
= 22.2% * red + 71.7% * green + 6.1% * blue


Many, many thanks! I tried your percentages with a real image rather 
than a solid white layer, using Normal blend mode, and your percentages 
produced *exactly* the right black and white image.


Here's why I think there might be a bug in the code for Addition blend 
mode. But maybe you can explain why it's not a bug:


Working in GIMP 2.9, change the color of the three layers that are being 
added together to 0.50f (the same as you'd get if you started with a 50% 
gray layer and dragged the three channels over to the layer stack).


The result of setting the percentages to 22.2% of the Red channel layer, 
71.7% of the Green channel layer, and 6.1% of the Blue channel layer, 
and then setting the layer blend mode for each layer to Addition, is 
exactly 0.50f, which is intuitively what I would expect, and coheres 
with the equations:


(0.222 * Red) + (0.717 * Green) + (0.061 * Blue)

If Red=Green=Blue=0.5, the above equation simplifies to

(0.222 + 0.717 + 0.061) * 0.5 = 1.0 * 0.5 = 0.5

The corresponding Normal blend mode math that you provided produces 0.3965.

I tried the same percentages using GIMP 2.8, using R=G=B=128. Well, 
actually I set the percentages to the "easier to type" 22%, 72%, 6%.


In GIMP 2.8, Addition blend mode for the three layers produces R=G=B=127 
or 50% (rounded by the color picker), pretty close to what I expected 
Addition blend mode to produce. And Normal blend mode produces 
R=G=B=101, or 40%, exactly as you describe the Normal blend mode math above.


In GIMP 2.9, using Addition blend mode as described produces the 
intuitively expected results for all shades of gray less than or equal 
to 55% gray (R=G=B=0.55f, or 140 for 8-bit integer).


But at 56% gray and higher, results are progressively less than I would 
expect, assuming my equations for Addition blend mode are correct. 
Instead results progressively converge on the Normal blend mode results 
as the color of the blended layers approaches solid white.


So does this seem like a bug in the Addition blend mode? Or is there 
something I'm not still not understanding about how Addition layer blend 
mode is supposed to work?


Best,
Elle

As an aside (in case anyone is interested in using stacked channel 
layers to produce a black and white image), although the math is the 
same, the required percentages for converting to Luminance will change 
for other RGB color spaces. And the image needs to be in a linear gamma 
color 

Re: [Gimp-user] Layer addition - bug, feature, or user misunderstanding?

[Elle Stone]

On 10/13/2015 10:55 AM, Elle Stone wrote:

So does this seem like a bug in the Addition blend mode? Or is there
something I'm not still not understanding about how Addition layer blend
mode is supposed to work?


Hmm, Krita produces the results I expected, that is, the three layers 
add up to R=G=B=1.0f.


So either GIMP intentionally uses a different algorithm for addition 
blend mode. Or else there's a bug in the code, most likely the same bug 
reported here: https://bugzilla.gnome.org/show_bug.cgi?id=744265. I'll 
add a comment to that bug report.

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

[Gimp-user] Layer addition - bug, feature, or user misunderstanding?

[Elle Stone]

Using GIMP 2.9 updated yesterday, two different ways of adding layers 
produce different results. But it seems to me that the two ways should 
produce the same results. Here is a screenshot:

http://ninedegreesbelow.com/bug-reports/gimp29/layer-addition/addition-results-vary.png,

Are the different results a bug, a feature, or am I making an obvious 
mistake or just not understanding something?


Looking at the screenshot, the "channel" layers were produced by making 
a solid white layer and dragging the Red, Blue, and Green channels over 
to the layer stack. So of course each channel layer also has R=G=B=1.0.


The channel layers are added using layer percent opacities of 22.2 for 
the Red channel layer, 71.7% opacity for the Green channel layer, and 
6.1% opacity for the Blue channel layer. The percentages are the correct 
percentages for producing a Luminance conversion to black and white by 
adding the Red, Green, and Blue channels together as layers.


The result of adding the three layers should be white, R=G=B=1.0, which 
is what happens with the second way of adding the layers. But the first 
way, using the more obvious "add each layer to the layers below", 
produces R=G=B=0.793257.


Here's a download link for the actual XCF file:
http://ninedegreesbelow.com/bug-reports/gimp29/layer-addition/white-gimpdefault.xcf 



You'll need to reset *all* of the layer opacities to the values given 
above, because for some reason saving to disk and reopening causes layer 
opacities to shift slightly (for example, the Blue layer opacities shift 
to 5.9% instead of staying at 6.1%).


The image is an sRGB image and the precision is 32-bit floating point 
(linear) in order to get the layers to properly add up to R=G=B=1.0, 
which they should anyway for solid white, but results would be wrong for 
colors other than solid white or solid black.


Elle, puzzled
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] blur-gauss-selective gives segment fault when applied to the L-component of a LAB decomposition

[Elle Stone]

On 10/04/2015 12:22 PM, Helmut Jarausch wrote:

Hi,

using the GIT version from Sept, 30th, I get a segment fault in the 
blur-gauss-selective filter.

I first decompose the image into LAB and try to invoked this filter on the 
L-component.
It crashes immediately before showing the options window.

Is this known not to work?


I also get a segmentation fault (babl/GEGL/GIMP updated from git a 
couple of days ago). The GEGL gaussian blur works just fine, but the 
selective gaussian blur seg-faults.


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

Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL

[Elle Stone]

On 11/17/2014 06:56 PM, Simon Budig wrote:

Oh, I was under the assumption that AdobeRGB had well defined
chromaticies. If that is not the case then please consider my example
moot. I am well aware that dealing with color profiles most definitely
is not my area of expertise.

It absolutely does have well-defined chromaticities.

LCMS specifies an odd value for D65 and doesn't compensate for 
hexadecimal rounding. And so almost everyone who distributes ICC 
profiles made with LCMS makes AdobeRGB1998-compatible profiles that 
don't exactly match the Adobe specifications.


Graham Gill distributes ClayRGB1998.icm that exactly matches the Adobe 
specs. I've submitted code to GIMP to make a proper 
AdobeRGB1998-compatible profile.


Other free/libre profile makers really aren't distributing an exact 
match to the Adobe specs. I've already reported this on the LCMS mailing 
list.


Similar problems obtain with a lot of other free/libre ICC profiles.

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

Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL

[Elle Stone]

On 11/17/2014 07:32 PM, Ed . wrote:

Elle,

If you don't understand the difference between a design detail, and an
implementation detail, you need to either a) go away and get to
understand that difference; or b) stop commenting. I am neutral as to
which you choose.

Ed


Again, Ed, in this discussion you don't have a leg to stand on.

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

Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL

[Elle Stone]

On 11/18/2014 03:05 AM, Michael Henning wrote:

On Mon, Nov 17, 2014 at 11:39 PM, Gez lis...@ohweb.com.ar wrote:

P.s.: If you think this discussion is a waste of your time and my time,
feel free to skip an answer. I don't think it's a waste of time at all,
it's developer/user interaction regarding important aspects of the tool.
Do you really think that discussing this is counterproductive?


Yes, I think that discussing this is counterproductive because it is
premature. If I had spent the time I spent responding to color-related
emails on coding this system instead, it would easily be working right
now.


If I had not spent time and effort explaining the problems *before* you 
got around to implementing unbounded sRGB image editing, you would have 
coded up a working high bit depth GIMP that was steadily churning out 
wrong results. And I'd be filing a whole lot of bug reports.



Then, we could be discussing the details of a system that
actually existed, instead of the details of a system that does not
exist, and if current rates of coding continue, will never exist.


And the discussion would be exactly the same. You would still need to 
use UserRGB chromaticities instead of sRGB chromaticities. But you'd 
have to undo a lot of new code to get there.


Convincing the babl/GEGL/GIMP devs of anything regarding color 
management has never been easy. For example, in 2013 I tried to explain 
why there is a difference between device Y vs ICC profile D50-adapted Y:


* 
https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html 
and eight follow-up messages

* http://ninedegreesbelow.com/photography/srgb-luminance.html.

Michael Henning did understand and did make appropriate changes to 
babl's hard-coded sRGB Y values. But I doubt whether any of the other 
devs understood; if they did, babl wouldn't still use D65 device sRGB to 
convert to XYZ before converting to LAB, and GIMP wouldn't still be full 
of hard-coded D65 device sRGB Y values. See:


GIMP really does need someone on the team who understands ICC profile 
color management. But it doesn't do any good to have such a person 
around unless you actually listen.


To listen *intelligently* so you can ask the right questions when your 
color management person seems to be giving wrong advice (I'm just as 
capable as the next person when it comes to giving wrong advice), you 
need to understand a little bit about ICC profile color management. I've 
done my best to make this task easier:


Completely Painless Programmer's Guide to XYZ, RGB, ICC, xyY, and TRCs
http://ninedegreesbelow.com/photography/xyz-rgb.html

I've learned a lot while trying to explain where babl/GEGL/GIMP has gone 
off track regarding one or another color management issue. Hopefully the 
exchange of knowledge has been a two-way street.



You say I should stop responding, but it's hard to stop responding
when novels are being written about how wrong you are, but you believe
you are right. It's hard to stop responding when an article portraying
you as incompetent appears on hacker news. It's hard to stop
responding when you genuinely want people to understand.

   -- drawoc


I agree with you that it's hard to stop responding when you want people 
to understand something that you care about. I doubt whether any of you 
have a clue just how much I value GIMP as an RGB image editor. But GIMP 
is critically important to free/libre artists and therefore GIMP color 
management needs to be right.



Now, please explain this to me with a straight answer: Why is it so
insanely important to know what color space an operation happens in,
in a situation where it*by definition*  does not matter, that you are
willing to waste hours of your time and hours of developers' time
arguing about it?


This is exactly the right question. It will me take a bit of time to put 
together a straight answer that is also not one of my walls of words. 
I'll try to post the answer today or at least by tomorrow morning.


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

Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL

[Elle Stone]

On 11/18/2014 11:00 AM, Elle Stone wrote:

Convincing the babl/GEGL/GIMP devs of anything regarding color
management has never been easy. For example, in 2013 I tried to explain
why there is a difference between device Y vs ICC profile D50-adapted Y:

*
https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html
and eight follow-up messages
* http://ninedegreesbelow.com/photography/srgb-luminance.html.

Michael Henning did understand and did make appropriate changes to
babl's hard-coded sRGB Y values. But I doubt whether any of the other
devs understood; if they did, babl wouldn't still use D65 device sRGB to
convert to XYZ before converting to LAB, and GIMP wouldn't still be full
of hard-coded D65 device sRGB Y values. See:


Sorry, typo, the See: is misplaced. It should read:

Convincing the babl/GEGL/GIMP devs of anything regarding color 
management has never been easy. For example, in 2013 I tried to explain 
why there is a difference between device Y vs ICC profile D50-adapted Y See:


* 
https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html 
and eight follow-up messages

* http://ninedegreesbelow.com/photography/srgb-luminance.html.

Michael Henning did understand and did make appropriate changes to 
babl's hard-coded sRGB Y values. But I doubt whether any of the other 
devs understood; if they did, babl wouldn't still use D65 device sRGB to 
convert to XYZ before converting to LAB, and GIMP wouldn't still be full 
of hard-coded D65 device sRGB Y values.


Elle

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

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

On 11/16/2014 05:18 PM, Øyvind Kolås wrote:

On Sun, Nov 16, 2014 at 9:01 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

Do you understand that when I say that Multiply is a chromaticity-dependent
editing operation, I don't just mean the Multiply layer blend mode? that in
fact *all* editing operations that use multiplication or division are
chromaticity dependent, regardless of whether the colors are *in* gamut or
*out* of gamut with respect to the very small bounded sRGB color gamut?

The exception to all, of course, is when multiplying or dividing by black,
gray, or white.


Yes I do understand that


OK, thanks! for confirming. I was afraid my phrasing might have obscured 
an important point.



1. Do you agree or disagree that for *all* chromaticity dependentediting
operations, the *user* should be in control of which RGBchromaticities
are used to perform the operation?


That is the point of adding more, and named, RGB families to babl.



2. Do you agree or disagree that for chromaticity *in*depedent editing
operations (for example, and assuming linearized RGB: adding, scaling,
gaussian blur, etc), the same results (same XYZ values) are obtained
whether the operation is done in the user's chosen RGB working space or in
unbounded sRGB?


I do;


So it appears that we agree on the following, yes?

1. The user's chosen RGB working space chromaticities should be used for 
performing all chromaticity dependent RGB editing operations.


2. For chromaticity independent RGB editing operations, the same XYZ 
values are obtained regardless of whether the operation is performed 
using the user's chosen RGB working space chromaticities or after 
converting the image to unbounded sRGB.





Somewhat switching gears, the revised babl roadmap
(https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says:


The plan in roadmap hasn't really changed since mid-april[1],


I agree with you that the plan you outlined in April is pretty much the 
same plan that I think you are outlining now. In April you did agree 
that some RGB editing operations don't work in unbounded sRGB. You said 
that using targetRGB (ie the user's chosen RGB working space, UserRGB, 
barRGB, etc) would be one solution and that another solution would be 
converting to CIELAB to do the operation.


Putting aside coding considerations that might affect other software 
that uses babl and GEGL, here's my understanding of your current plan 
for babl/GEGL/GIMP:


1. Upon opening an image, the image will be converted to unbounded sRGB.

2. For all chromaticity dependent RGB editing operations:
   * Either the image will be re-encoded using the user's chosen RGB 
working space chromaticities, and then the operation will be performed.
   * Or else the image will be converted to CIELAB and then the 
operation will be performed.


3. For all chromaticity *in*dependent RGB editing operations, the image 
will be converted to unbounded sRGB for processing.


4. When converting to XYZ/CIELAB/etc, the image will first be converted 
to unbounded sRGB.


5. The GEGL developers will specify on an operation by operation basis 
whether the operation requires being encoded using UserRGB/Y/etc, or 
unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity 
dependent RGB processing, or etc.


As an important note, depending on the last operation that was done, the 
image might already be encoded using the GEGL-operation-specified 
format, in which case a conversion to that format is not needed.


Are the above five points (and note) an accurate summary of your current 
plan for babl/GEGL/GIMP?


I have a couple of followup questions, but there's no point in asking 
them if I don't have a clear understanding of what your current plan 
really is. I think we've both been rightly accused of talking right past 
each other.



1: the only change in plans since then (and that changed occured
before roadmap.txt was started), was abandoning the plan to do
conversions between bablRGB and userRGBs in babl using LCMS2; and
instead do those conversions directly ourselves in babl; a change
without impact on how babl will be used by GEGL (and GIMP).



Using babl instead of LCMS2 to do ICC profile matrix conversions makes 
perfect sense, being faster and potentially a lot more accurate 
(https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00093.html).



/pippin



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

Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL

[Elle Stone]

On 11/17/2014 10:46 AM, Simon Budig wrote:

Hi Elle.

The following is my understanding, when pippin answers his answers have
more authority than mine.


Hi Simon,

I appreciate your answers, but the points you make aren't actually 
relevant to the questions that I wanted to ask Pippin. This is my fault. 
In an effort to clarify what I think he's saying, I seem to have just 
opened the door for more miscommunication.


Elle Stone (ellest...@ninedegreesbelow.com) wrote:

Putting aside coding considerations that might affect other software that
uses babl and GEGL, here's my understanding of your current plan for
babl/GEGL/GIMP:


A slight preface here. I don't consider it important to focus on the
*storage* of the pixel data, as in the actual bulk memory for the pixel
data.


If you choose to *store* the user's RGB data using chromaticities not of 
user's choosing, that suggests that you also intend to *edit* the user's 
RGB data using chromaticities not of user's choosing





1. Upon opening an image, the image will be converted to unbounded sRGB.


I don't think that this is decided yet, I actually consider it unlikely
at the moment. I think it might be more likely to have it sitting in
memory as userRGB.But again, this is an implementation detail, where I
assume that the floating point math is sufficiently precise to avoid
visible rounding errors.


This is not just an implementation detail. The user has the right to 
control what RGB working space is used when performing RGB edits on the 
user's own RGB data.





2. For all chromaticity dependent RGB editing operations:
* Either the image will be re-encoded using the user's chosen RGB working
space chromaticities, and then the operation will be performed.
* Or else the image will be converted to CIELAB and then the operation
will be performed.




Conceptually the image won't be converted as a whole. A
pixel-data-flow-graph will be set up that considers the region of
interest.


This really is an implemetation detail.



For all chromaticity dependent RGB editing operations the pixels will be
re-encoded in the format the operations requests. Which most likely will
be userRGB.


If the user opens a BetaRGB image or an AdobeRGB image or whatever, the 
user really does expect that *all* RGB edits wil be done using the 
user's chosen RGB working space chromaticities.





3. For all chromaticity *in*dependent RGB editing operations, the image will
be converted to unbounded sRGB for processing.


For all chromaticity *in*dependent RGB editing operations the pixels will be
converted to the format the operations requests. Which most likely will
0e sRGB or XYZ.


This brings me to the question that I was planning on asking Pippin.

If Pippin *doesn't* intend to convert the image to unbounded sRGB before 
performing any RGB editing operations, then my question is irrelevant.


So the pre question is: Does Pippin intend that the image will be 
converted to unbounded sRGB before performing chromaticity *in*dependent 
RGB editing operations?


If Pippin's answer to the pre question is yes, here's the question I 
wanted to ask Pippin:


1. We've agree that many RGB editing operations really are chromaticity 
dependent and therefore should be done using the user's chosen RGB 
working space chromaticities.


2. We've agree that for chromaticity *in*dependent editing operations, 
the resulting colors as located in the XYZ reference color space are the 
same *regardless* of the chromaticities used to encode the RGB data 
before performing the operation.


Given the above two points of agreement, what is point of EVER 
converting the image to unbounded sRGB?


I can list a whole bunch of disadvantages. But I don't understand what 
the advantages are supposed to be.


I thought Jon Nordby had made it clear (more than once) that for all RGB 
editing operations, the user's chosen RGB working space's chromaticties 
would be used.


But it's hard to tell whether Pippin agrees with Jon Nordby.

So I'm asking Pippin as directly as possible whether he ever intends 
that RGB editing will be done using sRGB chromaticities instead of the 
user's chosen RGB working space's chromaticities.


If Pippin's answer is yes, then the next question is Why?.



(Sorry for repeating, but this is an important point: in a given image
context userRGB really is not conceptually different from sRGB or XYZ,


My apologies, but this statement makes no sense unless you mean the 
trivially obvious point that RGB color data can be losslessly converted 
to various unbounded color spaces including the XYZ reference color 
space, of course putting aside floating point precision limitations and 
sundry other sources of computational loss of precision.



it gets slightly more complicated when two images with different
user chromaticies are to be combined.)


Again, let the *user* decide what RGB working space to use for combining 
images. Except for the few compositing operations

Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL

[Elle Stone]

On 11/17/2014 05:41 PM, Mikael Magnusson wrote:

On Mon, Nov 17, 2014 at 10:03 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

On 11/17/2014 10:46 AM, Simon Budig wrote:



I don't think that this is decided yet, I actually consider it unlikely
at the moment. I think it might be more likely to have it sitting in
memory as userRGB.But again, this is an implementation detail, where I
assume that the floating point math is sufficiently precise to avoid
visible rounding errors.



This is not just an implementation detail. The user has the right to control
what RGB working space is used when performing RGB edits on the user's own
RGB data.


The above two things are implementation details as Simon said.


There is no reason to *store* the image using the sRGB chromaticities 
unless you also intend to *edit* the image using the sRGB 
chromaticities, or else if you intend to convert the image to unbounded 
sRGB and then to Y or else to XYZ and then maybe to CIELAB.


So yes, the question of how you *store* the user's RGB data really does 
matter. It's not just an implementation detail.


Unless maybe you think it's reasonable to randomly re-encode the user's 
RGB data using the sRGB chromaticities just because you can.



If you
don't understand this, then please don't write long articles full of
misinformation that get widely quoted.Your answers suggest you didn't
even understand what he said.


I do understand what Simon said. And I'm waiting for Pippin to clarify 
whether *Pippin* intends that images will be converted to unbounded sRGB 
before performing chromaticity independent RGB editing operations.


If Pippin's answer is yes, the image will be converted to unbounded 
sRGB for chromaticity independent RGB editing operations, I want to ask 
him why. There are many bad consequences of doing this. So if Pippin's 
answer is yes, there must be some advantages that I don't see.


Pippin and Jon Nordby seem to be saying different things. Three times 
Nordby has said that the image won't be converted to sRGB except for the 
handful of editing operations that really can't be generalized. (As an 
aside, in these cases, I hope a UI warning will be provided so the user 
knows what's going on and can exercise the right to not use the affected 
operation.)


And three times Pippin has made statements that seem to directly 
contradict Jon Nordby.



Your argument is like saying it matters
if you store an integer in decimal or binary, and doing anything else
than the user input is definitely wrong, because there is no longer
any way to display it in this format.


Umm, could you untangle your analogy? Because all of sudden the integer 
encodings became undisplayable images.


I assure you that if you add integers encoded using binary, while 
thinking you are adding decimal numbers, you will almost certainly get 
results that diverge from what you expect, adding 0+1 being an obvious 
exception.


And if you composite colors thinking you are compositing in UserRGB, 
when really you are compositing in sRGB, likewise you are very likely to 
get results other than what you expected.




Gegl stores pixels in memory in some format, it knows what format it
used.


babl and GEGL do communicate with each other as to what format the data 
is in and what format is needed next. Are you trying to say something else?



Gimp can display/edit pixels in some color space (specified by
the user).


Well, this really is the question: according to Pippin, what color space 
chromaticities will be used for chromaticity independent RGB editing 
operations? UserRGB's or sRGB's?



Gimp asks Gegl for pixels saying what colorspace it wants.


Well, sometimes GIMP specifies the babl format and sometimes GEGL 
specifies the babl format. The question is whether for RGB editing 
operations the format so specified will ever be unbounded sRGB. Each 
time Nordby seems to say no, Pippin seems to say yes.



Gegl presents the pixels to Gimp.All is well. It doesn't matter how
the pixels are stored.


Again, there is no reason to re-encode and *store* the pixels using the 
sRGB chromaticities *unless* there is an intention to *use* the 
re-encoded information for some purpose other than storing the pixels.


As GIMP is an image editor, presumably that purpose would be for 
*editing*, and the format the pixels are in for editing does matter a 
great deal.


Elle

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

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

On 11/15/2014 08:20 PM, Øyvind Kolås wrote:

On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

This really is my last post on unbounded sRGB unless someone has a specific
question to ask.


Well, I think a question was asked.



On 11/14/2014 11:47 AM, Øyvind Kolås wrote:


I ask for an assumption of good faith, that the babl/GEGL developers
know what they are doing and have incorporated your input from April
on out how multiply and gamma produce undesirable results for values
outside the 0.0-1.0 range working with unbounded sRGB. That we want to
and will incorporate that in the color management model of GEGL. A
model that differs from how traditional ICC based photo editors
traditionally work, GEGL has both internal (babl) and external (ICC)
color management; and you have correctly pointed out that the internal
color management is lacking and needs to take more RGB spaces into
account.


I think it's important to clarify some of Pippin's misunderstandings that
are betrayed in the above quote:

1. Multiply and gamma slider adjustments are both highly chromaticity
dependent editing operations. What Kolås fails to acknowledge, and maybe
doesn't even understand, is that this is true regardless of whether the RGB
channel values are *in* or *out* of gamut with respect to the bounded sRGB
color space.


The multiply compositing op; doesn't really have any sliders,


I don't think you intended to imply that I think the Multiply layer 
blend mode (compositing op) has a slider. So I'll assume you are 
rightly pointing to an ambiguity in how I phrased the sentence. I should 
have said something like this: Multiply and also Levels gamma slider 
adjustments.



and
gamma adjustments are among the things that definetely would not end
up using bablRGB; regardless of how far we get in specifying other
working spaces.


I'm going to ask you a question. Please don't take the question the 
wrong way. I'm trying to establish some common ground for communication.


Here's some background to the question:

There are four basic mathematical operations that can be performed on 
the pixels in an RGB image: add and subtract, and multiply and divide.


Add and subtract are inverses, and multiply and divide are inverses, so 
really the four basic operations reduce to two: add and multiply.


Here's the question:

Do you understand that when I say that Multiply is a 
chromaticity-dependent editing operation, I don't just mean the Multiply 
layer blend mode? that in fact *all* editing operations that use 
multiplication or division are chromaticity dependent, regardless of 
whether the colors are *in* gamut or *out* of gamut with respect to the 
very small bounded sRGB color gamut?


The exception to all, of course, is when multiplying or dividing by 
black, gray, or white.


See:
1. 
http://nbviewer.ipython.org/github/colour-science/colour-website/blob/master/ipython/about_rendering_engines_colourspaces_agnosticism.ipynb
2. 
http://ninedegreesbelow.com/photography/unbounded-srgb-multiply-produces-meaningless-results.html
3. 
http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html



4. The list of chromaticity dependent editing operations is much longer than
just multiply and gamma slider adjustments:

 * For editing performed on more or less perceptually uniform RGB data,
the list includes essentially *all* editing operations.

 * For editing performed on linear gamma RGB data, the list includes at
least the following operations (I haven't checked every single editing
operation made available through the GIMP UI):

 Channel data used as a blending layer
 Channel data used for making selections
 Colors/Alien Map HSL
 Colors/Alien Map RGB
 Colors/Auto stretch contrast
 Colors/Auto stretch contrast HSV
 Colors/Channel Mixer (try Margulis' enhance green formula)
 Colors/Desaturate average
 Colors/Desaturate lightness
 Colors/Mono Mixer (except straight Luminosity-based BW conversion)
 Colors/Posterize
 Colors/Threshold
 Colors/Levels Gamma slider operations
 Colors/Levels Red, Green, and Blue Input/Output sliders
 Colors/Levels Auto Pick (used for white balancing images)
 Filters/Artistic/Cartoon (this uses hard-coded Y values)
 Filters/Edge Detect/Sobel
 Filters/Enhance/Red Eye Removal
 Filters/Noise/HSV Noise
 Filters/Noise/RGB Noise
 Filters/Artistic/Soft glow
 Filters/Artistic/Vignette (any color except gray, white, black)
 Layer blend Mode/Burn
 Layer blend Mode/Color
 Layer blend Mode/Darken only
 Layer blend Mode/Difference
 Layer blend Mode/Divide
 Layer blend Mode/Dodge
 Layer blend Mode/Hard light
 Layer blend Mode/Hue
 Layer blend Mode/Lighten only
 Layer blend Mode/Multiply
 Layer blend Mode

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

 provides an overview of problems with unbounded sRGB image 
editing: Using unbounded sRGB as a universal color space for image 
editing is a really bad idea 
(http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html)


If you find the article to be too technical, looking at the pictures 
should be enough to let you see what the problems with unbounded sRGB 
really are. If you follow the links in the article, again you don't 
really need to read the text, just look at the pictures and you will see 
that unbounded sRGB image editing is a really, really bad idea.


Best regards,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

On 11/14/2014 12:01 PM, Alexandre Prokoudine wrote:

Øyvind, having a last say in every dispute typically makes one look
like a jerk. I am a living proof of that.


My apologies to Simon and Alex for continuing this discussion, and yes I 
guess I'll be the jerk with the last word unless Pippin wants to respond.



On 11/14/2014 11:47 AM, Øyvind Kolås wrote:

I was saying that one can construct a scene, that photographed with
your camera, would yield the type of desired black and white - when
done in sRGB or some other non sensor RGB space. So yes; for the
purposes of black and white conversion and using a single channel for
it - I still call that image a corner case.


I have no idea what Pippin means by one can construct a scene, that 
photographed with your camera, would yield the type of desired black and 
white - when done in sRGB or some other non sensor RGB space. If 
someone can help me out here, I'd be grateful.


In the meantime, as a note to Pippin, it sort of sounds like you expect 
photographers to change their workflow and their way of taking pictures 
to suit your unbounded sRGB architecture.


The yellow flower in question is long dead. So if there ever was a 
possibility of reshooting the scene in a way that would make the blue 
channel information available for use in the sRGB color space, that 
possibility is gone.


The flower's blue channel has interesting detail that is missing in the 
red and green channels. I used the blue channel as a blending layer over 
a straight luminance-based conversion to black and white. Here's a link 
to my envisioned black and white conversion:


http://ninedegreesbelow.com/gimpgit/gimp-srgb/channel-mix-blend/flower-blue-channel-over-luminance.jpg

This article shows what happened when I tried to do the envisioned 
conversion to black and white in the unbounded sRGB color space:


Channel blending when converting to black and white can fail completely 
in the unbounded sRGB color space 
(http://ninedegreesbelow.com/photography/unbounded-srgb-channel-blend-convert-black-white.html)


Frankly I am appalled that Pippin says my yellow flower image represents 
a corner case. How many of *your* images will he dismiss as corner cases?


Elle

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

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

On 11/14/2014 02:15 AM, Øyvind Kolås wrote:

On Sun, Nov 9, 2014 at 12:23 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

if the other babl/GEGL/GIMP developers really are in agreement with Jon
Nordby (the babl roadmap leaves room for differing interpretations), then
there is no reason whatsoever for further discussion of forking babl and
GEGL to benefit GIMP.


Misinterpreting is your choice. You still seem to have little trust
that babl/GEGL/GIMP developers have the interests of users/colors or
the future of their software in mind.


Really there is only one developer who's current stance on unbounded 
sRGB seems a little unclear.




babl/GEGL/GIMP developers have had rough consensus on this topic since
march or april,


You are somewhat rewriting history:

In 2011 Kolås said:

My stance is that the sliders on an operations should be predictable 
and always do the same thing for the colorimetrically absolute same 
color . . . . The RGB space defined by and used by babl uses the same 
primaries as sRGB 
(http://article.gmane.org/gmane.comp.video.gimp.devel/19916)


In 2012 Kolås said:

ICC profiles should only need to be involved upon loading files from 
disk and exporting to files used outside - internally it is up to 
GIMP/GEGL/babl to assign appropriate fully color managed color spaces to 
the raster storage of the buffers in the layers; for 8bpc precision this 
will be sRGB and for higher bitdepths this should be linear light/linear 
scRGB . . . . this differs from any assumptions that might have been in 
2.8 and before wrt color management and the ability to assign color 
profiles to images; I would not trust (and want GIMP to get rid of) any 
such things in the UI. 
(https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00261.html)


In March 2014 Kolås confirmed that images would be converted to 
unbounded sRGB before editing could begin 
(https://mail.gnome.org/archives/gimp-developer-list/2014-March/msg00086.html).


In April 2014 I asked for explicit confirmation that in GIMP 2.10 all 
images would be converted to unbounded sRGB before editing would begin 
(extended and unbounded mean the same thing):


[Q] Will the image be converted to extended sRGB before image editing 
can begin?
[A] Yes. 
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg1.html)


In April 2014 two other GIMP users and myself started testing whether 
unbounded sRGB actually was a viable model for image editing, and I took 
on the task of posting our results to the GIMP developers mailing list.


Initially Kolås dismissed our results as involving extreme edits and/or 
colors that hardly ever showed up in real images. Then he decided that 
at some point in the future special treatment might be needed for some 
images, some of the time. The record is in the April and May GIMP 
developer's mailing list:


Some blend modes break in unbounded mode sRGB 
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00049.html)


GIMP and Adobe RGB (1998) 
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00094.html)


Attempt to summarize the discussion of my examples of what doesn't work 
in unbounded sRGB 
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00102.html)


Drawing Rec 2020 gradients in the unbounded mode sRGB color space 
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00103.html)


Gamma slider adjustments don't work in unbounded mode sRGB
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00133.html)

Possible approach for some non-sRGB GEGL/GIMP color workflows 
(https://mail.gnome.org/archives/gimp-developer-list/2014-May/msg00059.html)


Then I gave up the discussion as a lost cause, until this article was 
posted to the web:


About Rendering Engines Colourspaces Agnosticism 
(http://nbviewer.ipython.org/github/colour-science/colour-website/blob/master/ipython/about_rendering_engines_colourspaces_agnosticism.ipynb)


GIMP being extremely important free/libre editing software, it seemed 
worthwhile to start another discussion on the topic of unbounded sRGB:


Don't make an architectural mistake based on a groundless premise 
(https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg2.html)


Twice in subsequent discussion it seemed that at least some of the 
babl/GEGL/GIMP devs had given up on unbounded sRGB, but each time Kolås 
made it clear that Kolås hadn't given up on unbounded sRGB. Here's 
Kolås's last public statement on the topic of unbounded sRGB (bablRGB 
and fixed linear RGB both mean unbounded sRGB):


the first thing we should do is to annotate all the operations which 
are broken when done with sRGB primaries, then we will be able to 
continue refactoring, profiling and optimizing; without breaking 
existing functionality/rendering. Not only in terms of making more 
operations request directly userRGB, but also doing things like make 
some linear operations accept

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

On 11/14/2014 04:56 AM, Alexandre Prokoudine wrote:

On Fri, Nov 14, 2014 at 6:03 AM, billn wrote:

BABL has been on the drawing board since 2008? 6 years and still not a no go for
a stable Gimp 2.10 release. Changing Gimp license may be faster than waiting
another 3-5 years for a stable BABL so Gimp can use better open source tools.


Are you suggesting that relicensing babl would somehow magically right
all wrongs? :) How?


I *think* Bill N might think that forking babl would mean that GIMP 
development could switch to a release early and often approach to 
future development. I think that's the difference between OpenOffice and 
LibreOffice that he's pointed to.


People who don't make a habit of reading the babl/GEGL/GIMP git logs on 
a regular basis might not realize what a huge amount of coding effort 
has gone into the conversion to a geglified GIMP. It's not a matter of 
incremental improvements.


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

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

On 11/14/2014 09:04 AM, Øyvind Kolås wrote:

I have spent hundreds of hours more on babl/GEGL this year than I
intended, most of them on unproductive arguments on mailinglists, a
medium I not well suited for clearing up misunderstandings


I agree with you 100% that you shouldn't waste your time responding to 
mailing list discussions. Personally I would very much prefer that you 
use your time to:


* Write the requisite babl format specifiers for allowing GEGL and GIMP 
code to be modified so functions can use Y and XYZ values from the 
user's chosen RGB working space, instead of using hard-coded sRGB values.


* Write the requisite generalized or additional babl functions so that 
when the user draws on a mask or uses a grayscale image as a mask, the 
mask is drawn using the correct Y values from the user's chosen RGB 
working space, instead of using hard-coded sRGB Y values.


* And maybe fix the babl conversion to LAB code that still uses 
unadapted D65 sRGB values instead of the D50-adapted values suitable for 
an ICC profile color-managed workflow. The current code produces wrong 
results for ICC profile color-managed sRGB images, and even more so for 
images in other RGB working spaces.


However, I do understand that proper ICC profile color management isn't 
a high priority for GIMP 2.10. So the hard-coded sRGB values might still 
be in the code base when GIMP 2.10 is released, which would mean GIMP 
2.10 would produce incorrect results for some operations, for images 
that aren't sRGB images.



but you
refuse to spend time where the developers normally clear up
misunderstandings, reach consensus and make plans; on IRC.


As you well know, I did try discussing unbounded sRGB with you on IRC. 
On IRC you felt free to issue personal insults. And you wasted time 
eliciting general agreement from people who learned everything they know 
about color management from you.




I wrote the babl roadmap when it became clear that playing in your
preferred medium, on the mailinglist, answering your questions was
more conductive to deepen misunderstandings than clear them up. Like
the continued refusal to understand that converting to unbounded
linear sRGB on import to the system would be an implementation detail
and not neccesarily mean that any processing would necessarily happen
in that format -


STILL you want to convert to unbounded sRGB upon opening an image? 
STILL?? Why What is this implementation detail supposed to accomplish?


In case you hadn't noticed, I had already ceased discussing unbounded 
sRGB, on the apparently quite mistaken assumption that the unbounded 
sRGB architecture had actually been abandoned.


In an ICC profile color-managed workflow:

* sRGB is just another RGB working space.
* sRGB doesn't require special treatment, being handled just fine by 
generalized code that retrieves the user's chosen RGB working space's Y 
and XYZ values.
* Developers need to respect the user's RGB data. There is *never* any 
justification for forcibly convert the user's RGB data to an RGB working 
space not of the user's choosing.



as well as broader principles of software engineering
and how one keeps working code working.


Nothing in the current GIMP code base depends on unbounded sRGB. No GIMP 
functionality will be broken by not writing new code that will convert 
the user's image to unbounded sRGB.


If you insist on writing special sRGB only code (unbounded or 
otherwise), at least give the user the option to opt out of using such 
code, even for sRGB images.



/pippin



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

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

On 11/14/2014 11:08 AM, Øyvind Kolås wrote:

On Fri, Nov 14, 2014 at 3:48 PM, Elle Stone  but you

refuse to spend time where the developers normally clear up
misunderstandings, reach consensus and make plans; on IRC.


As you well know, I did try discussing unbounded sRGB with you on IRC. On
IRC you felt free to issue personal insults. And you wasted time eliciting
general agreement from people who learned everything they know about color
management from you.


If calling the examples you used for corner cases, and that one can
construct scenes favoring different RGB spaces for orthogonality
between channels - not only the sensor space  - a personal insult; I
call it being direct.

/pippin



My apologies, I don't understand what you are trying to say. Can you 
give links to specific mailing list threads? Are you perhaps again 
saying that my yellow flower image is a corner case and therefore it's 
OK to write an image editor that makes it literally impossible for me to 
perform my envisioned conversion to black and white?


As an aside, insults are things like:

* backseat driver

* half-knowledgeable filibusterer (I'm only guessing that was directed 
at me; perhaps I'm wrong)


* suggesting on IRC that I'm insulting GIMP (which I have never done, 
GIMP is my favorite RGB image editor) when really I'm questioning your 
understanding of the requirements for proper RGB image editing


* suggesting that because I agree that you are intelligent (obviously 
you are), therefore I should stop trying to educate you about where your 
color management theories took a wrong turn and are threatening to take 
GIMP with them.

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

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

On 11/14/2014 11:21 AM, Simon Budig wrote:

Hi Pippin, Hi Elle.

I know that i am not really a neutral party in this dispute, but I'll
try anyways?

WILL YOU TWO PLEASE STOP FIGHTING?

Neither is Elle in the position to tell pippin what he is supposed to
work on, nor is pippin right when he holds Elle responsible for the time
he decided to waste in this discussion.

Elle is entitled to a told you so when we claim this feature to be
done and she can figure out from the outer workflow if internal
conversions happened or not.

Sheesh.

Bye,
 Simon



+1

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

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

On 11/14/2014 12:01 PM, Alexandre Prokoudine wrote:

14 нояб. 2014 г. 19:47 пользователь Øyvind Kolås pip...@gimp.org
написал:


You are quoting later venting of frustration with your later walls of
text on the mailinglists questioning and demanding answers for every
single little detail before details even exist.


Øyvind, having a last say in every dispute typically makes one look like a
jerk. I am a living proof of that.


I don't know as Pippin intended to have the last say. I replied to 
Pippin's next-to-last post about a half-minute before Simon's very wise 
post arrived in my inbox. So the timestamps are out of order. Pippin 
likewise may have hit the send button before receiving Simon's post.




Elle, we do invite you to attend Libre Graphics Meeting 2015 in Toronto,
April 29 to May 2. Travel expenses will be covered.


Alex, that is very kind. If at all possible I will atttend. Toronto is 
easier than Germany. But other obligations unfortunately make travelling 
even to Toronto a bit difficult.




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



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

Re: [Gimp-user] [Gimp-developer] Test images and test suite (was Re: GIMP should fork babl and GEGL)

[Elle Stone]

On 11/12/2014 08:32 PM, Pat David wrote:

Jehan,

Ah, I did mean to link something, but thank you for linking my Flickr
account.  Note that for the most part, I have the RAW files from any of my
photos that I'd be happy to release for whatever purposes are needed.

I also have model releases for all of my images as well, and can include
them as needed (there might need to be some discussion surrounding how that
release is made available and in what context as they contain probably
sensitive information regarding the models themselves).

​To Elle's point about licensing, I can make them CC-BY(-SA) as appropriate.

To Elle's other point about color, I would imagine that the most desirable
solution would be to host the actual RAW files themselves (hopefully from a
variety of capture sources/cameras).  Any further work around conversion
should probably be noted as needed to effectively reproduce the results.

More importantly, if there is a consensus reached about certain types of
test images, I am also available to shoot new ones specifically for the
purpose.  I can rent other cameras/bodies as needed to support multiple
capture sources.  Please don't hesitate to ask if there's something that
may prove useful (I may not be coding, but perhaps I can at least help out
in this way).  ​



It looks like we've reached the point of let's do this, which will 
require assembling the actual images and ironing out a lot of details.


I take it as given that Pat, Jehan, and myself will do the actual work 
of assembling the images, yes? And all three of us will also contribute 
test images. We each have websites so we can put up pages with 
thumbnails of suggested test images for consideration.


Nicolas Robidoux has already pointed to a good collection of images, 
which also provides a model for including all the required copyright and 
image generation information.


Contributions of proposed test images from other people are of course 
very, very welcome.


Would it be appropriate to perhaps ascertain who all wants to be 
actively involved in putting together a pack of test images? And then 
perhaps take this discussion off-list until we have something concrete 
to present for further input from GIMP users?


Best regards,
Elle Stone
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] [Gimp-developer] Test images and test suite (was Re: GIMP should fork babl and GEGL)

[Elle Stone]

On 11/13/2014 09:23 AM, Jehan Pagès wrote:

Otherwise I don't think we are in a hurry, and the set can also be
gathered slowly with time and patience

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

Re: [Gimp-user] [Gimp-developer] Test images and test suite (was Re: GIMP should fork babl and GEGL)

[Elle Stone]

On 11/13/2014 10:02 AM, Simon Budig wrote:


I do have access to a x-rite color checker which should be in a
reasonably good condition (it is slightly older but has been stored in
the dark).

I could try to set up a colorful scene and shoot it in RAW with my
Nikon D40. Would this be of any help?


Yes. A colorchecker is very often found in composite test images. Given 
the number of websites that post pictures of colorchecker charts, 
hopefully there are no copyright restrictions on photographs of same.




(I am right now unsure about the correct lighting, there *should* be
some daylight neon tubes around, but I am at the moment unsure where
they are...)


You raise a good point. On the one hand, natural daylight on a sunny day 
(D65ish) and direct morning and late afternoon/early evening sunlight 
(D50ish) are wonderful full spectrum light sources that really bring out 
colors. On the other hand, studio lighting is either iffy or expensive 
and probably sometimes both (my own studio lighting is on the cheap and 
iffy side).


Where I am sunlight is in short supply until spring, so it's studio 
lighting or nothing. For flourescent and LED lighting, the fact that the 
label says daylight is not very informative by itself. The other half 
of the story is the CRI, color rendering index 
(http://en.wikipedia.org/wiki/Color_rendering_index). Anything 92 and 
above is probably good enough.


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

Re: [Gimp-user] [Gimp-developer] Test images and test suite (was Re: GIMP should fork babl and GEGL)

[Elle Stone]

On 11/13/2014 09:51 AM, Jehan Pagès wrote:

I take it as given that Pat, Jehan, and myself will do the actual work of
assembling the images, yes? And all three of us will also contribute test
images. We each have websites so we can put up pages with thumbnails of
suggested test images for consideration.


Well for the contribute test images part, I'm not a photographer. I
have a good enough Canon camera and I can try to shoot some objects
with RAW on request though, but I won't guarantee the art quality for
these. Though you'll say that's not the purpose of this test set
anyway. :P


Well, I think it's asking a lot to expect a test image to also be 
artistically pleasing, except for maybe for people's faces, and Pat 
David makes really good photographs of people's faces.



For the rest, yes, I can help organize, host if necessary, put up a
small website (nothing fancy, I'm not really into web UI design) or
something.


If you are willing to put together a small website, that would be 
wonderful. Simple is better than complicated.


To allow for displaying and sorting through potential test images, I 
think jpeg image large thumbnails would suffice and would minimize 
demands on your server.


For actual storage and distribution of a finished pack of test images 
plus associated raw files, server demands would go up. So that's a 
separate issue to be addressed.



Also we should probably broaden the user list to encompass other FLOSS
graphics projects which would also be interested and can provide user
input and well as contribute photos. I don't think it should stay a
GIMP-only project.


+1.


As for gathering user input for instance, if every potential
interested project (GIMP, ImageMagick, Krita, G'Mic... are the ones
I'd think without much searching) would make a blog post to ask user
input and later user raw photos once we got the input, we could have a
usable test image set in no times (which can anyway always improve
with time and more user input).



I think the first step would be a small simple page to present the
project with a way to contact us. We could have a basic survey there
what are you looking for when you want test image and for what
purpose?. I can do such a thing.


Sounds good to me.

It might be nice to put up a page of sample test image large 
thumbnails comprising a mix of synthetic test images, colorful 
subjects, and faces. And we could include a list of links to existing 
useful but copyright-encumbered test images to give people an idea of 
the kinds of test images we'd like to put together.


I can supply thumbnails of some of the synthetic and colorful test 
images that I've put together. Would 512px max dimension jpegs be a 
good size?


The thumbnail images wouldn't represent any composite test images. But 
once we have a good set of images to work with, suitable composite test 
images would be easy to put together.



Then we can redirect people to this URI anytime, and ask projects to
do blog posts. Because staying email-only is a way to have the project
end up in limbo with time passing.




Then at some point, we go to the gathering step where we ask users
to send raw photos, ask them to accept the licensing (I would agree
with CC by and CC by-sa personally), and ask them to get the explicit
agreement of the model (maybe with a written agreement scan even?).
And of course we could present what we already have.

For the decisions on exact contents, I would let any of you in charge
though, since I am not the best fit to decide.


That's a place where input from users would be really, really helpful. 
Otherwise the people putting together the test images don't know what 
other people would find useful.


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

Re: [Gimp-user] [Gimp-developer] Test images and test suite (was Re: GIMP should fork babl and GEGL)

[Elle Stone]

On 11/11/2014 11:45 AM, Gary Aitken wrote:

On 11/11/14 08:15, Elle Stone wrote:


So the important question is:

*What copyrighted or otherwise test images GIMP users might have
downloaded from the internet and found useful, and *what kinds of
test images GIMP users might have already put together, *for what
particular testing purposes.


The things I find most useful are the following:

1. Peoples' faces.  Important here is a wide selection of ethnicities,
such as white, asian, african, latino.  It would be useful to have
individual images; and combination images with the extremes (e.g.
white, african, and wedding dress in the same image).  In the
african group, a wide range from very black to brown.


Despite the plethora of CC- and public domain images, finding suitable 
test images is harder than one might think. It's obvious that a lot of 
time and thought went into Nicolas Robidoux's collection 
(http://www.imagemagick.org/download/image-bank/16bit840x840images).


In particular, it's not easy to find faces that were properly 
white-balanced and haven't been in-camera jpeg processed to have 
saturated colors and dark shadows.


Maybe Pat David (and other GIMP users) could suggest some good face 
images that were shot raw, preferably in full spectrum lighting 
(daylight, direct sunlight, high quality studio lighting, etc), and 
properly white balanced, that could be release under a suitable license?




2. Highly saturated from the natural world -- birds and flowers, for
example.  I may have a few birds of use.  Others may well have
better images.


Raw files of such images from a variety of cameras would be very good to 
have.




3. Color gradients and ICC targets.
In this category I would find useful a chart specifically designed
to show the boundaries of different well-known colorspaces, such
as sRGB, AdobeRGB, and ProPhoto.


Hmm, ArgyllCMS can be used to relate actual image colors to the 
boundaries of any given RGB working color space, and also to compare 
different RGB working space color gamuts. Are the images on this page 
sort of what you were thinking of?


http://ninedegreesbelow.com/photography/icc-profile-conversion-clipped-colors-examples.html#flower-color-gamut

http://ninedegreesbelow.com/photography/icc-profile-conversion-clipped-colors-examples.html#srgb-prophoto-cielab


  If the chart had an outline of
the colorspaces as separate .xcf layers it would be great.  It
might be useful to have layers for some printers as well.


The thing is, color gamuts are 3-dimensional, so 2D charts only tell 
part of the story. 
http://brucelindbloom.com/index.html?WorkingSpaceInfo.html has great 
interactive tools for comparing color spaces. Click on the 3D Gamut 
Viewer link.


Also there is the related question of how much any give RGB working 
space overlaps with real-world colors as seen by the mythical average 
human. Lindbloom's chart indicates that ProPhotoRGB, for example, 
contains a lot of imaginary colors and also holds almost all real 
colors, whereas sRGB has no imaginary colors but only holds about 35% of 
all real colors.


Also see this Lindbloom page for a comparison between ProPhotoRGB and 
real world LAB colors as normally encoded by imaging software:

http://brucelindbloom.com/index.html?LabGamutDisplayHelp.html

I think what you are asking about might fall into the category of better 
soft-proofing tools. Right now GIMP's softproofing is pretty much only 
what's available from LCMS, which sadly doesn't deal with real vs. 
imaginary and also does a terrible job with linear gamma working spaces 
(not relevant to 8-bit GIMP, but very important for high bit depth GIMP).


A test image image that shows more or less finely granulated colors 
spanning the full range of real world colors would be *very* nice to 
have, but I don't know how to make such an image. Lindbloom does supply 
Lab Gamut test images, but the license is restrictive (see 
http://brucelindbloom.com/index.html?ProfileEvaluation.html).


Elle

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

Re: [Gimp-user] [Gimp-developer] Test images and test suite (was Re: GIMP should fork babl and GEGL)

[Elle Stone]

On 11/11/2014 07:32 PM, Chris Mohler wrote:

The license wording is a little ambiguous, but I interpret it to mean
that it's OK to use it for testing purposes, as long as you aren't
selling or otherwise distributing the image itself.  I'm not sure how
that would relate to a project like GIMP, and it appears we'd need a
German speaker to even ask.


Keeping in mind that I am not a lawyer and corrections/additions to 
what's below are very welcome . . .


The license for the excellent (even if not quite family-rated) Pixl 
test image reads like many/most test image licenses. The image can't be 
redistributed as part of a package of test images. Nor can it be used 
commercially.


Which raises the question of how to license a package of test images, 
hopefully in a way to be compatible with distribution alongside 
free/libre software.


CC-BY-SA (used by Wikipedia and compatible with free software) allows 
commercial use of images. AFAIK commercial use does require a release 
from all recognizable people in the image.


Releasing an image as public domain/CC0 (also used by Wikipedia and 
compatible with free software) requires consent of the person taking the 
photograph and also would seem to require the consent of any 
recognizable person being photographed.


Also, if there is a recognizable person in the image, the thorny issue 
of personality rights is raised 
(http://en.wikipedia.org/wiki/Personality_rights).


So two practical questions are how to license and how to distribute the 
test images.


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

Re: [Gimp-user] [Gimp-developer] Test images and test suite (was Re: GIMP should fork babl and GEGL)

[Elle Stone]

Here are links to some sample collections of copyrighted test images:

http://www.pcstats.com/articleimages/200601/samsungspp2040_300dpi1.jpg
http://www.northlight-images.co.uk/article_pages/test_images.html
http://www.outbackphoto.com/printinginsights/pi048/essay.html



So the first question is: What kind of test images, for what kinds of
testing, do you all, as a diverse group of GIMP users and developers, wish
you had access to?

Elle


I know we have a diverse and talented group of GIMP users. It seems to 
me that assembling a good set of test images really does need to start 
with feedback from GIMP users as to what kind of test images they might 
find useful.


I already know which test images I've downloaded from the internet over 
the years, for what purposes. I also know which test images I've put 
together, and for what purposes. It could be that no one else would find 
these images useful.


So the important question is:

*What copyrighted or otherwise test images GIMP users might have 
downloaded from the internet and found useful, and

*what kinds of test images GIMP users might have already put together,
*for what particular testing purposes.

It could be the case that hardly any GIMP user has ever used any test 
images (doubtful).


It could be the case that the phrase test image needs further 
clarification. Here are some random examples of when an appropriate test 
image might be useful:


1. Somewhere in my collection of copyrighted test images that can't be 
shared, there is a brightly colored montage that includes buildings 
along a stretch of beach, a parrot, and a woman's face. I found that 
test image very useful for learning about various conversion to black 
and white routines.


2. Grayscale block and grayscale and color gradient images are useful 
for testing things like:


*How LCMS2 plus the monitor+monitor-profile plus the GIMP color 
management settings affects how dark an image can get before dark gray 
and black can't be visually distinguished.
*How smoothly the monitor+profile displays and the printer+profile 
prints smooth gradients.


3. A granger rainbow can be used for all kinds of testing, such as 
Visually what kind of overlap is there between any given RGB working 
space and the monitor+profile and What happens when extremely 
saturated colors from a selected RGB working space are converted to the 
printer profile using perceptual intent.


So before getting too far down the road of randomly assembling images 
and hoping someone finds them useful enough to justify the time and 
effort that would be involved, I think it would be helpful, actually 
essential, to have feedback from at least a few GIMP users as to what 
kinds of test images you've used in the past (preferably with links to 
example test images), for what specific testing purposes.


Best regards,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone]

On 11/09/2014 02:56 AM, Alexandre Prokoudine wrote:

09 нояб. 2014 г. 6:28 пользователь billn for...@gimpusers.com написал:


Time to fork off BABL and GEGL. Forking was good for Openoffice.

LIbreoffice is

kicking tail. Developers who want to turn out a good product in a timely

manner

and other programmers who want to wait 3-5 years for small improvements.

LOL



I'm not sure if it was meant as sarcasm or if it was serious. However, if
you are not personally prepared to maintain a develop fork, you might
reconsider publicly suggesting something that makes sense so little that
you'd need a microscope to  expertly deal with it.

The topic of forking the libraries was born out of miscommunication. Could
we please finally bury this?


I agree with Alexandre. If I really do understand what Jon Nordby is 
saying (see 
https://mail.gnome.org/archives/gimp-developer-list/2014-November/msg00018.html 
and 
https://mail.gnome.org/archives/gimp-developer-list/2014-November/msg00023.html), 
and if the other babl/GEGL/GIMP developers really are in agreement with 
Jon Nordby (the babl roadmap leaves room for differing interpretations), 
then there is no reason whatsoever for further discussion of forking 
babl and GEGL to benefit GIMP.




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

Re: [Gimp-user] Blueprint Style Effects?

[Elle Stone]

On 11/07/2014 04:05 PM, Partha Bagchi wrote:

Yes, that is the same as DOG (Difference of gaussian). :)


Hmm, checking in GIMP 2.9 on a high bit depth image, I think the 
algorithms really are a bit different.


Checking in GIMP 2.8 on an 8-bit image, DOG gives much more useable 
results than duplicate, divide, blur. I should have checked 2.8 
results before mentioning duplicate, divide, blur. It's a cool way to 
make a line drawing, but it doesn't seem to work very well at 8-bit 
precision.


For anyone using GIMP 2.9, the duplicate, divide, blur method gives 
more useable results if you first use the Levels lower left (output) 
Value slider to pull all the channel values well above (0,0,0). This is 
because the Divide blend mode gives odd results when zero is divided by 
zero, going to black instead of to white.


Best regards,
Elle Stone




On Fri, Nov 7, 2014 at 3:56 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

On 11/07/2014 03:34 PM, Garyfx wrote:


You mean just exchanging colors?


Well, I may have not been as articulate as I could have.  I want to take
JPG
images of trailers and turn them into line schematics or outlines.  I want
just
the line drawing or frame of the trailers like the images I attached in my
original message.

And... a simple grey background is sufficient.

Thanks



This PhotoShop-specific link explains how to use divide blend mode to make a
line drawing; the technique is the same when using GIMP:

http://blog.advancedphotoshop.co.uk/tutorials/how-to-use-the-divide-and-subtract-blending-modes-in-photoshop-cs5/



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

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



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

Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL

[Elle Stone]

On 11/07/2014 04:25 AM, Simos Xenitellis wrote:

Hi All,

I am a recent subscriber to the list and I have read with interest the
recent threads and I am trying to figure out the what next?.
Developer resources in any project are generally very limited, so it's
important to get more people contributing.

Is there a test suite available that could show the expected behavior?
If not, let's try to build one, both the test-suite code plus the images
(before/after).

Regarding the color spaces and conversions, it should be easy to try to
make some of the the changes
(most of them sound like simple text substitutions),
compile the source and see how well it performs on the test-suite.
Any comments on that?

Simos



The text/code editor Geany can be used to do a file search in GEGL and 
GIMP for the following string (confine the search to *.c and *.h files): 
babl_format (


GEGL has 212 such strings. GIMP has 503.

Here are some example strings with the actual babl formats included (the 
list is not exhaustive):


babl_format (Y' u8)
babl_format (Y u32)
babl_format (YA u32)
babl_format (Y float)
babl_format (Y' float)
babl_format (Y'A float)
babl_format (Y'CbCrA float)
babl_format (R'G'B'A u8)
babl_format (R'G'B'A u16)
babl_format (R'G'B' float)
babl_format (R'G'B'A float)
babl_format (R'aG'aB'aA float)
babl_format (CIE Lab alpha float)
and so on . . .

If I understand Jon Nordby correctly, all of these babl_formats really 
are supposed to be dedicated formats that were intended to be used only 
with images encoded using the sRGB primaries. Changing the intended 
meaning of these formats might break compatibility with other software 
that uses babl.


So new babl_formats need to be written to take the place of all the 
dedicated sRGB only formats. Then the text substitutions could be made.


The problem is made more complicated by the fact that babl does many of 
the calculations for GEGL and GIMP functions that use Y (in particular 
painting on a mask and making an grayscale copy of the image for use as 
a mask). Babl also does the conversions to the YCbCr and CIELAB formats 
for GEGL and GIMP.


So all the babl functions that currently use hard-coded sRGB parameters 
either need to be generalized to use parameters pulled from UserRGB 
(meaning whatever RGB working space the user chooses, which might in 
fact be sRGB, or might be ProPhotoRGB, or etc). Or else duplicate babl 
functions for UserRGB need to be written.


The same is true for GEGL and GIMP functions that use Y to calculate 
Luminance, except most likely for GEGL and GIMP there won't be any side 
by side generalized and sRGB-only functions. Instead the existing 
functions will all be generalized.


Only a few GIMP UI functions use RGB working-space-specific (UserRGB) 
Y and XYZ values. This article lists where UserRGB Y and XYZ parameters 
need to be used: 
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html


To avert any possible confusion, when you open an image using GIMP, 
there is not and never has been a forced conversion from UserRGB to 
sRGB. The previously planned code that would have done so, never was 
written. If I understand Jon Nordby correctly, the development plan that 
would have required such code seems to have been put aside.


Currently only a few GIMP UI editing operations (that use Y to calculate 
Luminance or XYZ to convert to LAB) are affected by the babl_format 
assumption that the image really is an sRGB image. This article lists 
most of the GIMP UI functions that are currently only accurate for sRGB 
images: 
http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html


Hopefully Jon Nordby will point out any mistakes I might have made in 
the above summary.


Best regards,
Elle

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

[Gimp-user] Test images and test suite (was Re: [Gimp-developer] GIMP should fork babl and GEGL)

[Elle Stone]

On 11/06/2014 11:24 AM, Gary Aitken wrote:

Even if the result is not obvious visually, I need a heads-up
so I can pay close attention to what's happening and undo the
operation if appropriate.


On 11/07/2014 04:25 AM, Simos Xenitellis wrote:

Is there a test suite available that could show the expected behavior?
If not, let's try to build one, both the test-suite code plus the images
(before/after).


As Gary hinted, when doing X to an image, whatever X might be, 
sometimes results are visually obvious and sometimes not. Many times 
when editing images, I've done X and thought X was just fine, only 
to realize later that X had changed the file in an unwanted way that 
only became obvious several editing steps later.


And sometimes X can make a change in an image that the monitor's 
limited color gamut can't display, that might only pop up visually when 
the image is printed or displayed on a wider gamut display.


There are a lot of nice copyright-encumbered test images available on 
the internet, but not many copyleft test images, and not many images 
that reflect the full range of colors as captured by digital cameras and 
then interpreted using typical matrix input profiles.


When I was testing unbounded sRGB image editing, the first task was to 
put together some appropriate test images and then figure out which 
tests needed to be made, as per Simos's test suite.


A good test suite of copyleft images would be a nice thing to have, 
whether for testing new and existing editing algorithms, or for whatever 
testing that individual GIMP users might want to do on their own 
(printer-related, for example).


Best regards,
Elle Stone
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Test images and test suite (was Re: [Gimp-developer] GIMP should fork babl and GEGL)

[Elle Stone]

On 11/07/2014 10:25 AM, Jehan Pagès wrote:

A good test suite of copyleft images would be a nice thing to have,
whether for testing new and existing editing algorithms, or for whatever
testing that individual GIMP users might want to do on their own
(printer-related, for example).

That's a good idea. What kind of images would be the most interesting?
Basically should that be images, taken with a good digital camera, of
a lot of objects of various colors?
It could also be images with color gradients, I guess (sunset/rise and such)?
Or do you already have such copyleft images at your disposal that you
could provide?
Indeed if we could gather these for access to anyone as reference
(then various software could use them for their own tests), it would
be great.

Jehan



Nicolas Robidous's test image collection is very nice, in particular the 
baby's face and the brightly colored buildings make great test images. 
His images are already converted to sRGB, which means they can't really 
fully exercise the color gamuts of reasonably decent printers and wider 
gamut displays.


I can make available straight from the camera interpolated raw file, no 
enhancements added images of very saturated (outside the sRGB color 
gamut) natural objects, mostly flowers.


I've also put together various artificial color ramps, granger rainbows, 
stepped gray scales, and such. And I have IT8 target shots from several 
cameras, which I think the photographers would release under an 
appropriate license.


I wish that I had a nice set of pictures of people's faces, young to 
old, male and female, of diverse skin colors. Skin tones are something 
that everyone wants to get just right, so faces make great test 
images. Such photographs ideally would be shot raw under natural 
daylight, more or less full frame, and properly white balanced, 
preferably with a white balancing object discretely placed somewhere in 
the image frame (styrofoam cups, PVC plastic, white coffee filters all 
work really well, often as well as commercially available white 
balancing aids).


High quality images with good gradients would be a nice addition to a 
collection of test images. Interpolated raw files that have been output 
in a wider gamut color space would be more versatile than images that 
have already been converted to sRGB.


Here are links to some sample collections of copyrighted test images:

http://www.pcstats.com/articleimages/200601/samsungspp2040_300dpi1.jpg

I would love to have enough copyleft images to put together a copyleft 
composite similar to the one in the above link.


http://www.northlight-images.co.uk/article_pages/test_images.html

http://www.outbackphoto.com/printinginsights/pi048/essay.html


Thinking more about what kind of images, it depends on who's testing 
what. Here are some possible reasons for wanting test images:


* Testing scaling algorithms.

* Testing ICC profile conversions from wider gamut color spaces to 
printer profiles and/or to display screen profiles.


* Testing the quality of prints made by a commercial or personally owned 
printers.


So the first question is: What kind of test images, for what kinds of 
testing, do you all, as a diverse group of GIMP users and developers, 
wish you had access to?


Elle

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

Re: [Gimp-user] Blueprint Style Effects?

[Elle Stone]

On 11/07/2014 03:34 PM, Garyfx wrote:

You mean just exchanging colors?

Well, I may have not been as articulate as I could have.  I want to take JPG
images of trailers and turn them into line schematics or outlines.  I want just
the line drawing or frame of the trailers like the images I attached in my
original message.

And... a simple grey background is sufficient.

Thanks



This PhotoShop-specific link explains how to use divide blend mode to 
make a line drawing; the technique is the same when using GIMP:


http://blog.advancedphotoshop.co.uk/tutorials/how-to-use-the-divide-and-subtract-blending-modes-in-photoshop-cs5/


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

Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL

[Elle Stone]

On 11/05/2014 09:40 AM, Jon Nordby wrote:

On 5 November 2014 14:50, Elle Stone wrote:



For the babl code that converts an sRGB image to grayscale for use
as a layer mask, do you plan to add a new set of functions that
convert from UserRGB to grayscale?

That code would, of course, need to pull Y values from UserRGB.
Which of course means that the new code for UserRGB would also work
for sRGB images.

For the babl code that converts from color to Y for painting on a
mask, that code currently is hard-coded to use sRGB Y values. Do you
plan to add a new set of functions that convert from UserRGB to Y
for painting on a mask? That code would also, of course, need to
pull Y values from UserRGB. Which of course means that the new code
for UserRGB would also work for sRGB images.

For all the GIMP UI functions that currently use hard-coded sRGB Y
values sprinkled through babl, GEGL, and GIMP, do you plan to add a
new set of alternate functions that will use Y values pulled from
UserRGB? Again, that new UserRGB code will also work for sRGB images.

How is this not side-by-side implementation?


When I said operations I meant GEGL operations: There will be no
side-by-side implementation of GEGL operations.


Will this also be true of any editing operations that remain within the 
GIMP code base, once GIMP is fully geglified?


A separate question - will there actually be any remaining editing 
operations in the GIMP code base once GIMP is fully geglified?



Yes, we will have to introduce new babl color conversion functions which
handle arbitary RGB color spaces by looking up parameters from UserRGB.
Both to convert fromto grayscale and between the various RGB spaces.
There is no escaping that, as we don't have any code that can handle
these cases right now.


OK. This makes sense.


Whether the existing conversion functions with hardcoded sRGB parameters
for bablRGB will remain once general functions exists, is an open
question. It could be that they will just call into the general RGB
color conversion functions with the particular parameters of sRGB.


It seems to me that this might be the preferable course of action. This 
way there would be no reason for code to be written that tries to 
second-guess the user's intentions as to whether UserRGB really is the 
same as GIMP's built-in sRGB.



Or it could be that keeping the functions as-is has benefits that
outweigh the cost of keeping the code around, like being able to do
performance optimization tricks not possible in the general case.


Speaking as a developer (you all keep telling me I'm a developer), a 
crucially important guiding principle for writing a high end image 
editor is that you never mess with the user's RGB data without the 
user's explicit consent.


If you *ask* the user whether they want to have their data treated as 
bonified same as GIMP's sRGB and then use optimized sRGB-only code, 
that's one thing. Doing so behind the user's back, without their 
consent, that's another thing. That is disrespecting the user's control 
over their RGB data.



What part of the latest new plan am I missing? Could you explain the
purpose that is served by having all the functions with hard-coded
sRGB parameters sit side by side with equivalent functions that use
UserRGB parameters?

Or are you really getting rid of *all* the hard-coded sRGB
parameters? In which case, what is the new purpose for the bablRGB
formats that will not change their meanings?

For operations which have an actual dependency on sRGB parameters, like
the previously mentioned operations emulating color blindness.


Two practical problems will need solutions:

First, for code that clearly requires that the image be an sRGB image, 
converting the image to sRGB without the user's *explicit* consent is 
disrespecting the user's RGB data. If there are GIMP UI functions that 
only work for sRGB images, give the user a choice. Don't convert the 
image to sRGB without the user's explicit consent. Maybe they'd just as 
soon not use that editing operation.


Second, some functions currently use sRGB and NTSC *device* parameters:

  * Some of the existing hard-coded sRGB *device* parameters in the 
code base clearly ought to be D50-adapted ICC profile parameters. That 
code should be generalized to use UserRGB Y and XYZ values.


  * Some of the functions seem to suggest that the unadapted *device* 
parameters really are appropriate for the originally intended use, and 
that the affected functions simply aren't appropriate for use in an ICC 
profile *color-managed* workflow. These device functions should be 
identified in the UI so the unsuspecting user doesn't try to use these 
functions thinking they are appropriate for ICC profile color-managed 
images. I think the color-deficiency filter might actually be one of 
these functions.


Converting the image to the sRGB or NTSC ICC profile

Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL

[Elle Stone]

On 11/06/2014 12:35 PM, Gary Aitken wrote:

Maybe I'm misunderstanding the discussion.  Gimp asks when one opens an
image what one wants as the working colorspace.  But we're talking
about operations *after* the image has been opened and the working
colorspace has been established.

Once I establish the colorspace, I expect all operations to be performed
in a manner which is consistent with and preserves that colorspace.  If
some operation deals in some other space without my knowledge, that's
not good.

My apologies if I'm misunderstanding the discussion.


You aren't misunderstanding the discussion.

The current proposed solution to the current hard-coded Y and XYZ sRGB 
parameters is to generalize all editing operations to use UserRGB Y and 
XYZ.


But there are a handful of editing operations that can't be generalized, 
that only work properly when done on actual sRGB images.


One proposed solution to the only works in sRGB problem is to convert 
the image to sRGB for those few editing operations. That would be OK as 
an *option*. Even just a UI notification would be sufficient and then 
the user could choose to convert to sRGB or to simply not use that 
particular editing operation.


Previously (back in April) the plan was to convert all images to 
unbounded sRGB before editing would begin, and the user wouldn't have a 
choice in the matter.


More recently the plan was to convert to unbounded sRGB for just some 
editing operations and use UserRGB for other editing operations, and 
again the user wouldn't have a choice in the matter.


At this point we hopefully are down to only convert to sRGB for those 
very few editing operations that really only work in the sRGB color space.


I'm saying and make sure you still give the user a choice. There 
should never, ever be a forced conversion to sRGB. The only correct 
thing to do is tell the user what the problem is and let the user decide 
what to do, either convert to sRGB or else don't use the affected 
editing operation.


In addition to trying to avert any forced ICC profile conversions, I'm 
also concerned about special sRGB only optimized code.


Personally I would prefer that sRGB be treated just like any other RGB 
working space, with no special sRGB only optimized code paths, partly 
because there are too many sRGB profile variants (Will the Real sRGB 
Profile Please Stand Up? 
http://ninedegreesbelow.com/photography/srgb-profile-comparison.html).


Giving the user a choice whether to use or not use optimized sRGB only 
code paths would be OK. Not telling the user that sRGB images might be 
handled differently is not OK.


I don't want the devs to decide for me that this profile is close 
enough to sRGB that we'll just assume it really is the same as GIMP's 
sRGB and then we'll use different code paths.


Even if the image profile really is the GIMP sRGB profile, I still think 
the user should have a choice of whether to use optimized sRGB only 
code paths.


Given the previously planned forced conversions to unbounded sRGB, I 
think it's important to stress that the user really does need to have 
complete control over when and whether:

  * an image is converted from UserRGB to sRGB.
  * the GIMP sRGB profile is assumed to be close enough to some other 
sRGB profile variant.

  * special optimized sRGB only code is used.

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

Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL

[Elle Stone]

On 11/04/2014 02:31 PM, Jon Nordby wrote:

(apologies for top-posting)

Hi Elle,

The BABL roadmap[1], which was written in response to comments raised by
you (and others),
details a mechanism for working with multiple RGB color spaces. It will
be possible to create a babl format specifier which means
whatever-the-artist-chose-for-this-image RGB.
All GEGL operations which currently wrongly use hardcoded bablRGB (RGBA
float and similar) will be changed to use this new specifier.
Duplicate/side-by-side implementations of operations is not necessary
nor planned.



With this BABL work in place, GIMP/GEGL can then use LCMS to read in the
ICC color profiles from inputs and set up the parameters for this color
space.

I do not understand how this solution (once implemented) will not work
for your usecase. If you think it will not, please explain why.

I have no desired for a sRGB only workflow, and it does not help the
discussion to jump such a conclusion. Please do not assume that the
different needs are in conflict/adverserial to each other.

1. https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74


What you just described IS side-by-side implementations of operations. 
In an ICC profile color-managed application, sRGB is just another RGB 
working space. You don't need to special-case sRGB.


Right now all GEGL operations specify bablRGB: RGBA, R'G'B'A, etc.

In Pippin's originally planned unbounded sRGB architecture, bablRGB 
meant convert the image to unbounded sRGB before perfoming *any* 
editing operation. Now the plan is that bablRGB will mean convert to 
unbounded sRGB for *some* operations.


But thankfully the convert from UserRGB to unbounded sRGB code has not 
yet been written. So in reality, at this point in time bablRGB already 
IS UserRGB. There is no reason to write a whole bunch of new babl format 
specifiers for UserRGB. That would be side-by-side implementation.


ALL current babl/GEGL/GIMP editing operations already work just fine, 
regardless of the user's chosen RGB working space, EXCEPT for the fact 
that there are still hard-coded Y and XYZ parameters in the 
babl/GEGL/GIMP code base.


To work with UserRGB data, those hard-coded sRGB Y and XYZ parameters 
need to be generalized to use Y and XYZ parameters pulled from the 
user's chosen RGB working space. If you generalize those operations to 
work with Y and XYZ pulled from UserRGB, those operations will work just 
fine even when UserRGB really is sRGB.


bablRGB is now in fact and should remain UserRGB. There is no reason 
to write code that makes bablRGB mean convert to unbounded sRGB and 
then write more code that means use UserRGB instead of sRGB.


I'm leaving to one side the babl sRGB TRC flips because that code 
requires special handling, and the user really does need a way to 
completely disable those TRC flips. A fundamental premise for writing an 
RGB image editor is that you never mess with the user's RGB data without 
their explicit permission. Just opening the image with GIMP is NOT 
explicit permission.


Best regards,
Elle Stone
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL

[Elle Stone]

In his last post on the topic Pippin said:


Once we have the vocabulary to also describe this aspect of the
pixelformats used by operations, the first thing we should do is to
annotate all the operations which are broken when done with sRGB
primaries, then we will be able to continue refactoring, profiling and
optimizing; without breaking existing functionality/rendering. Not
only in terms of making more operations request directly userRGB, but
also doing things like make some linear operations accept any of
userRGB or bablRGB (or other linear RGB); and creating output buffers
in the same format – to avoid unnecessary conversions in such cases.

Using a fixed linear RGB format instead of userRGB is what for some
operations will provide the consistent results for the same property
values / slider positions. Knowing which operations this is important
for is easier to determine when we have code providing the vocabulary
in babl. The further along on the roadmap, more of the road will have
to be laid/determined as we walk it.



Nothing in the above post shows that Pippin has given up on unbounded 
sRGB. If Pippin really understood anything I've been trying to explain, 
he wouldn't still be saying things like:


//begin quote
Using a fixed linear RGB format instead of userRGB is what for some 
operations will provide the consistent results for the same property 
values / slider positions. Knowing which operations this is important 
for is easier to determine when we have code providing the vocabulary in 
babl.

//end quote

There is not one single operation for which it is important that sliders 
produce consistent results. NONE. NOT ONE. The whole premise that 
sliders should produce consistent results is grounded in a misconception 
of the requirements for RGB image editing.


Anyone not indoctrinated in the whole unbounded sRGB mystique that's 
been perpetrated among the babl/GEGL/GIMP devs for the last however many 
years would be rolling on the floor laughing if they could fight their 
way past the nonstandard color management vocabulary enough to 
understand what you all have been talking about all these years.


I no longer have the time to continue being actively involved with GIMP 
development (OK, that cheering in the background isn't nice! :) ). My 
hope is to see the whole unbounded sRGB thing abandoned. Let bablRGB be 
UserRGB. You can deal with device-specific code with a UI warning. An 
RGB image editor should NEVER mess with the user's RGB data without the 
user's explicit request. Behind the scenes conversions to unbounded sRGB 
is just wrong.


GIMP is important to free/libre artists. GIMP is also important to 
would-be refugees from Adobe Cloud. Artists need non-proprietary 
alternatives and specifically they need software that doesn't lock the 
user's work inside proprietary formats that can't even be accessed 
without a subscription.


(To forestall one of Pippin's stock responses, no, I am not advocating 
that GIMP be a PhotoShop clone. One reason I switched to Linux and free 
software was because I was unhappy with PhotoShop limitations regarding 
linear gamma image processing; sadly Cinepaint capabilities were 
overrated; even more sadly, all these years later GIMP high bit depth 
image processing is saddled with the whole unbounded sRGB overlay.)


If GIMP can't get ICC profile color management exactly right, well, 
DarkTable partly fills the gap with its built-in masks. And Krita is 
frankly leaving GIMP in the dust in very many ways. Krita is a load of 
fun to use for painting. But Krita not aimed at photographers and it's 
not as easy to use for strictly RGB image editing as GIMP would be, 
could be, if unbounded sRGB is just abandoned and the devs starting 
listening to potential and actual GIMP users.


What free/libre photographers really need is for GIMP to be everything 
it could be if ICC profile color management is properly implemented 
across the board for all editing operations. This whole unbounded sRGB 
thing is a dead-end street.


Best regards,
Elle Stone
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] GIMP should fork babl and GEGL

[Elle Stone]

My apologies in advance for sounding preachy, but here goes:

GIMP developers need to start paying attention to what potential and 
actual GIMP users really want and need from their RGB image editor.


I respectfully suggest the following:

Drop the incredibly paternalistic attitude that the devs know better 
than the GIMP users what GIMP users really need.


Try finding a few actual high end users who understand ICC profile color 
management and the requirements for proper RGB image editing, and *ask* 
them what they need. Talk to Krita users and Darktable users. Even try 
to find a few Adobe Cloud refugees and talk to them - there is certainly 
enough interest in high bit depth GIMP being expressed in the various 
photography forums.


Ask these actual and potential new GIMP users how GIMP would need to 
change before these users would be happy using GIMP for photographic 
image editing. And please don't try to hide from the user what's 
happening in the background. Instead show some respect the user's RGB 
data. Users are trusting that GIMP doesn't do silly things like 
converting to unbounded sRGB in the background or deciding for the user 
whether an operation should be done on linear or perceptually uniform RGB.


Best regards,
Elle Stone
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL

[Elle Stone]

On 11/05/2014 08:22 AM, Jon Nordby wrote:

What you just described IS side-by-side implementations of
operations. In an ICC profile color-managed application, sRGB is
just another RGB working space. You don't need to special-case sRGB.


No it is not. There will be one implementation of say multiply. It
will be able to work on any RGB color space. Including sRGB, but without
need for special casing.

Right now all GEGL operations specify bablRGB: RGBA, R'G'B'A, etc.

In Pippin's originally planned unbounded sRGB architecture,
bablRGB meant convert the image to unbounded sRGB before
perfoming *any* editing operation. Now the plan is that bablRGB
will mean convert to unbounded sRGB for *some* operations.


The meaning of the bablRGB specifiers has not, and will not change.
The vast majority of operations will just stop using them (because they
have hardcoded sRGB parameters), and instead use the new specifiers, as
per the roadmap.



For the babl code that converts an sRGB image to grayscale for use as a 
layer mask, do you plan to add a new set of functions that convert from 
UserRGB to grayscale?


That code would, of course, need to pull Y values from UserRGB. Which of 
course means that the new code for UserRGB would also work for sRGB images.


For the babl code that converts from color to Y for painting on a mask, 
that code currently is hard-coded to use sRGB Y values. Do you plan to 
add a new set of functions that convert from UserRGB to Y for painting 
on a mask? That code would also, of course, need to pull Y values from 
UserRGB. Which of course means that the new code for UserRGB would also 
work for sRGB images.


For all the GIMP UI functions that currently use hard-coded sRGB Y 
values sprinkled through babl, GEGL, and GIMP, do you plan to add a new 
set of alternate functions that will use Y values pulled from UserRGB? 
Again, that new UserRGB code will also work for sRGB images.


How is this not side-by-side implementation?

Why would any sane developer want to write all the new code and have it 
exist side by side with equivalent hard-coded sRGB functions?


What part of the latest new plan am I missing? Could you explain the 
purpose that is served by having all the functions with hard-coded sRGB 
parameters sit side by side with equivalent functions that use UserRGB 
parameters?


Or are you really getting rid of *all* the hard-coded sRGB parameters? 
In which case, what is the new purpose for the bablRGB formats that 
will not change their meanings?


Best regards,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL

[Elle Stone]

On 11/05/2014 09:07 AM, Simon Budig wrote:

Elle Stone (ellest...@ninedegreesbelow.com) wrote:

Why would any sane developer want to write all the new code and have it
exist side by side with equivalent hard-coded sRGB functions?


Why would any sane developer want to fork an existing libary and have it
exist side by side with an equivalent but subtly incompatible library?

Bye,
 Simon



You are entirely avoiding the very pertinent question I just asked and 
you full well know it.


Now could you try answering the question I did ask? Although frankly I'd 
rather hear what Jon Nordby has to say.


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

[Gimp-user] GIMP should fork babl and GEGL

[Elle Stone]

Below explains why GIMP should fork babl and GEGL for use just with GIMP:

Hacker News picked up an article from my website: The Sad State of High 
Bit Depth GIMP Color Management

(http://ninedegreesbelow.com/photography/sad-state-of-high-bit-depth-gimp-color-management.html)

In the Hacker News comments (https://news.ycombinator.com/item?id=8549560
), unhammer said:

//begin quote
From glancing over it, it seems to me like Elle Stone wants GIMP to 
make a rather radical shift to Do The Right Thing, while Øyvind Kolås 
(Pippin) values making small improvements one step at a time to avoid 
breaking current functionality.

//end quote

unhammer's otherwise excellent summary overlooks one very important 
point, which is that there is absolutely *no* current functionality in 
GIMP that would be broken by Doing the Right Thing, which is to give 
GIMP proper ICC profile color management.


The only caveat is that a very few GIMP UI functions really do need to 
be labelled as only for device sRGB images or in some cases only for 
device NTSC images. This article lists all such functions: 
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html


Moving back to the Hacker News comments, our very own Jon Nordby 
(jononor) reveals precisely where the current functionality that 
would be broken by Doing the Right Thing actually resides:


//begin quote
GEGL is developed for GIMP, and other projects. 
http://www.jonnor.com/2014/04/imgflo-0-1-an-image-processing... 
http://www.jonnor.com/2014/11/imgflo-0-2-the-grid-launched/ Disclosure: 
I'm a GEGL dev and the imgflo maintainer.


The 'other projects' part is one of the reasons why the proposed 
solution 'just strip all colorspace info, assume it is the same 
throughout entire processing pipeline' is not acceptable for GEGL, even 
if that might somewhat close to the typical usecase for GIMP.

//end quote

In other words, nothing in *GIMP* would be compromised or broken by 
Doing the Right Thing. However, Nordby's other projects *would* be 
affected. Of course his other software could be patched to assume sRGB 
as the image input profile, but perhaps that is something he doesn't 
want to do.


As an aside, by just strip all colorspace info, Norby seems to mean 
replacing hard-coded sRGB parameters with equivalent parameters pulled 
from the user's chosen RGB working space, which is precisely the Right 
Thing to Do for GIMP.


The ICC profile color management problem with current GIMP 2.8/2.9 is 
that some babl/GEGL/GIMP functions are written using hard-coded sRGB Y 
and XYZ parameters. These functions necessarily give wrong results if 
you, the GIMP user, try to edit images in other RGB working spaces such 
as AdobeRGB1998, BetaRGB, or ProPhotoRGB 
(http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html).


The Right Thing to Do for GIMP is to use LCMS to retrieve the Y and 
XYZ values from the image's actual user-chosen ICC working space profile 
and then use the Right values instead of the Wrong values.


Moving back to the Hacker News comments, Jon Nordby said:

//begin quote
This article is primarly a strawman argument, the 'architecture' which 
is so adamantly argued against has already been abandoned (much thanks 
to arguments from OP). 
https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74 It has 
however not magically implemented itself yet.


This is somewhat recognized in the article section which starts There 
is a ray of hope. The implication that the issues demonstrated will go 
away as a consequence of this has somehow been lost, possibly due to 
miscommunication.

//end quote

My article does not present a strawman argument. Based on his last post 
to the GIMP developer's mailing list, head babl/GEGL developer Øyvind 
Kolås is still clinging to his hopelessly broken unbounded sRGB model 
for image editing.


If Kolås had really given up on unbounded sRGB, he wouldn't still be 
saying things like Using a fixed linear RGB format instead of userRGB 
is what for some operations will provide the consistent results for the 
same property values / slider positions 
(https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00096.html). 
For those of you who don't speak bablese, fixed linear RGB means 
linear gamma unbounded *s*RGB.


Kolås's desire for consistent slider results betrays his failure to 
understand the nature of color-managed RGB image editing. Yes, many 
editing operations do produce different results in different RGB working 
spaces. This is precisely *why* we have different RGB working spaces. 
The ONLY person qualified to pick which RGB working space to use for any 
given technical or artistic purpose is YOU, the GIMP *USER*.


Kolås's plan seems to be to use unbounded sRGB whenever and wherever 
possible, with Kolås being the judge of whenever and wherever possible.


Nordby's plan seems to be to eventually implement side-by-side 
babl/GEGL processing for sRGB and for the user's choice of RGB

Re: [Gimp-user] User's Guide to High Bit Depth GIMP 2.9

[Elle Stone]

On 11/02/2014 08:35 AM, Partha Bagchi wrote:

Elle,

What are your thoughts on the 64-bit precision now in Gimp?


At some point in the not too distant past I asked about the 64-bit 
precision options. As I recall, the answer was that 64-bit precision 
options are to accomodate (I think) the FITS file format, which can be 
at 64-bit precision. But the actual GEGL calculations are at 32-bit 
floating point.




Also, (I know, I shouldn't ask :) ) are the patches already in the
current trunk?


My apologies, I'm not sure which patches you are asking about. The 
openexr patch? I filed a bug report but don't remember if I attached a 
patch or not. The patch to retrieve Y and XYZ info from the image ICC 
profile? I did attach a patch to the bug report. Some other patch?


Elle



Thanks,
Partha


On Sat, Nov 1, 2014 at 7:40 AM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

I posted a User's Guide to High Bit Depth GIMP 2.9 to my website.

Some of the GIMP 2.9 code still uses hard-coded sRGB-only parameters.

Consequently, if you use GIMP 2.9 to edit images in wider gamut RGB working
spaces such as ProPhotoRGB or AdobeRGB1998, the affected editing operations
produce incorrect results.

The User's Guide tells you which editing operations to watch out for and
also provides some workarounds.

Some of the workarounds are simple, and some require making small
modifications to the source code and then recompiling babl/GEGL/GIMP.

Here's the link:
http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html

The Guide talks about color management and so gets a bit technical in
places. So if anyone has questions, please ask and I'll do my best to answer
them.

Best regards,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list




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

Re: [Gimp-user] User's Guide to High Bit Depth GIMP 2.9

[Elle Stone]

On 11/02/2014 09:08 AM, Partha Bagchi wrote:

Yes, the openexr patch, the modified util.h, and the 7 files that need
to be modified. I can do it locally, but would be nice if they were in
git.



I added the openexr patch to a bug report. With this patch, the user 
really does need to assign an appropriate linear gamma ICC profile to 
the openexr file, as the GIMP built-in sRGB profile assumes nonlinear 
data. All the patch does is revert to the original openexr code, from 
before the latest openexr commits were made: 
https://bugzilla.gnome.org/show_bug.cgi?id=316646


On the one hand, the modified util.h file isn't really something that 
any of the devs would like to see as a patch, as it basically destroys 
the functionality of the babl/GEGL linear vs perceptually uniform code.


On the other hand, it's very possible that some of the people who use 
your excellent builds might like the linear vs perceptually uniform 
functionality removed until such time as the UI options are not so 
confusing.


On a related topic, awhile back I wrote patches that remove all of the 
(linear) vs (gamma) precision options, plus all the supporting 
linear/gamma precision switching code. It was very nice to use high bit 
depth GIMP without seeing such a long list of precision options. But 
those patches won't work with the latest git versions of babl/GEGL/GIMP 
(I could update the patches if anyone really wanted to use them).


This bug report: https://bugzilla.gnome.org/show_bug.cgi?id=737778
has a patch that retrieves the RGB working-space-specific Y and XYZ 
parameters, and also specifies where the information needs to go to take 
the place of the current hard-coded sRGB parameters. Unfortunately I 
don't have sufficient coding skills to write code that would ferry the 
retrieved information to the places in the code base that need the 
information.


As far as the 7 files go, modifying those files requires knowing what 
RGB working space the user actually wants to use. This is why I 
currently run three side-by-side installations of GIMP 2.9, one per RGB 
working space that I'm currently using. If I knew how to write the Y/XYZ 
ferrying code, there would be no need to resort to running three 
side-by-side versions of babl/GEGL/GIMP.


No doubt just about any of the GIMP devs would be able to write the 
ferrying code without much trouble, which is why I suggested that 
perhaps a proper ICC profile color management branch of babl/GEGL/GIMP 
could be set up.


Elle

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

Re: [Gimp-user] User's Guide to High Bit Depth GIMP 2.9

[Elle Stone]

On 11/02/2014 10:03 AM, Elle Stone wrote:

On a related topic, awhile back I wrote patches that remove all of the
(linear) vs (gamma) precision options,


Leaving, of course, the ability to choose 8/16/32 bit precision. That 
probably wasn't clear.


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

[Gimp-user] User's Guide to High Bit Depth GIMP 2.9

[Elle Stone]

I posted a User's Guide to High Bit Depth GIMP 2.9 to my website.

Some of the GIMP 2.9 code still uses hard-coded sRGB-only parameters.

Consequently, if you use GIMP 2.9 to edit images in wider gamut RGB 
working spaces such as ProPhotoRGB or AdobeRGB1998, the affected editing 
operations produce incorrect results.


The User's Guide tells you which editing operations to watch out for 
and also provides some workarounds.


Some of the workarounds are simple, and some require making small 
modifications to the source code and then recompiling babl/GEGL/GIMP.


Here's the link:
http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html

The Guide talks about color management and so gets a bit technical in 
places. So if anyone has questions, please ask and I'll do my best to 
answer them.


Best regards,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] Elle Stone

[Elle Stone]

On 10/16/2014 01:15 PM, billn wrote:

I suggest to give Elle the latest dev version of babl to edit the way Elle wants


Just to be clear, Elle is in no way qualified to make major changes to 
babl, GEGL, and GIMP. Elle's ability to write c code is extremely 
limited and every bit of code she's ever contributed to GIMP has 
required major cleanup on the part of the real programmers.


Also, all in all, Elle thinks babl, GEGL, and GIMP are pretty cool already!

But thanks! for the vote of confidence.

Kind regards,
Elle Stone
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] [Gimp-developer] Precision Conversion Dithering and Triangular wave gradient issues

[Elle Stone]

On 09/02/2014 07:00 PM, Michael Henning wrote:

I think I might have fixed the segfault. Could you pull and test again? Thanks.

   -- drawoc

commit 36d719c9862892ec64383699e7778264f06dd4be
Author: Michael Henning
Date:   Tue Sep 2 18:49:41 2014 -0400

 app: In GimpBlendTool, don't start the draw tool too early.

 Also simplify some related logic and rename related functions to
 be clearer.




That did fix the segfault. Thanks!
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Re: [Gimp-user] [Gimp-developer] Precision Conversion Dithering and Triangular wave gradient issues

[Elle Stone]

On 09/03/2014 06:19 AM, Elle Stone wrote:

On 09/02/2014 07:00 PM, Michael Henning wrote:

I think I might have fixed the segfault. Could you pull and test
again? Thanks.

   -- drawoc

commit 36d719c9862892ec64383699e7778264f06dd4be
Author: Michael Henning
Date:   Tue Sep 2 18:49:41 2014 -0400

 app: In GimpBlendTool, don't start the draw tool too early.

 Also simplify some related logic and rename related functions to
 be clearer.




That did fix the segfault. Thanks!


Sorry! Sent to the wrong list!

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