Re: [Gimp-developer] The darktable plug-in isn't using the user-specified output ICC profile

[Elle Stone]

On 04/27/2016 05:43 PM, Tobias Ellinghaus wrote:

Am Mittwoch, 27. April 2016, 12:00:32 schrieb Elle Stone:

On 04/24/2016 12:30 PM, Tobias Ellinghaus wrote:

https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00098.html:

It's hardcoded to export 32bit float EXR
as linear Rec709 after opening up your regular darktable. Did you
manually
select the Canon or Nikon format in the open dialog?


It would be nice if the darktable plug-in were modified to allow users
to choose their preferred output space.


Yes.


But currently darktable does seem to force output to be in the darktable
version of linear gamma Rec709 (which isn't equivalent to GIMP's
internal linear gamma sRGB color space -
https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00116.html
-, but hopefully this can be changed).


Should be fixed, see the other thread. Once you confirmed that the profiles are
fine now we will release darktable 2.0.4.


Yes, the profiles are fine.




Right now GIMP is an "sRGB only" image editor. But this situation surely
won't last forever. Having a raw processing plug-in that only allows to
export in one color space (especially a color space that doesn't match
the GIMP built-in sRGB color space) seems to be a step in the wrong
direction.


The reason I chose linear sRGB is that

1) we are exporting to EXR as the intermediate file, so we need a linear profile
2) GIMP seems to work best with sRGB images so far, so I used the linear
version of that.

I agree that it would be nice to have some choice there. Would default export
to linear Rec2020 be better? Still hard coded, but a wider gamut. It seems
GIMP asks about converting the colors anyway, so for people that want to work
in sRGB that's just one click away.


At this point in time and given the hard-coded sRGB parameters in the 
babl/GEGL/GIMP code base, if the darktable plug-in can't be easily 
modified to provide users with a choice of export profiles, then 
converting the image to linear gamma sRGB seems to me to be the right 
choice (even though I'd love to suggest using linear Rec2020).


If a user wants to then convert the image to another RGB working space, 
that conversion can be done in GIMP, as you say "just a couple of clicks 
away". This assumes the exported darktable OpenEXR file doesn't clip out 
of gamut channel values, which I'm pretty sure it doesn't - at least the 
"out of sRGB gamut" channel values in my sample CR2 file were not clipped.


Best,
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

Re: [Gimp-developer] The darktable plug-in isn't using the user-specified output ICC profile

[Tobias Ellinghaus]

Am Mittwoch, 27. April 2016, 12:00:32 schrieb Elle Stone:
> > On 04/24/2016 12:30 PM, Tobias Ellinghaus wrote:
> https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00098.html:
> >> It's hardcoded to export 32bit float EXR
> >> as linear Rec709 after opening up your regular darktable. Did you
> >> manually
> >> select the Canon or Nikon format in the open dialog?
> 
> It would be nice if the darktable plug-in were modified to allow users
> to choose their preferred output space.

Yes.

> But currently darktable does seem to force output to be in the darktable
> version of linear gamma Rec709 (which isn't equivalent to GIMP's
> internal linear gamma sRGB color space -
> https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00116.html
> -, but hopefully this can be changed).

Should be fixed, see the other thread. Once you confirmed that the profiles are 
fine now we will release darktable 2.0.4.

> Right now GIMP is an "sRGB only" image editor. But this situation surely
> won't last forever. Having a raw processing plug-in that only allows to
> export in one color space (especially a color space that doesn't match
> the GIMP built-in sRGB color space) seems to be a step in the wrong
> direction.

The reason I chose linear sRGB is that

1) we are exporting to EXR as the intermediate file, so we need a linear profile
2) GIMP seems to work best with sRGB images so far, so I used the linear 
version of that.

I agree that it would be nice to have some choice there. Would default export 
to linear Rec2020 be better? Still hard coded, but a wider gamut. It seems 
GIMP asks about converting the colors anyway, so for people that want to work 
in sRGB that's just one click away.

Having a way to actually change the profile from darktable on the fly would 
require some changed to darktable that I don't want to do right now (pending 
release, breaking things, you know the drill). Eventually I will think about 
ways to fix that though.

> Also, only some GIMP operations are "sRGB only". Many operations work
> just fine using any RGB working space chromaticities.
> 
> Presumably at least some GIMP users will sometimes want to edit their
> interpolated raw files in RGB working spaces other than sRGB, and GIMP
> does allow this to happen. So it doesn't make sense that the darktable
> plug-in prevents users from exporting the image in the user's chosen RGB
> working space.
> 
> Best,
> Elle

Tobias

signature.asc
Description: This is a digitally signed message part.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] darktable linear Rec709 doesn't match GIMP linear sRGB

[Tobias Ellinghaus]

Am Mittwoch, 27. April 2016, 10:55:14 schrieb Elle Stone:
> The darktable plug-in linear Rec 709 chromaticities don't match the GIMP
> built-in sRGB chromaticities.

Thanks for bringing that up, I changed the sRGB profile a while ago but somehow 
forgot the others. I pushed a change to create profiles that match your sample 
set. Could you please have a look at them [0]?

