Hi Sven,

have a look at line 114 from file-darktable.c:

// TODO: check if darktable is installed

https://git.gnome.org/browse/gimp/tree/plug-ins/file-darktable/file-darktable.c#n114

It is at least on the ToDo list to not show this import on Windows.

Regards, Tobias

2016-04-20 6:46 GMT+02:00 Sven Claussner :

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.
On the one hand it is great we have proper import for raw files in GIMP and darktable is indeed a great application for raw processing. On the other hand I see that up to 90% of the PC users are Windows users, for instance see these [statistics]. In the past the darktable devs refused to provide a Windows build for understandable reasons of maintenance and even didn't want to hear about Partha's Windows build (see the latest discussion about this on the darktable dev mailing list in February 2016). The latter makes it also very difficult to discuss Windows related bugs which will definitely come.
So, it seems GIMP and Darktable are now trapped - how are 90% of the GIMP users supposed to import raw files with an application that will probably never support their platform? What has led to this decision?
Did anybody compare the various ways to import raw files into GIMP (GEGL, darktable, ufraw, photoflow etc.)?

Greetings

Sven

[statistics] https://netmarketshare.com/
http://www.statista.com/statistics/268237/global-market-share-held-by-operating-systems-since-2009/

_______________________________________________ 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

hi all,

let me try to answer some details from the dt side:

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.
On the one hand it is great we have proper import for raw files in GIMP and darktable is indeed a great application for raw processing. On the other hand I see that up to 90% of the PC users are Windows users, for instance see these [statistics]. In the past the darktable devs refused to provide a Windows build for understandable reasons of maintenance and even didn't want to hear about Partha's Windows build (see the latest discussion about this on the darktable dev mailing list in February 2016). The latter makes it also very difficult to discuss Windows related bugs which will definitely come.

fair point. as far as i can tell gimp has a similar problem trying to fix windows related bugs without windows devs?

So, it seems GIMP and Darktable are now trapped - how are 90% of the GIMP users supposed to import raw files with an application that will probably never support their platform?

darktable compiles just fine on windows. for a windows package of gimp shipping dt just as a raw importer, i would imagine a stripped-down build without tethering, map mode, etc, maybe even without lighttable mode altogether would be much simpler to maintain for the package manager than trying to do the full thing.

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

that's probably more a question for the gimp side.

cheers, jo

Greetings

Sven

[statistics] https://netmarketshare.com/
http://www.statista.com/statistics/268237/global-market-share-held-by-operating-systems-since-2009/

___________________________________________________________________________ darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscribe@lists.darktable.org

* Sven Claussner [04-20-16 00:47]:

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.
On the one hand it is great we have proper import for raw files in GIMP and darktable is indeed a great application for raw processing. On the other hand I see that up to 90% of the PC users are Windows users, for instance see these [statistics]. In the past the darktable devs refused to provide a Windows build for understandable reasons of maintenance and even didn't want to hear about Partha's Windows build (see the latest discussion about this on the darktable dev mailing list in February 2016). The latter makes it also very difficult to discuss Windows related bugs which will definitely come.
So, it seems GIMP and Darktable are now trapped - how are 90% of the GIMP users supposed to import raw files with an application that will probably never support their platform? What has led to this decision?
Did anybody compare the various ways to import raw files into GIMP (GEGL, darktable, ufraw, photoflow etc.)?

statistics lie :) but you can always use photivo or rawtherapee. They have/provide windows builds. Or you might embrace linux :) and free yourself of dependencies which increasingly desire more of your payroll and allotment for new glass.

(paka)Patrick Shanahan       Plainfield, Indiana, USA          @ptilopteri
http://en.opensuse.org    openSUSE Community Member    facebook/ptilopteri
http://wahoo.no-ip.org        Photo Album: http://wahoo.no-ip.org/gallery2
Registered Linux User #207535                    @ http://linuxcounter.net

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.

Will there be (or is there already) a way in the GIMP UI for users to have more than one raw plug-in installed? plus a way to choose which raw processor to use when opening a raw file? The various free/libre raw processors provide various editing options, and many people do occasionally or routinely switch away from whatever raw processor they tend to use the most.

Speaking specifically of the GIMP-darktable code, it seems the GIMP-darktable code opens an already-processed 8-bit jpeg. It doesn't open the darktable raw processor interface and allow the user to choose the processing parameters and output bitdepth. Is this what is supposed to happen? I'm using darktable-2.0.3 from Gentoo portage and GIMP 2.9.3 updated from git master this morning.

Best, Elle

Am Sonntag, 24. April 2016, 09:54:25 schrieb Elle Stone:

[...]

Speaking specifically of the GIMP-darktable code, it seems the GIMP-darktable code opens an already-processed 8-bit jpeg. It doesn't open the darktable raw processor interface and allow the user to choose the processing parameters and output bitdepth. Is this what is supposed to happen? I'm using darktable-2.0.3 from Gentoo portage and GIMP 2.9.3 updated from git master this morning.

Then something isn't working for you. 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?

Best,
Elle

Tobias

In the darktable lua scripts, https://github.com/darktable-org/lua-scripts, there is a script to add GIMP as an export target to the darktable exporter. You can import your raws into darktable, process them, then select them and export them to GIMP. GIMP will launch and open the file. Save your changes back to the file, exit GIMP, and darktable will import the result and group it with the original raw.

Hope this helps,

Bill

On Sat, Apr 23, 2016 at 5:07 PM, Mika Mantere wrote:

Hi,

Can anyone tell me how to use darktable gimp plug-in to get images directly from DT to Gimp without having to export them in one format from DT and then open them in Gimp?

