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

(no subject)

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.

14 of 14 messages available
Toggle history

Please log in to manage your subscriptions.

(no subject) Elle Stone 19 Jun 13:24
  (no subject) Øyvind Kolås 19 Jun 13:48
  (no subject) Simon Budig 19 Jun 14:05
   (no subject) Michael Henning 19 Jun 16:19
   (no subject) Elle Stone 19 Jun 16:23
    (no subject) Elle Stone 19 Jun 17:14
     (no subject) Øyvind Kolås 19 Jun 18:14
      (no subject) Elle Stone 19 Jun 18:37
       (no subject) Partha Bagchi 20 Jun 10:53
(no subject) Ben Harrington-Ellsmore 21 Jun 06:46
  (no subject) Michael Schumacher 21 Jun 09:19
  (no subject) Alexandre Prokoudine 21 Jun 10:09
   (no subject) peter sikking 21 Jun 10:42
(no subject) Ben Harrington-Ellsmore 22 Jun 22:19
Elle Stone
2012-06-19 13:24:12 UTC (over 2 years ago)

(no subject)

Hello Gimp Developers,

I compiled Gimp, Babl, and Gegl from git (last compilation was June 12, 2012) and did some testing. I posted my findings to a temporary web page: http://ninedegreesbelow.com/temp/gimp29.html

I do understand that Gimp 2.9 from git is undergoing heavy development and so it changes frequently. My apologies if I'm reporting on stuff you already know. But here is a summary of what I've found so far:

(1) Color space conversions result in lost colors, whether done at 8-, 16-, or 32-bits, floating or integer. At first I thought it was a result of converting to and from a linear-gamma color space. But actually the color space gamma makes no difference.

(2) All the color space conversions that I used involved matrix profiles. For a matrix profile, the only valid type of color space conversion is "colorimetric". I used "relative colorimetric" color space conversion exclusively. The color space conversion results varied depending on whether I used black point compensation or not. However, if the color spaces involved all have the same black point, using or not using black point compensation should not make any difference whatsoever.

(3) Eric Brasseur's image scaling test produced very odd image discolorations, regardless of what color space (linear or nonlinear gamma) or image depth (8-bit integer or 32-bit floating) was used.