[...]

> Best,
> Elle

Tobias

[0] https://houz.org/tmp/darktable_profiles_2.0.4.tgz


signature.asc
Description: This is a digitally signed message part.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] How to transfer the darktable plug-in processed raw file to GIMP

[Tobias Ellinghaus]

Am Mittwoch, 27. April 2016, 10:51:39 schrieb Elle Stone:
> Upon attempting to open my sample CR2 file from within GIMP (updated
> this morning) using the darktable plug-in, darktable does indeed open
> the raw file in the usual darktable window.
> 
> However it's not obvious (at least not to me) how to then persuade
> darktable to transfer the processed raw file from darktable back to GIMP.
> 
> Closing the darktable window does immediately transfer the processed raw
> file back to GIMP.
> 
> Is there a more "official" way to transfer the darktable-processed raw
> file from darktable to GIMP?

No, that's how it's supposed to work: close darktable and wait for it to 
export the file that GIMP then opens.

> Best,
> Elle

Tobias

signature.asc
Description: This is a digitally signed message part.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [darktable-dev] Darktable plug-in in GIMP - Darktable for Windows?

[Elle Stone]

On 04/24/2016 09:54 AM, Elle Stone wrote:

On Wed, Apr 20, 2016 at 6:46 AM, Sven Claussner 
wrote:

Hi,

sorry if I'm asking the wrong question but I feel I have to.
Since 18.04.2016 there is a raw importer plug-in in GIMP master
that calls darktable to do its job. With the same commit
the GEGL NEF importer was disabled which is a quite clear sign
of the devs' preferences.



What has led to this decision?
Did anybody compare the various ways to import raw files
into GIMP (GEGL, darktable, ufraw, photoflow etc.)?




Darktable is a very good raw processor, but it's not everyone's
preferred raw processor. For example I use PhotoFlow for processing raw
files. PhotoFlow has a GIMP plug-in that works under Linux and Windows
and I think also Mac.

I was a little concerned to see the darktable-specific code appear in
GIMP master. But after installing the PhotoFlow plug-in in a "default"
copy of GIMP from git and trying to open a raw file, GIMP did bypass
darktable and allow PhotoFlow to open the raw file. So it looks like
GIMP users do have a choice of which raw processor to use when opening a
raw file from within GIMP. Hopefully this will always be the case.


Hmm, now that I have darktable properly installed using Lua, and GIMP 
opening 32f raw files processed with darktable, I can't figure out how 
to open a raw file from GIMP using the PhotoFlow plug-in.


What's the procedure for bypassing the darktable plug-in to use a 
different GIMP raw plug-in?


Best,
Elle

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

[Gimp-developer] Introducing the PhotoFlow GIMP plug-in

[Carmelo DrRaw]

Since a little while there is one more RAW loading plug-in available for GIMP, 
based on the PhotoFlow editor source code (http://photoflowblog.blogspot.com/ 
)

The plug-in works pretty much like UFraw, meaning that it gets called when GIMP 
tries to open a RAW file, and after the processing it writes back the image 
data into the GEGL buffer of a newly created GIMP image. However, the available 
functionalities are more complete than UFraw, and it also takes full advantage 
of GIMP 2.9 high bit depth capabilities by sending the image data in 32 bits 
floating point format. 

The PhF plug-in is already available as pre-compiled package for Ubuntu and 
derivatives though Thorsten Stettin gimp-edge PPA, and also included in the 
latest Windows and OSX GIMP 2.9 installers from Partha. 

Of course it can also be compiled from sources, in which case it is recommended 
to use the “stable” branch of the GitHub repository 
(https://github.com/aferrero2707/PhotoFlow/tree/stable 
). 

Presently I am working on improving the GIMP-PhF inter-operability. In the 
current version of the plug-in, not only the image data is sent to GIMP when 
the plug-in is closed, but also the RAW processing configuration. This 
configuration is stored as meta-data attached to the background layer created 
by the plug-in itself. Also, this meta-data gets stored in the XCF file when 
you save it to disk. 

The PhF plug-in can be executed again on the same background layer, through the 
Filters->Photoflow... menu shortcut. When you do so, instead of processing the 
layer itself, the plug-in opens again the RAW file and applies again the 
processing parameters as stored in the layer meta-data. The RAW processing can 
thus be further tweaked and saved back again in the same background layer. 

This functionality is currently only available when compiling the "stable" GIT 
branch from sources, and is not yet included in the pre-compiled packages. 

The goal is to provide a inter-operability between GIMP and PhF that somewhat 
resembles the one between PhotoShop and Lightroom... 

Any feedback would be greatly appreciated!

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

[Gimp-developer] The darktable plug-in isn't using the user-specified output ICC profile

[Elle Stone]

On 04/24/2016 12:30 PM, Tobias Ellinghaus wrote:

https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00098.html:

It's hardcoded to export 32bit float EXR
as linear Rec709 after opening up your regular darktable. Did you manually
select the Canon or Nikon format in the open dialog?