I use DT almost exclusively with photos, but sometimes I have to use Gimp and a plug-in would be very welcome.

I have Darktable Unstable and Gimp 2.9.3 (unstable), both from PPAs, running on Ubuntu 16.04.

Thanks, Mika

On Wed, Apr 20, 2016 at 3:47 AM, Patrick Shanahan wrote:

* Sven Claussner [04-20-16 00:47]:

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.
On the one hand it is great we have proper import for raw files in GIMP and darktable is indeed a great application for raw processing. On the other hand I see that up to 90% of the PC users are Windows users, for instance see these [statistics]. In the past the darktable devs refused to provide a Windows build for understandable reasons of maintenance and even didn't want to hear about Partha's Windows build (see the latest discussion about this on the darktable dev mailing list in February 2016). The latter makes it also very difficult to discuss Windows related bugs which will definitely come.
So, it seems GIMP and Darktable are now trapped - how are 90% of the GIMP users supposed to import raw files with an application that will probably never support their platform? What has led to this decision?
Did anybody compare the various ways to import raw files into GIMP (GEGL, darktable, ufraw, photoflow etc.)?

statistics lie :) but you can always use photivo or rawtherapee. They have/provide windows builds. Or you might embrace linux :) and free yourself of dependencies which increasingly desire more of your payroll and allotment for new glass.

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2
Registered Linux User #207535 @ http://linuxcounter.net

___________________________________________________________________________ darktable developer mailing list
to unsubscribe send a mail to
darktable-dev+unsubscribe@lists.darktable.org

___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscribe@lists.darktable.org

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

Am Sonntag, 24. April 2016, 09:54:25 schrieb Elle Stone:

[...]

Speaking specifically of the GIMP-darktable code, it seems the GIMP-darktable code opens an already-processed 8-bit jpeg. It doesn't open the darktable raw processor interface and allow the user to choose the processing parameters and output bitdepth. Is this what is supposed to happen? I'm using darktable-2.0.3 from Gentoo portage and GIMP 2.9.3 updated from git master this morning.

Then something isn't working for you. 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?

Maybe I don't understand what you mean by "select the Canon or Nikon format in the open dialog"? If it matters, the sample raw file I'm trying to open is a Canon CR2 file.

After selecting "File/Open" and looking under the tab that allows you to select which file types to show, there doesn't seem to be any Canon or Nikon format listed. There used to be an option to select camera raw files, but that option seems to have disappeared recently.

FWIW, I updated GIMP 2.9.3 from git this morning and there has been some new "file type magic" code added. But opening the Canon CR2 file still results in an 8-bit jpeg, accompanied by various terminal and popup errors and warnings.

Elle

On 04/25/2016 06:52 AM, Elle Stone wrote:

But opening the Canon CR2 file still results in an 8-bit jpeg, accompanied by various terminal and popup errors and warnings.

Looking more closely at the resulting jpeg, GIMP seems to just be opening the embedded jpeg.

Elle

Am Montag, 25. April 2016, 06:52:45 schrieb Elle Stone:

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

Am Sonntag, 24. April 2016, 09:54:25 schrieb Elle Stone:

[...]

Speaking specifically of the GIMP-darktable code, it seems the GIMP-darktable code opens an already-processed 8-bit jpeg. It doesn't open the darktable raw processor interface and allow the user to choose the processing parameters and output bitdepth. Is this what is supposed to happen? I'm using darktable-2.0.3 from Gentoo portage and GIMP 2.9.3 updated from git master this morning.

Then something isn't working for you. 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?

Maybe I don't understand what you mean by "select the Canon or Nikon format in the open dialog"? If it matters, the sample raw file I'm trying to open is a Canon CR2 file.

There is a way to specify how to open an image in the lower left hand corner of the open dialog:
http://picpaste.de/pics/Bildschirmfoto170-aGlsQVzQ.1461590441.png

After selecting "File/Open" and looking under the tab that allows you to select which file types to show, there doesn't seem to be any Canon or Nikon format listed. There used to be an option to select camera raw files, but that option seems to have disappeared recently.

FWIW, I updated GIMP 2.9.3 from git this morning and there has been some new "file type magic" code added. But opening the Canon CR2 file still results in an 8-bit jpeg, accompanied by various terminal and popup errors and warnings.

Elle

Tobias

On Mon, 2016-04-25 at 06:52 -0400, Elle Stone wrote:

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

Am Sonntag, 24. April 2016, 09:54:25 schrieb Elle Stone:

[...]

Speaking specifically of the GIMP-darktable code, it seems the GIMP-darktable code opens an already-processed 8-bit jpeg. It doesn't
open the darktable raw processor interface and allow the user to choose
the processing parameters and output bitdepth. Is this what is supposed
to happen? I'm using darktable-2.0.3 from Gentoo portage and GIMP 2.9.3
updated from git master this morning.

Then something isn't working for you. 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?

Maybe I don't understand what you mean by "select the Canon or Nikon  format in the open dialog"? If it matters, the sample raw file I'm  trying to open is a Canon CR2 file.

After selecting "File/Open" and looking under the tab that allows you to 
select which file types to show, there doesn't seem to be any Canon or 
Nikon format listed. There used to be an option to select camera raw  files, but that option seems to have disappeared recently.

FWIW, I updated GIMP 2.9.3 from git this morning and there has been some 
new "file type magic" code added. But opening the Canon CR2 file still 
results in an 8-bit jpeg, accompanied by various terminal and popup  errors and warnings.