(4) Although Gimp 2.9 correctly opens 8-bit tiffs, when opening any 16-bit tiff, the image is subjected to a roughly gamma=2.2 curve. All RGB colors are altered (it's not just a display problem), so the resulting image is too light.

Again, my apologies if I'm reporting issues of which you are already aware.

Kind regards, Elle Stone

Øyvind Kolås
2012-06-19 13:48:47 UTC (over 2 years ago)

(no subject)

On Tue, Jun 19, 2012 at 3:24 PM, Elle Stone wrote:

(1) Color space conversions result in lost colors, whether done at 8-, 16-, or 32-bits, floating or integer. At first I thought it was a result of converting to and from a linear-gamma color space. But actually the color space gamma makes no difference.

(2) All the color space conversions that I used involved matrix profiles. For a matrix profile, the only valid type of color space conversion is "colorimetric". I used "relative colorimetric" color space conversion exclusively. The color space conversion results varied depending on whether I used black point compensation or not. However, if the color spaces involved all have the same black point, using or not using black point compensation should not make any difference whatsoever.

None of the ICC profile handling in GIMP deals with GEGL or higher bitdepths - at the start and end of all these code paths things go through 8bpc; and probably behave similarly to how they do in 2.8 - there shouldn't be much of a difference.

(3) Eric Brasseur's image scaling test produced very odd image discolorations, regardless of what color space (linear or nonlinear gamma) or image depth (8-bit integer or 32-bit floating) was used.

I've seen some of these discolorations; but at least the results are a lot more correct than earlier versions, for some of these tests the type of resampler and "where in the pixel" the center being resampled is will matter a lot, the 2x2 px in input -> 1 px in output hardcoded tests used by eric brasseur are not generic like the code paths employed by gimp.

(4) Although Gimp 2.9 correctly opens 8-bit tiffs, when opening any 16-bit tiff, the image is subjected to a roughly gamma=2.2 curve. All RGB colors are altered (it's not just a display problem), so the resulting image is too light.

TIFFs seem to be a nightmare and only brief initial attempts have been made at making GIMP support higher bitdepth diffs.

/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
Simon Budig
2012-06-19 14:05:48 UTC (over 2 years ago)

(no subject)

Elle Stone (l.elle.stone@gmail.com) wrote:

(4) Although Gimp 2.9 correctly opens 8-bit tiffs, when opening any 16-bit tiff, the image is subjected to a roughly gamma=2.2 curve. All RGB colors are altered (it's not just a display problem), so the resulting image is too light.

Hmm, I am not fully sure what is the right thing to do there. On June 6th I did a change to the TIFF loading code, ensuring that the samples in the TIFF get treated as linear. Did you do your tests before or after that date?

Thanks,
Simon

Michael Henning
2012-06-19 16:19:20 UTC (over 2 years ago)

(no subject)

I can still reproduce this on latest master (5835a730a3eef3cee579c50b250bb8ba15b77d7c), using the images that are available for download at the bottom of that page.

Strangely, if you open the 16 bit tiff, and choose not to convert it into the sRGB builtin colorspace, the image still displays with the wrong gamma on canvas, but the thumbnail on the tab in single window mode looks correct to me.

-- drawoc

On Tue, Jun 19, 2012 at 10:05 AM, Simon Budig wrote:

Elle Stone (l.elle.stone@gmail.com) wrote:

(4) Although Gimp 2.9 correctly opens 8-bit tiffs, when opening any 16-bit tiff, the image is subjected to a roughly gamma=2.2 curve. All RGB colors are altered (it's not just a display problem), so the resulting image is too light.

Hmm, I am not fully sure what is the right thing to do there. On June 6th I did a change to the TIFF loading code, ensuring that the samples in the TIFF get treated as linear. Did you do your tests before or after that date?

Thanks,
Simon
--
simon@budig.de http://simon.budig.de/ _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Elle Stone
2012-06-19 16:23:12 UTC (over 2 years ago)

(no subject)

On 6/19/12, Simon Budig wrote:

Hmm, I am not fully sure what is the right thing to do there. On June 6th I did a change to the TIFF loading code, ensuring that the samples in the TIFF get treated as linear. Did you do your tests before or after that date?

Simon, I did the tiff tests before and after June 6th. Elle

Elle Stone
2012-06-19 17:14:21 UTC (over 2 years ago)

(no subject)

On 6/19/12, yvind Kols wrote:

None of the ICC profile handling in GIMP deals with GEGL or higher bitdepths - at the start and end of all these code paths things go through 8bpc; and probably behave similarly to how they do in 2.8 - there shouldn't be much of a difference.

On Tue, Jun 19, 2012 at 4:10 PM, Elle Stone wrote:

Is this a permanent state of affairs?

No, it means that the code converting between color profiles is unchanged and has almost not been touched as part of the conversion to use GEGL, in other words it is still 8bit, you or anyone elses contribution to fix this would be welcome - but it is unlikely as high priority as making other important things work fully.

/

Hi /,

My apologies, I think I accidentally emailed you off-list.

The last bit of code that I wrote was a rewrite of the dcraw c code to make it floating point and to incorporate some of the great interpolation algorithms that the dcraw default c code doesn't include.

That does't make me a "real" programmer, just a "programmer wannabe". Nonetheless, getting color conversion right is important enough to me that I'd like to take a look at the code and see what I can do.

However, Babl/Gegl/Gimp is a whole lot of code broken into a whole lot of files. If someone could maybe tell me which files handle color conversion, I would try my best to make sense of it all.

Elle

Elle Stone
http://ninedegreesbelow.com
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Øyvind Kolås
2012-06-19 18:14:27 UTC (over 2 years ago)

(no subject)

On Tue, Jun 19, 2012 at 7:14 PM, Elle Stone wrote:

On 6/19/12, yvind Kols wrote:

None of the ICC profile handling in GIMP deals with GEGL or higher bitdepths - at the start and end of all these code paths things go through 8bpc; and probably behave similarly to how they do in 2.8 - there shouldn't be much of a difference.

On Tue, Jun 19, 2012 at 4:10 PM, Elle Stone wrote:

Is this a permanent state of affairs?

No, it means that the code converting between color profiles is unchanged and has almost not been touched as part of the conversion to use GEGL, in other words it is still 8bit, you or anyone elses contribution to fix this would be welcome - but it is unlikely as high priority as making other important things work fully.

/

Hi /,

My apologies, I think I accidentally emailed you off-list.

The last bit of code that I wrote was a rewrite of the dcraw c code to make it floating point and to incorporate some of the great interpolation algorithms that the dcraw default c code doesn't include.

That does't make me a "real" programmer, just a "programmer wannabe". Nonetheless, getting color conversion right is important enough to me that I'd like to take a look at the code and see what I can do.

However, Babl/Gegl/Gimp is a whole lot of code broken into a whole lot of files. If someone could maybe tell me which files handle color conversion, I would try my best to make sense of it all.

If you join #gimp on irc.gimp.org I'm sure there will be people who can point you in the right direction ;) At least for the color profile bits which should be very self contained code.

/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-06-19 18:37:21 UTC (over 2 years ago)

(no subject)

Hi, /yvind and Mitch,

If you join #gimp on irc.gimp.org I'm sure there will be people who can point you in the right direction ;) At least for the color profile bits which should be very self contained code.

I will follow your suggestions to join IRC, #gimp on irc.gimp.org.

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Partha Bagchi
2012-06-20 10:53:08 UTC (over 2 years ago)

(no subject)

On Tue, Jun 19, 2012 at 2:37 PM, Elle Stone wrote:

Hi, /yvind and Mitch,

If you join #gimp on irc.gimp.org I'm sure there will be people who can point you in the right direction ;) At least for the color profile bits which should be very self contained code.

I will follow your suggestions to join IRC, #gimp on irc.gimp.org. _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

I on the other hand have not been able to open any 16-bit files (here on a Mac, Snow Leopard). This is based on git pull from yesterday.

Invariably I get this:

bps: 16 load_contiguous
bytes_per_pixel: 6, format: 6
file-tiff-load is updating the progress too often

file-tiff-load: fatal error: Bus error

file-tiff-load (pid:71070): [E]xit, [H]alt, show [S]tack trace or [P]roceed: S

#0 0x00007fff8659f0f0 in __wait4 () #1 0x0000000101161a2f in g_on_error_stack_trace (prg_name=0x7fff5fbff838
"/Users/partha/local/gimp-2.9/lib/gimp/2.0/plug-ins/file-tiff-load") at gbacktrace.c:256
#2 0x0000000101161ed2 in g_on_error_query (prg_name=0x7fff5fbff838 "/Users/partha/local/gimp-2.9/lib/gimp/2.0/plug-ins/file-tiff-load") at gbacktrace.c:190
#3 0x0000000100038665 in gimp_plugin_sigfatal_handler () #4 0x00007fff5fbfe9c0 in ?? ()
#5 0x0000000100050d3c in gimp_tile_put ()

file-tiff-load (pid:71070): [E]xit, [H]alt, show [S]tack trace or [P]roceed: P

plug-in 'file-tiff-load' aborted before sending its procedure return values EEEEeEeek! 4 GeglBuffers leaked

(gimp-2.9:70882): Gimp-Base-WARNING **: 2 tile managers leaked unref tile manager 0x1033d6b80 (4288 x 2848) unref tile manager 0x1033d5800 (4288 x 2848)

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Ben Harrington-Ellsmore
2012-06-21 06:46:10 UTC (over 2 years ago)

(no subject)

Hi I have been trying to work out how to get Gimp to only show fonts from the user/fonts file rather than the vast amount of system fonts can anyone point me at the code section I need to start mucking about with?

http://www.freewebs.com/noughtypixy/

Thank you for DELETING my address, other addresses and any other personal information from this email (if you plan to forward it). Thanks too for using "BCC" instead of "TO" and "CC" when forwarding e-mails. This helps prevent spammers and hackers from obtaining addresses and thus the proliferation of spam.

Michael Schumacher
2012-06-21 09:19:32 UTC (over 2 years ago)

(no subject)

Von: Ben Harrington-Ellsmore

Hi I have been trying to work out how to get Gimp to only show fonts from the user/fonts file rather than the vast amount of system fonts can anyone point me at the code section I need to start mucking about with?

Have you exhausted all other options already?

For example, have you verified that the directories are either present in the fontconfig configuration or have been added to GIMP's own font folder settings? Have you verified what font files are examined on the startup of GIMP?

Your mail reads like a textbook example from the Smart Questions guide (http://www.catb.org/~esr/faqs/smart-questions.html), in the way that it presents us with a single statement ('system fonts are not shown') and your conclusion ('must be something in the code'), without any additional information to first find the cause for the problem, and then decide how to fix it, that's why I'm trying to guide you into a different direction.

Regards, Michael

Alexandre Prokoudine
2012-06-21 10:09:38 UTC (over 2 years ago)

(no subject)

On Thu, Jun 21, 2012 at 10:46 AM, Ben Harrington-Ellsmore wrote:

Hi I have been trying to work out how to get Gimp to only show fonts from the user/fonts file rather than the vast amount of system fonts can anyone point me at the code section I need to start mucking about with?

Which version of GIMP?
On what system?

In general, if you want a problem solved, you should be providing more information about the conditions where the issue takes place.

P.S. Why is it a gimp-developer@ list material?

Alexandre Prokoudine http://libregraphicsworld.org

peter sikking
2012-06-21 10:42:05 UTC (over 2 years ago)

(no subject)

Alexandre wrote:

P.S. Why is it a gimp-developer@ list material?

I directed him here, because he wants to solve it in code.

--ps

founder + principal interaction architect man + machine interface works

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

Ben Harrington-Ellsmore
2012-06-22 22:19:01 UTC (over 2 years ago)

(no subject)

On Thu, Jun 21, 2012 at 10:46 AM, Ben Harrington-Ellsmore wrote:

Hi I have been trying to work out how to get Gimp to only show fonts from the user/fonts file rather than the vast amount of system fonts can anyone point me at the code section I need to start mucking about with?

Which version of GIMP?
On what system?

gimp 2.6.12
running in ubuntu 12.04

In general, if you want a problem solved, you should be providing more information about the conditions where the issue takes place.

P.S. Why is it a gimp-developer@ list materialI have been poking at the gui for a while and haven't been able to find a way to do what I would like to be able to, drastically shorten the list of fonts. I removed the path to system fonts from preferences/folders/fonts but they still appear have also googled extensively and have only been able to find topics with the opposite situation (no system fonts showing)
so tried to reverse what they had done to get system fonts back but that didn't help so after almost a year of trying on and off I posted it as a suggestion on the gimp-brainstorm where peter suggested I ask here.