Hi,

On Tue, Nov 4, 2014 at 7:27 PM, Elle Stone wrote:

[...]
Skipping all the main contents, since I don't know enough to be able to tell what is "the right thing to do" or not. Just a comment on the license and forking part.

Another advantage to forking babl and GEGL for GIMP is that GIMP's fork of babl and GEGL could be GPLed, thus freeing the GIMP devs to add FFTW (Fourier transforms, http://www.fftw.org/) and other new functionality to GIMP. FFTW is GPLed. At present, GIMP is somewhat hobbled as to what GPL code can be used for new editing functions because the babl/GEGL code is LGPLed.

You can't just relicense a whole program just because you forked it. Unless you asked a copyright assignment from contributors when they contributed code (which the GIMP project doesn't do), each piece of code still belongs to every person who contributed it. Which means that to be able to relicense GEGL or babl, you'll have to ask permission to every single person who contributed code over the years, and if you can't get it, delete or rewrite all the pieces of code that still exists and you could not get relicensing permission for. Well that's a huge and laborious work.

Also LGPL is usually used for library to allow a wide range of software to use the library. If the forked version was to become GPL, it would become very limited as to which program can use it.

In any case, I don't believe a fork is any kind of solution here (or at least not the best one). If there really is a problem (I don't deny nor acknowledge it; as I said, I don't know enough), I would really hope for a real in-code solution to be found for all kind of software to be able to use GEGL/babl with the various use case and no broken workflow. A single library being shared by a wide range of software is a real strength. In particular it allows the library to gain stability since we can get a lot of feedbacks and patchs from various downstream program (such as GIMP or imgflo). I would be really sad if we were to lose this strength.
If things were becoming too bad for GIMP somehow and we need to fork a library we use, I am not 100% against the possibility, but this should really be the last last possibility to consider. Working in harmony with upstream and helping each other should really be the way to go.

Jehan

With kindest 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

(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

On 4 November 2014 19:27, Elle Stone wrote:

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 working spaces. This plan unnecessarily complicates the code and totally ignores the fact that sRGB is just another ICC profile RGB working space that needs *no* special treatment.

The only way I can see for GIMP to get out of this babl/GEGL "hard-coded sRGB mess" is for GIMP to fork a babl/GEGL branch meant specifically for GIMP. That way Nordby can have his "sRGB only" branch, Kolås can play with unbounded sRGB, and GIMP can have proper ICC profile color management without having to take a backseat to the needs of other babl/GEGL projects.

Another advantage to forking babl and GEGL for GIMP is that GIMP's fork of babl and GEGL could be GPLed, thus freeing the GIMP devs to add FFTW (Fourier transforms, http://www.fftw.org/) and other new functionality to GIMP. FFTW is GPLed. At present, GIMP is somewhat hobbled as to what GPL code can be used for new editing functions because the babl/GEGL code is LGPLed.

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

Jon Nordby - www.jonnor.com

On Tue, Nov 4, 2014 at 10:27 PM, Elle Stone wrote:

Another advantage to forking babl and GEGL for GIMP is that GIMP's fork of babl and GEGL could be GPLed, thus freeing the GIMP devs to add FFTW (Fourier transforms, http://www.fftw.org/) and other new functionality to GIMP. FFTW is GPLed. At present, GIMP is somewhat hobbled as to what GPL code can be used for new editing functions because the babl/GEGL code is LGPLed.

Well, it's a shame we can't legally use FFTW to revive that GSoC project, but FFTW is not the only option out there. There's e.g. https://github.com/anthonix/ffts.

Also, as Jehan correctly stated, licensing a library under GPL opens a whole can of worms. Just google for "libredwg gpl freecad librecad" to see what kind of madness can happen.

Alex

On Wed, Nov 5, 2014 at 4:57 PM, Elle Stone wrote:

Drop the incredibly paternalistic attitude that the devs know better than the GIMP users what GIMP users really need.

Out of curiosity: if we had that attitude, what was the point of working with a user experience architect from 2006 to 2013, actually conducting interviews with end-user and adding/rewriting features based on those interviews? :)

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.

With Peter's departure, someone would have to take over the role of UI/UX guy to do interviews properly and write specs.

Alex

On 5 November 2014 13:50, Elle Stone wrote:

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.

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.

Jon Nordby - www.jonnor.com