You need the EXR plug-in built (have OpenEXR), install the plug-ins after the build, and have darktable in your PATH, then things should work automatically after my file magic fixes.

--Mitch

On Wed, 2016-04-20 at 06:46 +0200, 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.
On the one hand it is great we have proper import for raw files in GIMP and darktable is indeed a great application for raw processing. On the other hand I see that up to 90% of the PC users are Windows users, for instance see these [statistics]. In the past the darktable devs refused to provide a Windows build for understandable reasons of maintenance and even didn't want to hear about Partha's Windows build (see the latest discussion about this on the darktable dev mailing list in February 2016). The latter makes it also very difficult to discuss Windows related bugs which will definitely come.
So, it seems GIMP and Darktable are now trapped - how are 90% of the GIMP users supposed to import raw files with an application that will probably never support their platform? What has led to this decision?
Did anybody compare the various ways to import raw files into GIMP (GEGL, darktable, ufraw, photoflow etc.)?

Nope, we use darktable because  it works great, and because the darktable guys hang around in #gimp and are nice to work with, which trumps most other aspects from an engineering point of view.

--Mitch

Am 25.04.2016 um 00:50 schrieb William Ferguson:

In the darktable lua scripts, https://github.com/darktable-org/lua-scripts, there is a script to add GIMP as an export target to the darktable exporter. You can import your raws into darktable, process them, then select them and export them to GIMP. GIMP will launch and open the file. Save your changes back to the file, exit GIMP, and darktable will import the result and group it with the original raw.

By the way, this script does not work for me.

With Wdarktable -d lua" this script gives the error:

LUA ERROR true checkIfBinExists: gimp LUA ERROR /home/software/gimp/bin/gimp-2.9 /home/matthias/.local/tmp/IMG_4220.jpg LUA ERROR : /home/matthias/.config/darktable/luarc:216: field "execute" not found for type dt_lua_singleton_control

whats does that mean? I am using DT 2.0.3 and Mint Debian Edition.

Matthias

Hope this helps,

Bill

On Sat, Apr 23, 2016 at 5:07 PM, Mika Mantere > wrote:

Hi,

Can anyone tell me how to use darktable gimp plug-in to get images directly from DT to Gimp without having to export them in one format from DT and then open them in Gimp?

I use DT almost exclusively with photos, but sometimes I have to use Gimp and a plug-in would be very welcome.

I have Darktable Unstable and Gimp 2.9.3 (unstable), both from PPAs, running on Ubuntu 16.04.

Thanks, Mika

On Wed, Apr 20, 2016 at 3:47 AM, Patrick Shanahan > wrote:

* Sven Claussner > [04-20-16 00:47]: > 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.
> On the one hand it is great we have proper import for raw > files in GIMP and darktable is indeed a great application for > raw processing. On the other hand I see that up to 90% of the PC > users are Windows users, for instance see these [statistics]. > In the past the darktable devs refused to provide a Windows build > for understandable reasons of maintenance and even didn't want to > hear about Partha's Windows build (see the latest discussion about > this on the darktable dev mailing list in February 2016). The latter > makes it also very difficult to discuss Windows related bugs > which will definitely come. > So, it seems GIMP and Darktable are now trapped - how are > 90% of the GIMP users supposed to import raw files with an > application that will probably never support their platform? > What has led to this decision? > Did anybody compare the various ways to import raw files > into GIMP (GEGL, darktable, ufraw, photoflow etc.)?

statistics lie :) but you can always use photivo or rawtherapee. They have/provide windows builds. Or you might embrace linux :) and free yourself of dependencies which increasingly desire more of your payroll and allotment for new glass.

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscribe@lists.darktable.org

___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscribe@lists.darktable.org

___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscribe@lists.darktable.org

On 04/25/2016 09:21 AM, Tobias Ellinghaus wrote:

Maybe I don't understand what you mean by "select the Canon or Nikon format in the open dialog"? If it matters, the sample raw file I'm trying to open is a Canon CR2 file.

There is a way to specify how to open an image in the lower left hand corner of the open dialog:
http://picpaste.de/pics/Bildschirmfoto170-aGlsQVzQ.1461590441.png

Thanks! for the screen shot. I completely overlooked the "how to open an image" option in the lower left hand corner. But the Select File Type option doesn't list Canon Cr2 Raw files as one of the options.

On 04/25/2016 09:31 AM, Michael Natterer wrote:

You need the EXR plug-in built (have OpenEXR),

I have openexr and darktable installed through Gentoo portage. According to the terminal output, GIMP OpenEXR and darktable plug-ins are both built and installed. And both plug-ins show up in /home/elle/code/gimpdefault/install/lib/gimp/2.0/plug-ins/

after the build, and have darktable in your PATH,

The darktable executable is in /usr/bin, which is in my PATH: $ echo $PATH
/home/elle/code/gimpdefault/install/bin:/usr/local/bin:/usr/bin (and so on . . . )

then things should
work automatically after my file magic fixes.

Raw files opened from GIMP still aren't being opened in darktable. Instead it looks like the embedded jpeg is opened in GIMP. I'm clueless what I might be doing wrong but I'll try again tomorrow with a completely fresh build.

Elle

Am Montag, 25. April 2016, 17:16:03 schrieb Elle Stone:

[...]

Raw files opened from GIMP still aren't being opened in darktable. Instead it looks like the embedded jpeg is opened in GIMP. I'm clueless what I might be doing wrong but I'll try again tomorrow with a completely fresh build.

darktable needs to be built with Lua and EXR support. You can check for those by
- running "darktable --version", it will tell about Lua - look in the dropdown with the available formats in darktable's export module, does it list OpenEXR?