It would be nice if the darktable plug-in were modified to allow users 
to choose their preferred output space.


But currently darktable does seem to force output to be in the darktable 
version of linear gamma Rec709 (which isn't equivalent to GIMP's 
internal linear gamma sRGB color space - 
https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00116.html 
-, but hopefully this can be changed).


Right now GIMP is an "sRGB only" image editor. But this situation surely 
won't last forever. Having a raw processing plug-in that only allows to 
export in one color space (especially a color space that doesn't match 
the GIMP built-in sRGB color space) seems to be a step in the wrong 
direction.


Also, only some GIMP operations are "sRGB only". Many operations work 
just fine using any RGB working space chromaticities.


Presumably at least some GIMP users will sometimes want to edit their 
interpolated raw files in RGB working spaces other than sRGB, and GIMP 
does allow this to happen. So it doesn't make sense that the darktable 
plug-in prevents users from exporting the image in the user's chosen RGB 
working space.


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

[Gimp-developer] darktable linear Rec709 doesn't match GIMP linear sRGB

[Elle Stone]

The darktable plug-in linear Rec 709 chromaticities don't match the GIMP 
built-in sRGB chromaticities. This means the GIMP user must convert the 
image to the GIMP built-in ICC profile before some GIMP editing 
operations will give correct results.


The sRGB and Rec709 color spaces are defined in their respective color 
space specs by the exact same D65 white point and red, green, and blue 
xyY values 
(http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf, 
http://www.color.org/specification/ICC1v43_2010-12.pdf). So the 
resulting ICC profiles should have the same red, green, and blue ICC 
profile XYZ colorants (assuming of course that both profiles are made 
using Bradford adaptation).


sRGB and Rec709 only differ by the TRC, and of course when making linear 
gamma profile variants the two profiles should be identical.


Comparing GIMP and darktable ICC profile XYZ Colorants:

Here are the sRGB XYZ colorants from GIMP's internal built-in sRGB 
profiles (from iccToXml):


red:   0.43603516, 0.22248840, 0.01391602
green: 0.38511658, 0.71690369, 0.09706116
blue:  0.14305115, 0.06060791, 0.71392822

Here are the darktable XYZ colorants (from darktable's 
src/common/colorspace.c):


red:   0.436066, 0.222488, 0.013916
green: 0.385147, 0.716873, 0.097076
blue:  0.143066, 0.060608, 0.714096

Comparing GIMP and darktable Source White Points:

Here's the D65 xyY white point used to make GIMP's built-in sRGB 
profiles, exactly as specified in the sRGB color space specs 
(http://www.w3.org/Graphics/Color/sRGB, 
http://www.color.org/specification/ICC1v43_2010-12.pdf).

cmsCIExyY whitepoint = { 0.3127, 0.3290, 1.0 };

Here's the equivalent ICC profile XYZ values: 0.95045471, 1., 
1.08905029


Here are the darktable source white point values, given in the darktable 
code as XYZ values: 0.95045, 1, 1.08905


The difference in precision in specifying the values to make the 
resulting ICC profiles means that darktable and GIMP aren't using the 
same built-in "Rec709/sRGB" linear gamma ICC profiles. However, 
"precision" isn't the only difference. The darktable XYZ colorants for 
the linear gamma Rec709 profile aren't just rounded to only six places, 
but actually differ from the GIMP XYZ colorants in the fifth and sixth 
decimal places. So the GIMP user can't just assign the GIMP built-in 
linear gamma sRGB profile (the resulting images are sometimes obviously 
visually very different), but instead must do an ICC profile conversion.


On a related note, I think it's going to cause confusion for GIMP users 
to see "linear gamma Rec709" in darktable and "linear gamma sRGB" in 
GIMP, so for compatibility with GIMP it might be good to change the name 
of darktable's "linear gamma Rec709" to "linear gamma sRGB".


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

[Gimp-developer] How to transfer the darktable plug-in processed raw file to GIMP

[Elle Stone]

Upon attempting to open my sample CR2 file from within GIMP (updated 
this morning) using the darktable plug-in, darktable does indeed open 
the raw file in the usual darktable window.


However it's not obvious (at least not to me) how to then persuade 
darktable to transfer the processed raw file from darktable back to GIMP.


Closing the darktable window does immediately transfer the processed raw 
file back to GIMP.


Is there a more "official" way to transfer the darktable-processed raw 
file from darktable to GIMP?


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

[Gimp-developer] Cubic Interpolation vs No Halo

[C R]

I assume the reasoning behind using cubic as the default for all the scale
and transform tools is to cut back on the complaints of how slow GIMP is at
the moment, but the quality loss in the current cubic interpolation
algorithm is quite bad.

Can we shift the default to No Halo or Lo Halo?
Also, it's probably safe to assume that if the user chooses an
interpolation type in the tool, they are saying something about the quality
of the results they are after vs speed. I think setting the value in one
tool should set the value automatically in other tools, and treat it as a
"global" value of sorts.

It's just that I spend a lot of time lately switching to No halo for my
professional work.

Thoughts?

-C
___
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