Sign up now! · Forgot password?
RSS/Atom feed identi.ca Twitter

the Gimp lcms.c plug-in

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

26 of 26 messages available
Toggle history

Please log in to manage your subscriptions.

the Gimp lcms.c plug-in Elle Stone 19 Jul 17:12
  the Gimp lcms.c plug-in John Harris 19 Jul 18:39
   the Gimp lcms.c plug-in Elle Stone 20 Jul 21:46
    the Gimp lcms.c plug-in Øyvind Kolås 20 Jul 22:14
     the Gimp lcms.c plug-in Elle Stone 20 Jul 22:41
      the Gimp lcms.c plug-in Elle Stone 24 Jul 15:47
       the Gimp lcms.c plug-in Michael Schumacher 24 Jul 19:40
        the Gimp lcms.c plug-in Elle Stone 24 Jul 21:00
         the Gimp lcms.c plug-in Michael Schumacher 24 Jul 21:10
          the Gimp lcms.c plug-in Elle Stone 24 Jul 21:16
           the Gimp lcms.c plug-in Michael Schumacher 24 Jul 21:29
            the Gimp lcms.c plug-in Elle Stone 24 Jul 21:37
             the Gimp lcms.c plug-in Jernej Simončič 24 Jul 21:58
              the Gimp lcms.c plug-in Elle Stone 24 Jul 22:30
              the Gimp lcms.c plug-in Burnie West 25 Jul 03:50
             the Gimp lcms.c plug-in Michael Natterer 25 Jul 08:20
              the Gimp lcms.c plug-in Elle Stone 25 Jul 12:25
               the Gimp lcms.c plug-in Alexandre Prokoudine 25 Jul 21:39
               the Gimp lcms.c plug-in Burnie West 26 Jul 03:36
        the Gimp lcms.c plug-in Elle Stone 26 Jul 15:42
         the Gimp lcms.c plug-in Elle Stone 13 Aug 19:17
          the Gimp lcms.c plug-in Elle Stone 14 Aug 11:34
           the Gimp lcms.c plug-in Elle Stone 27 Aug 14:08
            the Gimp lcms.c plug-in Øyvind Kolås 27 Aug 18:47
             the Gimp lcms.c plug-in Elle Stone 28 Aug 18:03
              the Gimp lcms.c plug-in Elle Stone 29 Aug 13:47
Elle Stone
2012-07-19 17:12:21 UTC (over 1 year ago)

the Gimp lcms.c plug-in

I've been working on porting the Gimp lcms.c plug-in from using LittleCMS version 1 to using LittleCMS version 2. This will make possible high bit-depth ICC profile conversions.

I'm not a super-experienced c-coder, nor have I ever worked with the lcms engine before. So I'm learning as I go. So far I've: (1)compiled the existing Gimp lcms plug-in, (2)modified the existing plug-in to use lcms2.h and attempted to compile it (knowing it would fail)
(3)tracked down all the errors and warnings that result from the differences between LittleCMS version 1 and LittleCMS version 2

My next steps will be to add a whole bunch of "print to screen" commands to the current Gimp lcms.c plug-in so I can get a better handle on the flow of the code, and then start rewriting (or perhaps writing from scratch) the plug-in to use the LittleCMS v2 engine.

If anyone is curious, I've documented what I've done so far:

http://ninedegreesbelow.com/temp/gimp-lcms-1.html http://ninedegreesbelow.com/temp/gimp-lcms-2.html

Comments, input is more than welcome.

I have a couple of big-picture questions:

Will Gimp be using as its internal working space some variant of Microsoft's scRGB? What about:

Wikipedia: http://en.wikipedia.org/wiki/Scrgb "scRGB is a wide color gamut RGB (Red Green Blue) color space created by Microsoft and HP that uses the same color primaries and white/black points as the sRGB color space but allows coordinates below zero and greater than one. . . . the cost of maintaining compatibility with sRGB is that approximately 80% of the scRGB color space consists of imaginary colors."

"Two encodings are defined for the individual primaries: a linear 16 bit per channel encoding and a nonlinear 12 bit per channel encoding. . . The 16 bit scRGB(16) encoding is the linear RGB channels converted by 8192 x + 4096. Compared to 8-bit sRGB this ranges from about 1/2 the color resolution near 0.0 to more than 10 times the color resolution
near 1.0."

That last sentence is a bit worrisome - losing resolution in the shadow areas.

It seems to me that you will always need ICC profiles, to convert an image from whatever ICC color space profile it happens to be in, to your internal working space, and from your internal working space to the monitor profile, and from your internal working space back out to whatever color space profile the person wants to use to upon exporting to a non-xcf file. Yes? No?

Elle

John Harris
2012-07-19 18:39:55 UTC (over 1 year ago)

the Gimp lcms.c plug-in

Elle, I am not a programmer but I am a color professional. so here is my input regarding your last question:

It seems to me that you will always need ICC profiles, to convert an image from whatever ICC color space profile it happens to be in, to your internal working space, and from your internal working space to the monitor profile, and from your internal working space back out to whatever color space profile the person wants to use to upon exporting to a non-xcf file. Yes? No?