Elle Stone (ellestone@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

simon@budig.de              http://simon.budig.de/

On 5 November 2014 14:50, Elle Stone wrote:

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?

When I said "operations" I meant GEGL operations: There will be no side-by-side implementation of GEGL operations. 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 from&to 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.

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. 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.

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. Or for interacting with (sometimes broken) operating-system/library interfaces which expects sRGB. I don't expect it to be particularly common. The primary reason (as I see it) for not changing the semantics of existing specifiers is to preserve compatibility. Code outside of BABL/GEGL/GIMP could very well be reliant on the current meaning of the bablRGB formats.

Jon Nordby - www.jonnor.com

I'd like to add my penny's worth on this discussion. My primary use of gimp involves editing photographic images, for both web and print purposes.

On 11/06/14 05:04, Elle Stone wrote:

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.

This is critical. If I'm working with a wide-gamut profile, I really really really don't want gimp screwing with the rgb data without my say so. 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.

Gary

On Thu, Nov 6, 2014 at 8:24 PM, Gary Aitken wrote:

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.

This is critical. If I'm working with a wide-gamut profile, I really really really don't want gimp screwing with the rgb data without my say so.

Frankly, I'm puzzled. It's been, how many? 8 years? since GIMP asks users what it should do with a picture that is tagged with a profile that doesn't match the current RGB working space. Has anyone actually suggested that this is going to be otherwise? :)

Alex

Hi Alex,

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.

This is critical. If I'm working with a wide-gamut profile, I really really really don't want gimp screwing with the rgb data without my say so.

Frankly, I'm puzzled. It's been, how many? 8 years? since GIMP asks users what it should do with a picture that is tagged with a profile that doesn't match the current RGB working space. Has anyone actually suggested that this is going to be otherwise? :)

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.

Gary

On Thu, Nov 6, 2014 at 10:00 PM, Elle Stone wrote:

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.

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

Hi,

On Fri, Nov 7, 2014 at 1:07 PM, Elle Stone wrote:

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).

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

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

I suggested
http://www.imagemagick.org/download/image-bank/16bit840x840images/README to Elle.

Some details RE: how they were made are found in individual .txt files, e.g.
http://www.imagemagick.org/download/image-bank/16bit840x840images/wave.txt

I can't add much to the color discussion, but at least I can offer up just about any of my images as RAW for any testing (just about everything I shoot is cc-by-sa usually). If anyone finds one of mine they would like, just let me know and I'd be happy to provide the camera raw file.

On Fri, Nov 7, 2014 at 1:24 PM, Elle Stone wrote:

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-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp- developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list

pat david
http://blog.patdavid.net

Hi,

On Mon, Nov 10, 2014 at 5:30 PM, Pat David wrote:

I can't add much to the color discussion, but at least I can offer up just about any of my images as RAW for any testing (just about everything I shoot is cc-by-sa usually). If anyone finds one of mine they would like, just let me know and I'd be happy to provide the camera raw file.

I was actually gonna suggest to perhaps ask you, in particular for the "nice set of pictures of people's faces, young to old, male and female, of diverse skin colors." since I know you like to shoot people. That may be a start.
Since you forgot to add a link to your photos (maybe out of humility?), here they are: https://www.flickr.com/photos/patdavid

Unfortunately I am about the same for the actual color discussion part, and I'm not sure which photos are the best for color/printer/algorithms/other tests, but I can for instance host the test suite photos. Maybe under testimages.libreart.info or some similar URL. So I suggest that if someone on this thread thinks that this or that photo is interesting, tell me, and I'll make a test page gathering raw photos. With time, I think we should be able to gather a good suite of standard copyleft test photos.

Jehan

On Fri, Nov 7, 2014 at 1:24 PM, Elle Stone wrote:

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-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp- developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list

--
pat david
http://blog.patdavid.net
_______________________________________________ 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

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.

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.

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. 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.

It would be good if images have neutral gray cards / gradients of some sort in them, although that is obviously not always possible.

Gary

On Tue, Nov 11, 2014 at 9:15 AM, Elle Stone wrote:

*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.

I have used this image for a wide variety of testing, mostly to do with printing:
http://www.pixl.dk/download/ (first link)

(note to prudes, there is a woman's bare bottom included ;)

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.

The 2002 version contains a *wide* variety of things that can go spectacularly wrong when printing (eg for one, over saturation of black completely destroys the image of the watch), and was a real life saver when I was setting up the workflow of: Workstation -> Digital RIP -> Large Format Printer. It's a beastly image to try and print correctly, and I imagine the 2009 version is just as devious :)

/goes back to munching popcorn and lurking on the color threads...

Chris

On 11/11/14 17:32, Chris Mohler wrote:

The 2002 version contains a *wide* variety of things that can go spectacularly wrong when printing (eg for one, over saturation of black completely destroys the image of the watch), and was a real life saver when I was setting up the workflow of: Workstation -> Digital RIP -> Large Format Printer. It's a beastly image to try and print correctly, and I imagine the 2009 version is just as devious :)

For the curious and not overly competent, can you shed some light on the kinds of issues you had and how you dealt with them?

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). ​