Elle

Tobias

The first two errors are just debugging messages. The last error is an error. The lua interface changed has changed in darktable and a patch was made to the lua scripts to be compatible. Darktable 2.0.3 still uses the old interface. You can get the 2.0.3 compatible version of the scripts from https://github.com/wpferguson/lua-scripts.

Bill

On Mon, Apr 25, 2016 at 4:12 PM, Matthias Bodenbinder < matthias@bodenbinder.de> wrote:

Am 25.04.2016 um 00:50 schrieb William Ferguson:

In the darktable lua scripts,

https://github.com/darktable-org/lua-scripts, there is a script to add GIMP as an export target to the darktable exporter. You can import your raws into darktable, process them, then select them and export them to GIMP. GIMP will launch and open the file. Save your changes back to the file, exit GIMP, and darktable will import the result and group it with the original raw.

By the way, this script does not work for me.

With Wdarktable -d lua" this script gives the error:

LUA ERROR true checkIfBinExists: gimp LUA ERROR /home/software/gimp/bin/gimp-2.9 /home/matthias/.local/tmp/IMG_4220.jpg LUA ERROR : /home/matthias/.config/darktable/luarc:216: field "execute" not found for type dt_lua_singleton_control

whats does that mean? I am using DT 2.0.3 and Mint Debian Edition.

Matthias

Hope this helps,

Bill

On Sat, Apr 23, 2016 at 5:07 PM, Mika Mantere

> wrote:

Hi,

Can anyone tell me how to use darktable gimp plug-in to get images

directly from DT to Gimp without having to export them in one format from DT and then open them in Gimp?

I use DT almost exclusively with photos, but sometimes I have to use

Gimp and a plug-in would be very welcome.

I have Darktable Unstable and Gimp 2.9.3 (unstable), both from PPAs,

running on Ubuntu 16.04.

Thanks,
Mika

On Wed, Apr 20, 2016 at 3:47 AM, Patrick Shanahan <

paka@wahoo.no-ip.org > wrote:

* Sven Claussner

scl.gplus@gmail.com>> [04-20-16 00:47]:

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.
> On the one hand it is great we have proper import for raw > files in GIMP and darktable is indeed a great application for > raw processing. On the other hand I see that up to 90% of the

PC

users are Windows users, for instance see these [statistics].

> In the past the darktable devs refused to provide a Windows

build

for understandable reasons of maintenance and even didn't want

to

hear about Partha's Windows build (see the latest discussion

about

this on the darktable dev mailing list in February 2016). The

latter

makes it also very difficult to discuss Windows related bugs

> which will definitely come.
> So, it seems GIMP and Darktable are now trapped - how are > 90% of the GIMP users supposed to import raw files with an > application that will probably never support their platform? > What has led to this decision? > Did anybody compare the various ways to import raw files > into GIMP (GEGL, darktable, ufraw, photoflow etc.)?

statistics lie :) but you can always use photivo or

rawtherapee. They

have/provide windows builds. Or you might embrace linux :) and

free

yourself of dependencies which increasingly desire more of your

payroll

and allotment for new glass.

-- (paka)Patrick Shanahan Plainfield, Indiana, USA

@ptilopteri

http://en.opensuse.org openSUSE Community Member

facebook/ptilopteri

http://wahoo.no-ip.org Photo Album:

http://wahoo.no-ip.org/gallery2

Registered Linux User #207535 @

http://linuxcounter.net

___________________________________________________________________________

darktable developer mailing list
to unsubscribe send a mail to

darktable-dev+unsubscribe@lists.darktable.org

___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscribe@lists.darktable.org

___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscribe@lists.darktable.org

___________________________________________________________________________ darktable developer mailing list
to unsubscribe send a mail to
darktable-dev+unsubscribe@lists.darktable.org

On 04/25/2016 07:12 PM, Tobias Ellinghaus wrote:

Am Montag, 25. April 2016, 17:16:03 schrieb Elle Stone:

[...]

Raw files opened from GIMP still aren't being opened in darktable. Instead it looks like the embedded jpeg is opened in GIMP. I'm clueless what I might be doing wrong but I'll try again tomorrow with a completely fresh build.

darktable needs to be built with Lua and EXR support. You can check for those by
- running "darktable --version", it will tell about Lua - look in the dropdown with the available formats in darktable's export module, does it list OpenEXR?

In darktable's export module, OpenEXR is an option, and when run as a standalone, darktable does export OpenEXR images that GIMP can open:

magic match 4 on file-exr-load best magic match on file-exr-load

It looks like darktable (installed though Gentoo portage) is not installed with Lua support:

$ darktable --version this is darktable 2.0.3
copyright (c) 2009-2015 johannes hanika darktable-dev@lists.darktable.org

compile options: normal build
OpenMP support enabled
OpenCL support disabled
Lua support disabled
Colord support disabled
gPhoto2 support enabled
GraphicsMagick support enabled

It's not clear to me why Lua support is disabled. I do have Lua installed: $ equery list '*lua*'
[IP-] [ ] dev-lang/lua-5.1.5-r3:0

There is no Gentoo use flag for darktable that allows to disable Lua support, and during ./autogen.sh, GEGL does list Lua as available and configured.

Elle

Am Dienstag, 26. April 2016, 07:16:50 schrieb Elle Stone:

On 04/25/2016 07:12 PM, Tobias Ellinghaus wrote:

Am Montag, 25. April 2016, 17:16:03 schrieb Elle Stone:

[...]