"always" is a bit strong. Some individuals, such as myself, prefer to do as little profile swapping as possible, and in some cases work in complete native spaces during the entire flow. Display calibration excluded.

I rarely take an incoming file from it's native space to some other working space unless the file needs extreme adjustments. So converting from native to working is not a given. There will be some situations where I will send the image file directly to the output device without a conversion to the output profile. An output profile should be able to be used in soft-proofing without the need for conversion to profile. The Adobe workflow refers to this as "Preserve RGB". Having this option allows me and other users to proof the output on screen and never convert the file to any profile, thus keeping the working file in it's fullest integrity, free of banding, loss of color fidelity and other profile related issues that can result from remapping.

There may also be times when I will maintain the files native space but print using a convert to profile flow, and there are times when I DO convert from the native space to a larger space. The latter is often the case when the file needs major adjustments for density and contrast. I may also go from a larger space, such as ProRGB or Adobe1998 down to sRGB if I am working a file that will only see usage on the web and never go to wide gamut print.

Feel free to reach out to me with specific questions that might be off-topic.

On 07/19/2012 11:12 AM, Elle Stone wrote:

I've been working on porting the Gimp lcms.c plug-in from using LittleCMS version 1 to using LittleCMS version 2. This will make possible high bit-depth ICC profile conversions.

I'm not a super-experienced c-coder, nor have I ever worked with the lcms engine before. So I'm learning as I go. So far I've: (1)compiled the existing Gimp lcms plug-in, (2)modified the existing plug-in to use lcms2.h and attempted to compile it (knowing it would fail)
(3)tracked down all the errors and warnings that result from the differences between LittleCMS version 1 and LittleCMS version 2

My next steps will be to add a whole bunch of "print to screen" commands to the current Gimp lcms.c plug-in so I can get a better handle on the flow of the code, and then start rewriting (or perhaps writing from scratch) the plug-in to use the LittleCMS v2 engine.

If anyone is curious, I've documented what I've done so far:

http://ninedegreesbelow.com/temp/gimp-lcms-1.html http://ninedegreesbelow.com/temp/gimp-lcms-2.html

Comments, input is more than welcome.

I have a couple of big-picture questions:

Will Gimp be using as its internal working space some variant of Microsoft's scRGB? What about:

Wikipedia: http://en.wikipedia.org/wiki/Scrgb "scRGB is a wide color gamut RGB (Red Green Blue) color space created by Microsoft and HP that uses the same color primaries and white/black points as the sRGB color space but allows coordinates below zero and greater than one. . . . the cost of maintaining compatibility with sRGB is that approximately 80% of the scRGB color space consists of imaginary colors."

"Two encodings are defined for the individual primaries: a linear 16 bit per channel encoding and a nonlinear 12 bit per channel encoding. . . The 16 bit scRGB(16) encoding is the linear RGB channels converted by 8192 x + 4096. Compared to 8-bit sRGB this ranges from about 1/2 the color resolution near 0.0 to more than 10 times the color resolution
near 1.0."

That last sentence is a bit worrisome - losing resolution in the shadow areas.

It seems to me that you will always need ICC profiles, to convert an image from whatever ICC color space profile it happens to be in, to your internal working space, and from your internal working space to the monitor profile, and from your internal working space back out to whatever color space profile the person wants to use to upon exporting to a non-xcf file. Yes? No?

Elle

Elle Stone
2012-07-20 21:46:00 UTC (over 1 year ago)

the Gimp lcms.c plug-in

Hi, John,

By "native space" do you mean whatever color space the image happens to be in when you open it? As per the jpegs generated by my point-and-shoot are all in the sRGB color space? Or if someone hands me a file in the AdobeRGB color space, then that file's "native" color space is AdobeRGB? If this is what you mean by "native color space", then I agree with you 100% - converting from one color space to another without a good reason is pointless and can potentially have bad effects on image integrity.

The "internal working space" I was asking about is something else altogether. I am under the impression that Gimp either already does, or is planning to, use a very large internal working space, which internal working space will be completely beyond the end user's control.

So the admittedly ambiguous phrase I used, "your internal working space", was referring to Gimp's internal working space, if in fact Gimp either already uses, or is planning to use such a thing. I wasn't referring to whatever working space a user might have specified in Gimp's color management settings, but I can see how my wording was ambiguous.

I was hoping for some very brief answers to the following questions:

1. Is my impression correct? Is Gimp planning to use a very large internal working space for all image manipulation? If the answer is "No", ignore questions 2, 3, and 4.

2. If so, is that color space something like scRGB mentioned in the Wikipedia article?

3. If so, what about shadow detail (a problem mentioned in the Wikipedia article)?