pat david
http://blog.patdavid.net

Hi,

On Thu, Nov 13, 2014 at 2:32 AM, 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).

Yes I wanted to make a point about this as well, and I forgot. Thanks for reminding. On the legal point of view, I think we will need to have:
1/ the explicit agreement of the photographer (licensing); 2/ the explicit agreement of the model (or their legal representative, i.e. parents usually when they are underage) if there are human being shown and recognizable in the photograph.

This way, we make sure to have photos usable under any circumstances. That's more bothering, but better be safe than sorry.

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).

Well if that costs you money (renting camera/model) and is done for this specific task, I would be for crowdfunding a bit. Unless that's not your sole purpose and you are planning to use these photos somehow else.
Otherwise I don't think we are in a hurry, and the set can also be gathered slowly with time and patience (when a photograph hires a model or is hired for some usual shooting purpose, one can just ask the model if he'd accept some photos, and which ones, to be used in a test set).

Jehan

--
pat david
http://blog.patdavid.net
_______________________________________________ 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

Hi,

On Thu, Nov 13, 2014 at 1:55 PM, Elle Stone wrote:

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.

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

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.
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.
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).

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?

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.
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. My main purpose here is to improve Free Software and Graphics environment. :-)

Jehan

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

Jehan Pags (jehan.marmottard@gmail.com) wrote:

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

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?

(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...)

Bye,
Simon

simon@budig.de              http://simon.budig.de/

Hi,

On Thu, Nov 13, 2014 at 11:04 PM, Elle Stone wrote:

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.

I'll do it soon.

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.

I think I'll use TuxFamily which is my usual FLOSS community host when I'm unsure my small server will handle correctly the load. So that should not be a problem.

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 soon as I finished the website, and as you validate the way the project is presented (I'll do a small base text, but I'll expect fixes), I'll try and reach out to several graphics project. Also Steve Czajka from GIMP magazine said that if we can put up a small text before the end of November, it should go into January release without much problem (apparently GIMP magazine is getting monthly from now on). So we should be able to gather interested people this way, I hope. :-)

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?

I guess it is.

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.

Ok. :-)

Jehan

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

Hi Elle, Pat and others,

On Thu, Nov 13, 2014 at 1:55 PM, Elle Stone wrote:

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.

You said on the babl/gegl discussion that you'd be unsubscribing from the GIMP mailing lists. So first, I hope you'll stay in contact, and subscribe again at some point, and even more I sincerely hope we'll meet you in LGM where I'm sure the discussions with other contributors will be much more productive than most of what happened on the mailing list (I don't understand enough of the technical to take position, but I feel like the problem is mostly a communication problem. And dialogging only through emails does not help, far from it).

More on topic with this thread, does it mean you also wish to get out of this small project of assembling a test suite of images? I hope not, because I am not enough of a hard-core user myself to handle the decision part (though Patrick David is definitely one, but 2 are better than 1).
I have not taken the time to do the small web page yet, but I was planning to set it up within the next week, and getting the news to users (and GIMP magazine, etc.) before end of month. Are we putting this project on hold?

Jehan

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

Gimps needs another head developer to take over the color management part. It is currently stuck in a BABL nightmare of confusion.

Hi Elle, Pat and others,

On Thu, Nov 13, 2014 at 1:55 PM, Elle Stone wrote:
You said on the babl/gegl discussion that you'd be unsubscribing from the GIMP mailing lists. So first, I hope you'll stay in contact, and subscribe again at some point, and even more I sincerely hope we'll meet you in LGM where I'm sure the discussions with other contributors will be much more productive than most of what happened on the mailing list (I don't understand enough of the technical to take position, but I feel like the problem is mostly a communication problem. And dialogging only through emails does not help, far from it).

More on topic with this thread, does it mean you also wish to get out of this small project of assembling a test suite of images? I hope not, because I am not enough of a hard-core user myself to handle the decision part (though Patrick David is definitely one, but 2 are better than 1).
I have not taken the time to do the small web page yet, but I was planning to set it up within the next week, and getting the news to users (and GIMP magazine, etc.) before end of month. Are we putting this project on hold?

Jehan