Raw files opened from GIMP still aren't being opened in darktable. Instead it looks like the embedded jpeg is opened in GIMP. I'm clueless what I might be doing wrong but I'll try again tomorrow with a completely fresh build.

darktable needs to be built with Lua and EXR support. You can check for those by

- running "darktable --version", it will tell about Lua - look in the dropdown with the available formats in darktable's export

module, does it list OpenEXR?

In darktable's export module, OpenEXR is an option, and when run as a standalone, darktable does export OpenEXR images that GIMP can open:

magic match 4 on file-exr-load best magic match on file-exr-load

It looks like darktable (installed though Gentoo portage) is not installed with Lua support:

$ darktable --version this is darktable 2.0.3
copyright (c) 2009-2015 johannes hanika darktable-dev@lists.darktable.org

compile options: normal build
OpenMP support enabled
OpenCL support disabled
Lua support disabled
Colord support disabled
gPhoto2 support enabled
GraphicsMagick support enabled

It's not clear to me why Lua support is disabled. I do have Lua installed: $ equery list '*lua*'
[IP-] [ ] dev-lang/lua-5.1.5-r3:0

darktable requires Lua 5.2. If that isn't available in Gentoo you can just pass
-DDONT_USE_INTERNAL_LUA=Off
to cmake when compiling darktable. We bundle it for those distributions that lack it as Lua is changing a lot between minor versions.

In the future we will most likely make this a hard requirement in darktable to avoid surprises like this.

There is no Gentoo use flag for darktable that allows to disable Lua support, and during ./autogen.sh, GEGL does list Lua as available and configured.

Elle

Tobias

Having spent the last 45 minutes reinstalling Lua and and then darktable through Gentoo portage, here's which version of Lua Gentoo says I'm using:

equery list lua [IP-] [ ] dev-lang/lua-5.2.3-r1:5.2

$ eselect lua list [1] 5.2 *

The little * means that's the selected version of Lua that all installed software that uses lua should use. However, darktable still has Lua disabled:

$ darktable --version this is darktable 2.0.3
copyright (c) 2009-2015 johannes hanika darktable-dev@lists.darktable.org

compile options: normal build
OpenMP support enabled
OpenCL support disabled
Lua support disabled
Colord support disabled
gPhoto2 support enabled
GraphicsMagick support enabled

On 04/26/2016 07:20 AM, Tobias Ellinghaus wrote:

darktable requires Lua 5.2. If that isn't available in Gentoo you can just pass
-DDONT_USE_INTERNAL_LUA=Off
to cmake when compiling darktable. We bundle it for those distributions that
lack it as Lua is changing a lot between minor versions.

I don't know how to modify Gentoo builds, and really don't want to learn how. It would be easier for me to download and install darktable from source, which I'll try next.

In the future we will most likely make this a hard requirement in darktable to avoid surprises like this.

This might be a good thing to do ASAP as it's not a good thing to get the embedded jpeg when really one is trying to open a raw file.

If the darktable plug-in isn't working, it might be better if GIMP issued a warning that it's not possible to open the raw file using the darktable plug-in. Giving the user an 8-bit jpeg when really they wanted to open a raw file might give users the wrong idea that GIMP only supports opening 8-bit jpegs produced from raw files.

Here's the terminal output I get when attempting to open a raw file using the darktable plug-in. Nothing in the terminal output would tell the user that the problem is that darktable isn't really opening the raw file:
$ ../../rungimpdefault
This is a development version of GIMP. Debug messages may appear here.

gimp_display_shell_profile_update gimp_display_shell_profile_update
magic match 4 on file-tiff-load
best magic match on file-tiff-load
TIFF image: Unknown field with tag 513 (0x201) encountered

TIFF image: Unknown field with tag 514 (0x202) encountered

TIFF image: TIFF directory is missing required "ImageLength" field

TIFF image: Unknown field with tag 50649 (0xc5d9) encountered

TIFF image: Photometric tag value assumed incorrect, assuming data is YCbCr instead of RGB

TIFF image: Unknown field with tag 50648 (0xc5d8) encountered

TIFF image: Unknown field with tag 50656 (0xc5e0) encountered

TIFF image: Unknown field with tag 50752 (0xc640) encountered

TIFF image: TIFF directory is missing required "ImageLength" field

TIFF image: Photometric tag is missing, assuming data is YCbCr

TIFF image: SamplesPerPixel tag is missing, applying correct SamplesPerPixel value of 3

TIFF image: Subsampling tag is not set, yet subsampling inside JPEG data [2,1] does not match default values [2,2]; assuming subsampling inside JPEG data is correct

bps: 8
photomet: 6 (3)
load_rgba
TIFF image: Depreciated and troublesome old-style JPEG compression mode, please convert to new-style JPEG compression and notify vendor of writing software

Invalid UTF-8 in metadata value Iptc.Application2.Copyright, encoding as base64: Q29weXJpZ2h0IKkgMjAwNyBFbGxlIFN0b25lLCBhbGwgcmlnaHRzIHJlc2VydmVkLgA= gimp_display_shell_profile_update
src_profile: GIMP built-in sRGB
src_format: R'G'B'A u8
dest_format: R'G'B'A u8
gimp_display_shell_profile_update
src_profile: GIMP built-in sRGB
src_format: R'G'B'A u8
dest_format: R'G'B'A u8

Best,
Elle

OK, so I downloaded the source code from the darktable website and build darktable from source:

$ darktable --version this is darktable archive-c2f7fdb1fce2d1206cb6b86d19a2de03f71e2448 copyright (c) 2009-2015 johannes hanika darktable-dev@lists.darktable.org