4. If so, will there still be a need for ICC profile conversions (I can't imagine what the alternative might be, but that doesn't mean there isn't an alternative) from the image's "native space" (if I understand your usage of the phrase correctly) to Gimp's very large internal working space (and back out to whatever output space the user wants upon exporting the image, and also to display the image on the monitor screen)?

Elle

On 7/19/12, John Harris wrote:

Elle, I am not a programmer but I am a color professional. so here is my input regarding your last question:

It seems to me that you will always need ICC profiles, to convert an image from whatever ICC color space profile it happens to be in, to your internal working space, and from your internal working space to the monitor profile, and from your internal working space back out to whatever color space profile the person wants to use to upon exporting to a non-xcf file. Yes? No?

"always" is a bit strong. Some individuals, such as myself, prefer to do as little profile swapping as possible, and in some cases work in complete native spaces during the entire flow. Display calibration excluded.

I rarely take an incoming file from it's native space to some other working space unless the file needs extreme adjustments. So converting from native to working is not a given. There will be some situations where I will send the image file directly to the output device without a conversion to the output profile. An output profile should be able to be used in soft-proofing without the need for conversion to profile. The Adobe workflow refers to this as "Preserve RGB". Having this option allows me and other users to proof the output on screen and never convert the file to any profile, thus keeping the working file in it's fullest integrity, free of banding, loss of color fidelity and other profile related issues that can result from remapping.

There may also be times when I will maintain the files native space but print using a convert to profile flow, and there are times when I DO convert from the native space to a larger space. The latter is often the case when the file needs major adjustments for density and contrast. I may also go from a larger space, such as ProRGB or Adobe1998 down to sRGB if I am working a file that will only see usage on the web and never go to wide gamut print.

Feel free to reach out to me with specific questions that might be off-topic.

On 07/19/2012 11:12 AM, Elle Stone wrote:

I've been working on porting the Gimp lcms.c plug-in from using LittleCMS version 1 to using LittleCMS version 2. This will make possible high bit-depth ICC profile conversions.

I'm not a super-experienced c-coder, nor have I ever worked with the lcms engine before. So I'm learning as I go. So far I've: (1)compiled the existing Gimp lcms plug-in, (2)modified the existing plug-in to use lcms2.h and attempted to compile it (knowing it would fail)
(3)tracked down all the errors and warnings that result from the differences between LittleCMS version 1 and LittleCMS version 2

My next steps will be to add a whole bunch of "print to screen" commands to the current Gimp lcms.c plug-in so I can get a better handle on the flow of the code, and then start rewriting (or perhaps writing from scratch) the plug-in to use the LittleCMS v2 engine.

If anyone is curious, I've documented what I've done so far:

http://ninedegreesbelow.com/temp/gimp-lcms-1.html http://ninedegreesbelow.com/temp/gimp-lcms-2.html

Comments, input is more than welcome.

I have a couple of big-picture questions:

Will Gimp be using as its internal working space some variant of Microsoft's scRGB? What about:

Wikipedia: http://en.wikipedia.org/wiki/Scrgb "scRGB is a wide color gamut RGB (Red Green Blue) color space created by Microsoft and HP that uses the same color primaries and white/black points as the sRGB color space but allows coordinates below zero and greater than one. . . . the cost of maintaining compatibility with sRGB is that approximately 80% of the scRGB color space consists of imaginary colors."

"Two encodings are defined for the individual primaries: a linear 16 bit per channel encoding and a nonlinear 12 bit per channel encoding. . . The 16 bit scRGB(16) encoding is the linear RGB channels converted by 8192 x + 4096. Compared to 8-bit sRGB this ranges from about 1/2 the color resolution near 0.0 to more than 10 times the color resolution
near 1.0."

That last sentence is a bit worrisome - losing resolution in the shadow areas.

It seems to me that you will always need ICC profiles, to convert an image from whatever ICC color space profile it happens to be in, to your internal working space, and from your internal working space to the monitor profile, and from your internal working space back out to whatever color space profile the person wants to use to upon exporting to a non-xcf file. Yes? No?

Elle

Øyvind Kolås
2012-07-20 22:14:25 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On Fri, Jul 20, 2012 at 11:46 PM, Elle Stone wrote:

Hi, John,
By "native space" do you mean whatever color space the image > 1. Is my impression correct? Is Gimp planning to use a very large internal working space for all image manipulation? If the answer is "No", ignore questions 2, 3, and 4.

Yep, implicit in GEGL and babls architectures is making intermediate results be stored in buffers of floating point precision without clamping/etc at the gamut (allowing as wide gamut as needed by the data)

2. If so, is that color space something like scRGB mentioned in the Wikipedia article?

It is similar - best summed up, it is RGB stored with linear/physical light - using the sRGB RGB primaries - stored as half or single precision floating point (not 8bit or 15/16bit per component fixed point).

3. If so, what about shadow detail (a problem mentioned in the Wikipedia article)?

That sounds like a problem only relevant to low bidepth fixed point representations.

4. If so, will there still be a need for ICC profile conversions (I can't imagine what the alternative might be, but that doesn't mean there isn't an alternative) from the image's "native space" (if I understand your usage of the phrase correctly) to Gimp's very large internal working space (and back out to whatever output space the user wants upon exporting the image, and also to display the image on the monitor screen)?

As we move along towards embracing a fully GEGLified workflow, different things will happen at different times. The initial thing to reach for is likely to support the 2.8 era manual colormanagement. With a fully GEGLified system there will still be the need to use ICC based conversions to pixel formats efficiently dealt with by babl/GEGL/GIMP as well as do final transforms for display / export.

/yvind K. .--
The future is already here. It's just not very evenly distributed -- William Gibson http://pippin.gimp.org/ http://ffii.org/

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Elle Stone
2012-07-20 22:41:41 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On 7/20/12, yvind Kols wrote:

As we move along towards embracing a fully GEGLified workflow, different things will happen at different times. The initial thing to reach for is likely to support the 2.8 era manual colormanagement. With a fully GEGLified system there will still be the need to use ICC based conversions to pixel formats efficiently dealt with by babl/GEGL/GIMP as well as do final transforms for display / export.

Thanks! Now I have a better idea of the big picture regarding the lcms plug-in. I've had a chance to dig into the code and see what the different functions do and when they are called. It looks like converting the lcms.c plug-in to use lcms2 will be pretty easy to do. Which means really high bit depth conversions should also be not too difficult. But one step at a time.

Elle

http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Elle Stone
2012-07-24 15:47:19 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On 7/20/12, Elle Stone wrote:

On 7/20/12, yvind Kols wrote:

As we move along towards embracing a fully GEGLified workflow, different things will happen at different times. The initial thing to reach for is likely to support the 2.8 era manual colormanagement. With a fully GEGLified system there will still be the need to use ICC based conversions to pixel formats efficiently dealt with by babl/GEGL/GIMP as well as do final transforms for display / export.

Thanks! Now I have a better idea of the big picture regarding the lcms plug-in. I've had a chance to dig into the code and see what the different functions do and when they are called. It looks like converting the lcms.c plug-in to use lcms2 will be pretty easy to do. Which means really high bit depth conversions should also be not too difficult. But one step at a time.

Just an update. I rewrote the existing Gimp lcms.c plug-in to use lcm2. It seems to work just like the current Gimp plug-in. If anyone is interested in testing it, I can supply the code.

As explained here: http://ninedegreesbelow.com/temp/gimp-lcms-3.html (see summary at bottom of page), there are some coding issues to be resolved before attempting to make the lcms2 plug-in do high-bit-depth color conversions. So dealing with the coding issues is my next step.

Also, has anyone seen this Ubuntu bug report? Completely replace lcms1 by lcms2 in Ubuntu https://bugs.launchpad.net/ubuntu/+source/lcms/+bug/885324

Kind regards, Elle

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Michael Schumacher
2012-07-24 19:40:16 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On 24.07.2012 17:47, Elle Stone wrote:

Just an update. I rewrote the existing Gimp lcms.c plug-in to use lcm2. It seems to work just like the current Gimp plug-in. If anyone is interested in testing it, I can supply the code.

Also, has anyone seen this Ubuntu bug report? Completely replace lcms1 by lcms2 in Ubuntu https://bugs.launchpad.net/ubuntu/+source/lcms/+bug/885324

Hi Elle,

there are two bug reports in Bugzilla about changes in GIMP related to lcms2:

This one introduces lcms2 to get support for ICC V4 profiles: https://bugzilla.gnome.org/show_bug.cgi?id=662739

That one has been created to move everything to lcms2 to counter some performance problems:
https://bugzilla.gnome.org/show_bug.cgi?id=675558

I'm not sure if you are aware of them. Both have patches attached, and you should check if any of them - in particular the latter - is a duplication of your efforts.

HTH, Michael

Elle Stone
2012-07-24 21:00:23 UTC (over 1 year ago)

the Gimp lcms.c plug-in

Yes, it looks like both of them are concerned with exactly what I've been trying to do. Sigh.

As I'm working with Gimp 2.9 from git,

and have no clue how Gimp development works, and only got involved because I really want Gimp color conversion to use high bit-depth, and my impression was that making this happen is not exactly a high priority item for Gimp and right now Gimp from git is doing 8-bit color conversions,

may I ask why the Gimp from git that I'm using (which is really recent, July 13, 2012) is still using lcms1 if there are patches for lcms2?

Elle

On 7/24/12, Michael Schumacher wrote:

On 24.07.2012 17:47, Elle Stone wrote:

Just an update. I rewrote the existing Gimp lcms.c plug-in to use lcm2. It seems to work just like the current Gimp plug-in. If anyone is interested in testing it, I can supply the code.

Also, has anyone seen this Ubuntu bug report? Completely replace lcms1 by lcms2 in Ubuntu https://bugs.launchpad.net/ubuntu/+source/lcms/+bug/885324

Hi Elle,

there are two bug reports in Bugzilla about changes in GIMP related to lcms2:

This one introduces lcms2 to get support for ICC V4 profiles: https://bugzilla.gnome.org/show_bug.cgi?id=662739

That one has been created to move everything to lcms2 to counter some performance problems:
https://bugzilla.gnome.org/show_bug.cgi?id=675558

I'm not sure if you are aware of them. Both have patches attached, and you should check if any of them - in particular the latter - is a duplication of your efforts.

HTH, Michael
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Michael Schumacher
2012-07-24 21:10:34 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On 24.07.2012 23:00, Elle Stone wrote:

may I ask why the Gimp from git that I'm using (which is really recent, July 13, 2012) is still using lcms1 if there are patches for lcms2?

Because no one has tried and applied the patches yet.

HTH, Michael

Elle Stone
2012-07-24 21:16:12 UTC (over 1 year ago)

the Gimp lcms.c plug-in

How does one apply a patch? What does "apply a patch" mean?

On 7/24/12, Michael Schumacher wrote:

On 24.07.2012 23:00, Elle Stone wrote:

may I ask why the Gimp from git that I'm using (which is really recent, July 13, 2012) is still using lcms1 if there are patches for lcms2?

Because no one has tried and applied the patches yet.

Michael Schumacher
2012-07-24 21:29:54 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On 24.07.2012 23:16, Elle Stone wrote:

How does one apply a patch? What does "apply a patch" mean?

You use the patch program to apply the changes that are contained in the attachments to the bug report to the GIMP code.

The usage example from the Wikipedia article about patch should do: http://en.wikipedia.org/wiki/Patch_%28Unix%29

patch < foo.diff

This could be executed in the top directory of your GIMP source tree.

There are parameters to adjust for differences in the diff files regarding both your and the patch author's systems, see http://linux.die.net/man/1/patch - -p is the most commonly used parameter to get rid of leading folders in the paths used in the diff file, for example.

Elle Stone
2012-07-24 21:37:16 UTC (over 1 year ago)

the Gimp lcms.c plug-in

Perhaps what I really should be asking is what is the process by which an existing patch to the Gimp code is applied so that everyone can use it?

In particular, by what process does Gimp get patched to use lcms2? ( I kinda doubt that the Gimp developers are going to let Elle Stone patch Gimp, as the chances are very great that Elle Stone would break Gimp in the process.)

I don't need to patch my own copy of Gimp. It's already using lcms2.

On 7/24/12, Michael Schumacher wrote:

On 24.07.2012 23:16, Elle Stone wrote:

How does one apply a patch? What does "apply a patch" mean?

You use the patch program to apply the changes that are contained in the attachments to the bug report to the GIMP code.

The usage example from the Wikipedia article about patch should do: http://en.wikipedia.org/wiki/Patch_%28Unix%29

patch < foo.diff

This could be executed in the top directory of your GIMP source tree.

There are parameters to adjust for differences in the diff files regarding both your and the patch author's systems, see http://linux.die.net/man/1/patch - -p is the most commonly used parameter to get rid of leading folders in the paths used in the diff file, for example.

--
HTH,
Michael
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Jernej Simončič
2012-07-24 21:58:08 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On Tuesday, July 24, 2012, 23:37:16, Elle Stone wrote:

In particular, by what process does Gimp get patched to use lcms2? ( I kinda doubt that the Gimp developers are going to let Elle Stone patch Gimp, as the chances are very great that Elle Stone would break Gimp in the process.)

If you started by checking out the source from git, just run git diff > lcms2.patch

If you instead used the source tarball, it's a bit more work.

If you only changed a single file, the simplest way to create a patch is to get the copy of original file, put it in the same directory as the changed file with a different extension (eg. file.c.orig), then create a patch like this:

diff -u file.c.orig file.c > lcms2.patch

If you modified several files, it's slightly more involved: you will need a clean source tree (from the source tarball), and your patched version, each in it's own subdirectory. You should run make distclean in your tree (if you compiled from it), to ensure that none of the files that get generated during build are left behind. Assuming the clean tree is in gimp-2.8.0.orig/, and your patched version is in gimp-2.8.0/, you create the patch with:

diff -Naur gimp-2.8.0.orig gimp-2.8.0 > lcms2.patch

Elle Stone
2012-07-24 22:30:58 UTC (over 1 year ago)

the Gimp lcms.c plug-in

Jernej, thanks! That is a very clear explanation of how to use patch.

Burnie West
2012-07-25 03:50:02 UTC (over 1 year ago)

the Gimp lcms.c plug-in

This is beautiful, Jernej - I've moved this entire conversation to my gimp-developer/coding help subdirectory.

Thanks.

On 07/24/2012 02:58 PM, Jernej Simončič wrote:

On Tuesday, July 24, 2012, 23:37:16, Elle Stone wrote:

In particular, by what process does Gimp get patched to use lcms2? ( I kinda doubt that the Gimp developers are going to let Elle Stone patch Gimp, as the chances are very great that Elle Stone would break Gimp in the process.)

If you started by checking out the source from git, just run git diff > lcms2.patch

If you instead used the source tarball, it's a bit more work.

If you only changed a single file, the simplest way to create a patch is to get the copy of original file, put it in the same directory as the changed file with a different extension (eg. file.c.orig), then create a patch like this:

diff -u file.c.orig file.c > lcms2.patch

If you modified several files, it's slightly more involved: you will need a clean source tree (from the source tarball), and your patched version, each in it's own subdirectory. You should run make distclean in your tree (if you compiled from it), to ensure that none of the files that get generated during build are left behind. Assuming the clean tree is in gimp-2.8.0.orig/, and your patched version is in gimp-2.8.0/, you create the patch with:

diff -Naur gimp-2.8.0.orig gimp-2.8.0 > lcms2.patch

Michael Natterer
2012-07-25 08:20:15 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On Tue, 2012-07-24 at 17:37 -0400, Elle Stone wrote:

Perhaps what I really should be asking is what is the process by which an existing patch to the Gimp code is applied so that everyone can use it?

Your way of doing patches *and* actively communicating is the only way that will guarantee your patches to land. We are short on resources, and naturally active community members are harder to forget, as opposed to patches sitting in bugzilla.

So please, just go ahead, look at the patches in bugzilla, pick the best stuff from your patches and the bugzilla ones, and all will be fine.

In particular, by what process does Gimp get patched to use lcms2? ( I kinda doubt that the Gimp developers are going to let Elle Stone patch Gimp, as the chances are very great that Elle Stone would break Gimp in the process.)

Breaking gimp at least once is part of the initiation ceremony, don't worry ;)

I don't need to patch my own copy of Gimp. It's already using lcms2.

On 7/24/12, Michael Schumacher wrote:

On 24.07.2012 23:16, Elle Stone wrote:

How does one apply a patch? What does "apply a patch" mean?

You use the patch program to apply the changes that are contained in the attachments to the bug report to the GIMP code.

The usage example from the Wikipedia article about patch should do: http://en.wikipedia.org/wiki/Patch_%28Unix%29

patch < foo.diff

This could be executed in the top directory of your GIMP source tree.

There are parameters to adjust for differences in the diff files regarding both your and the patch author's systems, see http://linux.die.net/man/1/patch - -p is the most commonly used parameter to get rid of leading folders in the paths used in the diff file, for example.

--
HTH,
Michael
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Elle Stone
2012-07-25 12:25:10 UTC (over 1 year ago)

the Gimp lcms.c plug-in

So please, just go ahead, look at the patches in bugzilla, pick the best stuff from your patches and the bugzilla ones, and all will be fine.

OK, I'm working on it. And I promise to keep communicating actively. I'm making two Gimp from git installations, one for the existing lcms2 patches (thank you! Michael Schumacher, for pointing the two patches out to me) and one for the lcms2 code that I'm writing.

On a related note, I reported a bug back in 2010: https://bugzilla.gnome.org/show_bug.cgi?id=620781 (I changed my website domain, the link I gave in the bug report is no longer available). That bug still persists in Gimp 2.8/2.9 if the sRGB to which one is converting to, starting with a linear gamma image, is "sRGB built-in". However, using my lcms.c plugin using lcms2.h, that bug disappears. I need to do some more testing, but there is a more subtle bug, also involving conversions to and from a linear gamma color space, that also seems to no longer be a problem when using my lcms2 plug-in.

We are short on
resources, and naturally active community members are harder to forget, as opposed to patches sitting in bugzilla.

It always surprises me how few people are working on a project as big, important, and widely used as Gimp.

Alexandre Prokoudine
2012-07-25 21:39:55 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On Wed, Jul 25, 2012 at 4:25 PM, Elle Stone wrote:

On a related note, I reported a bug back in 2010: https://bugzilla.gnome.org/show_bug.cgi?id=620781 (I changed my website domain, the link I gave in the bug report is no longer available). That bug still persists in Gimp 2.8/2.9 if the sRGB to which one is converting to, starting with a linear gamma image, is "sRGB built-in". However, using my lcms.c plugin using lcms2.h, that bug disappears. I need to do some more testing, but there is a more subtle bug, also involving conversions to and from a linear gamma color space, that also seems to no longer be a problem when using my lcms2 plug-in.

By the way, there is a recent change that you probably want to be aware of, in case the next update of LCMS v2.x is soon.

https://github.com/mm2/Little-CMS/commit/8b13ad6a80ce0f2e19301083c4313988ae0f8c38

Alexandre Prokoudine http://libregraphicsworld.org

Burnie West
2012-07-26 03:36:00 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On 07/25/2012 05:25 AM, Elle Stone wrote:

It always surprises me how few people are working on a project as big, important, and widely used as Gimp.

I'd love to work on it, but I can't keep up with the starting point :-)

Elle Stone
2012-07-26 15:42:39 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On 7/24/12, Michael Schumacher wrote:

there are two bug reports in Bugzilla about changes in GIMP related to lcms2:

This one introduces lcms2 to get support for ICC V4 profiles: https://bugzilla.gnome.org/show_bug.cgi?id=662739

That one has been created to move everything to lcms2 to counter some performance problems:
https://bugzilla.gnome.org/show_bug.cgi?id=675558

I'm not sure if you are aware of them. Both have patches attached, and you should check if any of them - in particular the latter - is a duplication of your efforts.

Patches compared:
I've checked both patches, line for line comparing each patch to the code changes that I've made so far to convert the Gimp lcms.c plug-in to use lcms2.

Both patches cover *all* the source code files that are affected by a port from lcms to lcms2 (not just the lcms.c file itself). So far I've only worked on the actual lcms.c plug-in code. Before working on the other files myself, I want to add "printf" statements to the other relevant source code files so I can get a better idea of how all of Gimp color management hangs together. In particular, I want to track down where/why Gimp doesn't offer the user the option of using or not using black point compensation with the user-chosen monitor profile/conversion intent.

Both patches are similar to what I've written so far. The second patch lcms.c code is very, very close to what I've written and the first patch already does some of what was on my "to do" list:

1. Retrieving textual information: The first patch code replaces the three existing information collecting functons (that all actually produce the same information), and adds code that collects additional information (model, copyright, etc). The second patch and my own code both use a "three to one" workaround (keeping more of the original code intact, not necessarily a plus, but perhaps a safer first move). Also the first patch directly uses the lcms2 UTF8 information, rather than getting the ascii information and passing it to Gimp to change to UTF8 - a definite plus, it seems to me.

2. Error Handling (bad profiles, lcms errors in conversions, etc): The first patch keeps the existing non-functioning error code reporting intact. The second patch and my own code both eliminate the non-functioning error code. Ideally there should be some error code reporting/some way to detect and deal with bad profiles. But based on testing as well as examining the code, the existing code doesn't do anything at all. I have located examples of functioning lcms1 and presumably functioning lcms2 error handling, but haven't tried to incorporate same.

3. Checksum: Both patches update to lcms2 some MD5 code that I've temporarily commented out. I commented the code out partly because I hadn't found the right code to replace the old code, and mostly because I don't understand the point of calculating the MD5 of the profile header (to make sure you still have the profile you just opened??). See functions "lcms_calculate_checksum" and the no doubt related "lcms_sRGB_checksum". What is a "digest"? Why calculate the MD5 of the profile header?

The next steps: Based on the code, both patches look like they would probably work just fine. My next step is to actually apply the patches (separately, of course) and see if/how well the patches work in practice. And then pick and choose the best bits of each patch. It will be several days (at least) before I finish this next step.

Bug fix? enhancement? It seems to me that porting to use lcms2 is both a fix for some bugs (wrong results when converting from a linear gamma to the Gimp sRGB built in profile; inability to read V4 profiles, which are becoming more and more common), and also an enhancement in terms of speed, based on reports by others. And of course lcms2 is a prerequisite for 32-bit floating point ICC profile conversions.

Alexandre, thanks! for the link to the upcoming lcms2 changes regarding supported floating point variants.

Elle Stone
2012-08-13 19:17:07 UTC (over 1 year ago)

the Gimp lcms.c plug-in

I posted an update to my effort to port the lcms plugin to lcms2 and get it to do high-bit-depth color conversions:

http://ninedegreesbelow.com/temp/gimp-lcms-4.html

Summary of current state of plugin:

It uses lcms2. It does high bit depth conversions, but some options are not available yet. It still uses deprecated functions.

Black point compensation flag has been temporarily removed (easy to add back in, just haven't done it yet).

The code doesn't check for an alpha channel, and won't work if the image has an alpha channel (easy to add, just haven't done it yet).

The code will convert at 8-bit integer, 16-bit integer and 32-bit floating point (only, so far).

The ICC profile conversion is seemingly correct only if the starting profile is a linear gamma version of sRGB and the ending profile is the Gimp built-in sRGB, or vice versa.

Upon converting to any other ICC profile, the colors come out all wrong (confirm by opening in another application and eye-droppering). ***However***, upon:

*exporting the odd-looking image anyway (and confirming that the numbers are wrong in another imaging application) *closing and reopening Gimp (not a necessary step, but eliminates the possibility of "right values" somehow being in memory) *reopening the exported image (which still looks odd) *and then converting it to built-in sRGB or to linear sRGB

. . . then the colors are magically right. Which is both bizarre and wrong.

Elle

Elle Stone
2012-08-14 11:34:05 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On 8/13/12, Elle Stone wrote:

Upon converting to any other ICC profile, the colors come out all wrong . . . then the colors are magically right. Which is both bizarre and wrong.

A coding error/oversight on my part is the answer to the "magically right": the new profile is embedded even if the conversion didn't really happen.

Elle

Elle Stone
2012-08-27 14:08:46 UTC (over 1 year ago)

the Gimp lcms.c plug-in

My lcms2 plug-in now does do correct ICC profile conversions, from any RGB color space, to any RGB color space, at 8-bit integer, 16-bit integer, and 32-bit floating point.

However, to get it to work, I had to modify the babl/babl/util.h file.

After modifying the babl/babl/util.h file, 16-bit tiffs open correctly. As you might recall, with the default util.h file, 16-bit tiffs open with a mysterious and erroneous "gamma=2.2 correction" having been applied. This tiff issue has nothing to do with the lcms plug-in.

I realize that modifying a babl file might be a controversial move on my part. But I would ask you to look at this web page before dismissing what I've done:
http://ninedegreesbelow.com/temp/gimp-lcms-5.html

The modified babl/babl/util.h code can be found here: http://ninedegreesbelow.com/temp/gimp-lcms-4.html

Elle

Øyvind Kolås
2012-08-27 18:47:45 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On Mon, Aug 27, 2012 at 4:08 PM, Elle Stone wrote:

My lcms2 plug-in now does do correct ICC profile conversions, from any RGB color space, to any RGB color space, at 8-bit integer, 16-bit integer, and 32-bit floating point.

However, to get it to work, I had to modify the babl/babl/util.h file.

This is great news, since it means that the code works as intenended but probably with slightly different intentions.

After modifying the babl/babl/util.h file, 16-bit tiffs open correctly. As you might recall, with the default util.h file, 16-bit tiffs open with a mysterious and erroneous "gamma=2.2 correction" having been applied. This tiff issue has nothing to do with the lcms plug-in.

Data stored for higher bitdepths per pixel than 8 are assumed to be stored with a linear gamma ramp, a higher level code where you probably could do a similar tweak without changing core babl behavior could be in ... digging through GIMP code ... gimp/app/gegl/gimp-babl.c which contains code determining the data expected to be managed, for all arbitrary profile source imagery it would be recommended to store layer data in floating point.

/yvind K.

The future is already here. It's just not very evenly distributed
                                                 -- William Gibson
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Elle Stone
2012-08-28 18:03:22 UTC (over 1 year ago)

the Gimp lcms.c plug-in

On 8/27/12, yvind Kols wrote:

On Mon, Aug 27, 2012 at 4:08 PM, Elle Stone wrote:

My lcms2 plug-in now does do correct ICC profile conversions, from any RGB color space, to any RGB color space, at 8-bit integer, 16-bit integer, and 32-bit floating point.

However, to get it to work, I had to modify the babl/babl/util.h file.

This is great news, since it means that the code works as intenended but probably with slightly different intentions.

Could you clarify? which code works with which intentions?

After modifying the babl/babl/util.h file, 16-bit tiffs open correctly. As you might recall, with the default util.h file, 16-bit tiffs open with a mysterious and erroneous "gamma=2.2 correction" having been applied. This tiff issue has nothing to do with the lcms plug-in.

Data stored for higher bitdepths per pixel than 8 are assumed to be stored with a linear gamma ramp,

ICC V2 matrix profiles (simplest case here) have two parts that are relevant to the present discussion:

1. They have RGB/XYZ primaries, the chromaticity coordinates that "interpret" if you will the chroma part of the image RGB values.

2. They have a tone response curve (TRC) that determines how fast the image RGB tonality approches maximum white, starting from minimum black, as the RGB values go from 0 to whatever maximum value is allowed by the bit-depth of the image.

Also, the sRGB V2 matrix ICC profile has a 1024 point TRC that is contained in the sRGB profile TRC tags; this sRGB TRC can be exported and then imported into another ICC profile to change the other profile's TRC, to create a variant of the other profile that has the other profile's primaries, but the sRGB TRC.

The *only* time the default babl code properly converts an image from one ICC profile to another is if two conditions are met:

1. The primaries are the same in the source and destination profiles. 2. The TRCs of the two profiles are either linear gamma or the sRGB TRC.

So if I create a scarse prophoto variant that has a TRC equal to the sRGB TRC instead of being equal to gamma=1.8, and a second variant that has a linear gamma TRC, I can use the default babl code to convert from linear prophoto to the special prophoto variant with the sRGB TRC and back again.

If I create a variant of ClayRGB that has a linear gamma TRC and a second variant that has the sRGB TRC, I can use the default babl code to convert from linear gamma ClayRGB to the special ClayRGB variant with the sRGB TRC and back again.

All other ICC profile conversions are wrong if done with the default babl code, but correct if I modify the /babl/babl/util.h file.

In particular, if I keep the TRC as linear gamma for the source and destination profile, but the primaries vary, the colors are wrong.

And if I keep the primaries the same for the source and destination profile, but the TRCs are anything other than linear gamma and the sRGB TRC, the tonality comes out wrong.

And if both the primaries and the TRC vary, then everything is wrong. Unless I modify the util.h file. Then everything is right.

a higher level code where you
probably could do a similar tweak without changing core babl behavior could be in ... digging through GIMP code ... gimp/app/gegl/gimp-babl.c which contains code determining the data expected to be managed, for all arbitrary profile source imagery it would be recommended to store layer data in floating point.

I don't think there is any way to tweak the Gimp code to undo the effect of the util.h code that converts "something" in the background from a linear gamma TRC to the regular sRGB TRC and back. But perhaps if I had a better understanding of what the default babl code in babl/babl/base/util.h, and also in fast-float.c and float.c, is supposed to accomplish, it would help. Can anyone give a summary?

/yvind K.

Elle

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Elle Stone
2012-08-29 13:47:09 UTC (over 1 year ago)

the Gimp lcms.c plug-in

If anyone would like to try the lcms2 high bit depth plug-in, I put up instructions on compiling Gimp from git and the lcms2 plug-in, plus babl and gegl, with the modified babl/babl/util.h file:

http://ninedegreesbelow.com/temp/gimp-lcms-6.html