compile options: normal build
OpenMP support enabled
OpenCL support disabled
Lua support enabled, API version 3.0.0 Colord support disabled
gPhoto2 support enabled
GraphicsMagick support enabled

Then I rebuilt babl/GEGL/libmypaint/GIMP from scratch.

Navigating to the folder to open the CR2 file, and selecting the file type, there is still no CR2 option listed in the file type drop-down (http://ninedegreesbelow.com/bug-reports/gimp29/darktable-plug-in.jpg).

Opening the CR2 file still results in getting the 8-bit embedded jpeg.

So I guess I still don't know whatever it is that I might be doing wrong.

Best, Elle

On Tue, 2016-04-26 at 09:37 -0400, Elle Stone wrote:

OK, so I downloaded the source code from the darktable website and build 
darktable from source:

$ darktable --version this is darktable archive-c2f7fdb1fce2d1206cb6b86d19a2de03f71e2448

That version string won't be parsed by the GIMP plugin :/

Tobias, any idea?

Regards, Mitch

copyright (c) 2009-2015 johannes hanika darktable-dev@lists.darktable.org

compile options:    normal build
   OpenMP support enabled
   OpenCL support disabled
   Lua support enabled, API version 3.0.0    Colord support disabled
   gPhoto2 support enabled
   GraphicsMagick support enabled

Then I rebuilt babl/GEGL/libmypaint/GIMP from scratch.

Navigating to the folder to open the CR2 file, and selecting the file 
type, there is still no CR2 option listed in the file type drop-down  (http://ninedegreesbelow.com/bug-reports/gimp29/darktable-plug-in.jpg ).

Opening the CR2 file still results in getting the 8-bit embedded jpeg.

So I guess I still don't know whatever it is that I might be doing wrong.

Best,
Elle

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

that version looks like it's from a git-archive snapshot.. maybe the silly tar.gz that github provides as auto-generated tarball [0]? that doesn't work. either use git clone or the .tar.xz we provide with the releases.

-jo

[0] https://github.com/darktable-org/darktable/releases ``as always, please don't use the autogenerated tarball provided by github, but only our tar.xz.''

On Wed, Apr 27, 2016 at 3:44 AM, Michael Natterer wrote:

On Tue, 2016-04-26 at 09:37 -0400, Elle Stone wrote:

OK, so I downloaded the source code from the darktable website and build
darktable from source:

$ darktable --version this is darktable archive-c2f7fdb1fce2d1206cb6b86d19a2de03f71e2448

That version string won't be parsed by the GIMP plugin :/

Tobias, any idea?

Regards, Mitch

copyright (c) 2009-2015 johannes hanika darktable-dev@lists.darktable.org

compile options: normal build
OpenMP support enabled
OpenCL support disabled
Lua support enabled, API version 3.0.0 Colord support disabled
gPhoto2 support enabled
GraphicsMagick support enabled

Then I rebuilt babl/GEGL/libmypaint/GIMP from scratch.

Navigating to the folder to open the CR2 file, and selecting the file
type, there is still no CR2 option listed in the file type drop-down (http://ninedegreesbelow.com/bug-reports/gimp29/darktable-plug-in.jpg ).

Opening the CR2 file still results in getting the 8-bit embedded jpeg.

So I guess I still don't know whatever it is that I might be doing wrong.

Best,
Elle

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

_______________________________________________ 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

On 04/26/2016 12:13 PM, johannes hanika wrote:

that version looks like it's from a git-archive snapshot.. maybe the silly tar.gz that github provides as auto-generated tarball [0]? that doesn't work. either use git clone or the .tar.xz we provide with the releases.

-jo

[0]https://github.com/darktable-org/darktable/releases ``as always, please don't use the autogenerated tarball provided by github, but only our tar.xz.''

Hmm, my apologies. I downloaded the file that said "source code" instead of the file named "darktable-2.0.3.tar.xz".

After installing the version of darktable in darktable-2.0.3.tar.xz, the darktable plug-in does work with GIMP. Many thanks!

On Wed, Apr 27, 2016 at 3:44 AM, Michael Natterer wrote:

On Tue, 2016-04-26 at 09:37 -0400, Elle Stone wrote:

OK, so I downloaded the source code from the darktable website and build
darktable from source:

$ darktable --version this is darktable archive-c2f7fdb1fce2d1206cb6b86d19a2de03f71e2448

That version string won't be parsed by the GIMP plugin :/

Tobias, any idea?

Regards, Mitch

Best,
Elle

http://ninedegreesbelow.com
Color management and free/libre photography

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

On 04/27/2016 12:11 PM, Elle Stone wrote:

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?

Uninstalling darktable does allow the user to use the PhotoFlow raw plug-in. But this doesn't seem like a very user-friendly way to proceed. Also, it only seems to work if GIMP is recompiled and reinstalled *after* darktable has been uninstalled. Or at least delete the config folder, or whatever file in the config folder holds information about the raw plug-ins.

So is there some place in the GIMP UI - that so far I haven't been able to find - to choose which raw plug-in to use?

If not, are there plans to add a way in the GIMP UI for users to choose which raw plug-in to use?

Best, Elle

On 28/04/16 12:31, Elle Stone wrote:

On 04/27/2016 12:11 PM, Elle Stone wrote:

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?

Uninstalling darktable does allow the user to use the PhotoFlow raw plug-in. But this doesn't seem like a very user-friendly way to proceed. Also, it only seems to work if GIMP is recompiled and reinstalled *after* darktable has been uninstalled. Or at least delete the config folder, or whatever file in the config folder holds information about the raw plug-ins.

So is there some place in the GIMP UI - that so far I haven't been able to find - to choose which raw plug-in to use?

If not, are there plans to add a way in the GIMP UI for users to choose which raw plug-in to use?

Perhaps the best solution is to use the stand-alone version of the plugins. Of course, if these could save to high-bit-depth XCF directly, that would be even nicer.

Hi!

I’m not sure to understand what you mean by "if these could save to high-bit-depth XCF directly, that would be even nicer”, but what I can say is that photoflow works as a “native” plug-in, in the sense that it does not call an external program, and it copies the output into the GEGL buffer of a newly created GIMPO image.

The code is very similar to UFraw in this respect, except that the image data is passed in 32-bits floating point format.

Hope this helps.

On 28 Apr 2016, at 19:09, Ofnuts wrote:

On 28/04/16 12:31, Elle Stone wrote:

On 04/27/2016 12:11 PM, Elle Stone wrote:

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?

Uninstalling darktable does allow the user to use the PhotoFlow raw plug-in. But this doesn't seem like a very user-friendly way to proceed. Also, it only seems to work if GIMP is recompiled and reinstalled *after* darktable has been uninstalled. Or at least delete the config folder, or whatever file in the config folder holds information about the raw plug-ins.

So is there some place in the GIMP UI - that so far I haven't been able to find - to choose which raw plug-in to use?

If not, are there plans to add a way in the GIMP UI for users to choose which raw plug-in to use?

Perhaps the best solution is to use the stand-alone version of the plugins. Of course, if these could save to high-bit-depth XCF directly, that would be even nicer. _______________________________________________ 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

On 04/28/2016 01:09 PM, Ofnuts wrote:

Uninstalling darktable does allow the user to use the PhotoFlow raw plug-in. But this doesn't seem like a very user-friendly way to proceed. Also, it only seems to work if GIMP is recompiled and reinstalled *after* darktable has been uninstalled. Or at least delete the config folder, or whatever file in the config folder holds information about the raw plug-ins.

So is there some place in the GIMP UI - that so far I haven't been able to find - to choose which raw plug-in to use?

If not, are there plans to add a way in the GIMP UI for users to choose which raw plug-in to use?

Perhaps the best solution is to use the stand-alone version of the plugins. Of course, if these could save to high-bit-depth XCF directly, that would be even nicer.

Using the stand-alone versions of the user's preferred raw processor pretty much negates the value of having a plug-in.

A much better solution is to allow users to specify a preferred plug-in, perhaps by an option in Preferences.

I know the immediate reaction might be "We don't want to confuse users by adding more otions in preferences". But in point of fact users do have very strong ideas about which raw processer they prefer to use. So they won't be confused.

Before the darktable plug-in was developed and made into a default GIMP plug-in, users had a choice of which raw plug-in they installed in the plug-ins folder. But that choice no longer works. Right now exercising user choice regarding which raw processor plug-in to use is cumbersome and non-obvious:

If no version of darktable is installed, the user can still install and use a different raw plug-in. But if the user also wants to occasionally use darktable, they are out of luck or in for onerous workarounds, because as soon as darktable is installed GIMP tries to use the darktable plug-in.

If the wrong version of darktable/Lua is installed, GIMP tries (or did try, I haven't reinstalled the wrong version of darktable) to use darktable, and instead opens the jpeg embedded in the raw file, which is much worse than just issuing an error message.

If the right version of darktable/Lua is installed, GIMP uses the darktable plug-in and the user has no choice in the matter.

If darktable is then uninstalled and the user tries to go back to using their chosen raw processer plug-in, GIMP issues an error message: "Failed to execute child process "darktable" (No such file or directory)".

To get past the error message, the user needs to delete the config folder, or else figure out which file in the config folder needs to be modified. The file to modify is pluginrc.

Here's the text from pluginrc that currently keeps the user from using a raw plug-in other than the darktable plug-in, even after uninstalling darktable. Delete the following text from pluginrc after you uninstall darktable, and you can use a different raw plug-in:

(plug-in-def "/home/elle/code/gimpdefault/install/lib/gimp/2.0/plug-ins/file-darktable" 1461837410
(proc-def "file-cr2-load" 1
"Load files in the CR2 raw format via darktable" "This plug-in loads files in Canon's raw CR2 format by calling darktable."
"Tobias Ellinghaus"
"Tobias Ellinghaus"
"2016"
"Canon CR2 raw"
0
(icon icon-name -1 "")
(load-proc
(extension "cr2")
(magic "0,string,II*\\0\\020\\0\\0\\0CR") (mime-type "image/x-canon-cr2") (thumb-loader "file-cr2-load-thumb")) ""
3 1
(proc-arg 0 "run-mode" "The run mode { RUN-INTERACTIVE (0), RUN-NONINTERACTIVE (1) }")
(proc-arg 4 "filename" "The name of the file to load.") (proc-arg 4 "raw-filename" "The name entered") (proc-arg 13 "image" "Output image")) (proc-def "file-cr2-load-thumb" 1 "Load thumbnail from a CR2 raw image via darktable" "This plug-in loads a thumbnail from Canon's raw CR2 images by calling darktable-cli."
"Tobias Ellinghaus"
"Tobias Ellinghaus"
"2016"
""
0
(icon icon-name -1 "")
""
2 3
(proc-arg 4 "filename" "The name of the file to load") (proc-arg 0 "thumb-size" "Preferred thumbnail size") (proc-arg 13 "image" "Thumbnail image") (proc-arg 0 "image-width" "Width of full-sized image") (proc-arg 0 "image-height" "Height of full-sized image")) (proc-def "file-nef-load" 1
"Load files in the NEF raw format via darktable" "This plug-in loads files in Nikon's raw NEF format by calling darktable."
"Tobias Ellinghaus"
"Tobias Ellinghaus"
"2016"
"Nikon NEF raw"
0
(icon icon-name -1 "")
(load-proc
(extension "nef")
(magic
"0,string,MM\\0*\\0\\0\\0\\010,0,string,II*\\0\\010\\0\\0\\0") (mime-type " image/x-nikon-nef ") (thumb-loader "file-nef-load-thumb")) ""
3 1
(proc-arg 0 "run-mode" "The run mode { RUN-INTERACTIVE (0), RUN-NONINTERACTIVE (1) }")
(proc-arg 4 "filename" "The name of the file to load.") (proc-arg 4 "raw-filename" "The name entered") (proc-arg 13 "image" "Output image")) (proc-def "file-nef-load-thumb" 1 "Load thumbnail from a NEF raw image via darktable" "This plug-in loads a thumbnail from Nikon's raw NEF images by calling darktable-cli."
"Tobias Ellinghaus"
"Tobias Ellinghaus"
"2016"
""
0
(icon icon-name -1 "")
""
2 3
(proc-arg 4 "filename" "The name of the file to load") (proc-arg 0 "thumb-size" "Preferred thumbnail size") (proc-arg 13 "image" "Thumbnail image") (proc-arg 0 "image-width" "Width of full-sized image") (proc-arg 0 "image-height" "Height of full-sized image")))

Best, Elle

On 04/28/2016 03:40 PM, Elle Stone wrote:

Delete the following text from pluginrc after you uninstall darktable, and you can use a different raw plug-in:

Is there an "order of preference" in the pluginrc file such that if a user installs a raw plugin, the installed raw plugin would take precedence over the built-in darktable raw plugin?

http://ninedegreesbelow.com
Color management and free/libre photography

On Thu, 2016-04-28 at 15:43 -0400, Elle Stone wrote:

On 04/28/2016 03:40 PM, Elle Stone wrote:

Delete the following text from pluginrc after you uninstall darktable,
and you can use a different raw plug-in:

Is there an "order of preference" in the pluginrc file such that if a 
user installs a raw plugin, the installed raw plugin would take  precedence over the built-in darktable raw plugin?

No there isn't but there will. This is work-in-progress. We'll probably end up with the plug-in having to specify "I am a raw importer", and a page in prefs to pick one of the installed importers.

Regards,
--Mitch

Michael Natterer (mitch@gimp.org) wrote:

On Thu, 2016-04-28 at 15:43 -0400, Elle Stone wrote:

On 04/28/2016 03:40 PM, Elle Stone wrote:

Delete the following text from pluginrc after you uninstall darktable,
and you can use a different raw plug-in:

Is there an "order of preference" in the pluginrc file such that if a 
user installs a raw plugin, the installed raw plugin would take  precedence over the built-in darktable raw plugin?

No there isn't but there will. This is work-in-progress. We'll probably end up with the plug-in having to specify "I am a raw importer", and a page in prefs to pick one of the installed importers.

An alternate idea might be to en/disable the file-plugins manually in the preferences. That would allow users to cut down on the number of file format options in the dropdown in the file open dialog. That way the really obscure file formats can be disabled and don't clutter the list...

Bye,
Simon

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

On 28/04/16 21:07, Carmelo DrRaw wrote:

Hi!

I’m not sure to understand what you mean by "if these could save to high-bit-depth XCF directly, that would be even nicer”, but what I can say is that photoflow works as a “native” plug-in, in the sense that it does not call an external program, and it copies the output into the GEGL buffer of a newly created GIMPO image.

The code is very similar to UFraw in this respect, except that the image data is passed in 32-bits floating point format.

Personally I don't use the raw processors as plugins. I use raw files when I have to do extensive work on the picture (otherwise the camera Jpeg is good enough). So I don't see the point of using a plugin to spend 20 minutes in the plugin without being able to use any Gimp functionality. I can just as well use an external program (which until recently, gave me a lot more choice...). And after these 20 minutes I want to have something I can show/share before doing further edits so I'll anyway do an export, and this export is also the file I will open in Gimp for final edits.

With 8-bit Gimp, a 8-bit PNG or high-quality JPEG is enough. With the new Gimp, it will be better to use some 16-bit format. There are several already (TIFF, 16-bit PNG...) but using XCF could have benefits (passing metadata, etc....).

On 04/28/2016 05:18 PM, Simon Budig wrote:

No there isn't but there will. This is work-in-progress. We'll probably end up with the plug-in having to specify "I am a raw importer", and a page in prefs to pick one of the installed importers.

An alternate idea might be to en/disable the file-plugins manually in the preferences. That would allow users to cut down on the number of file format options in the dropdown in the file open dialog. That way the really obscure file formats can be disabled and don't clutter the list...

Having the ability to en/disable file plugins sounds useful. GIMP supports a ton of file types and I suspect very few users routinely use more than a few of the supported file types. Looking through the list to select the desired file type takes a fair amount of scrolling (GIMP XCF is in the middle of the list and tiff is at the bottom) and sharp eyes to focus on the file type descriptions.

This sort of goes along with a request made recently to allow the user to enable/disable the loading of plug-ins in general. On a new fast system with a lot of available RAM, loading all the default plug-ins happens very quickly. But on older systems loading the plug-ins can take a noticeable amount of time.

Best, Elle