Re: [Gimp-developer] Cubic Interpolation vs No Halo

[Liam R. E. Quin]

On Fri, 2016-04-29 at 00:59 +0200, Nicolas Robidoux wrote:
> Liam:
> 
> Do you ever find LoHalo (snail crawling notwithstanding) worthwhile?

Yes, but because it's so slow I use it less than once a month.

It feels like it takes half an hour or so, but I suspect it's probably
more like 10 minutes.

Most often I'm working with scanned engravings that have lots of
almost-parallel almost-horizontal lines, and the trouble is moiré-like
patterns that creep in. A gaussian blur before down-scaling, followed
by a sharpen, usually helps. We lost the old gimp 2.6 sharpen filter,
but the newer unsharp filter works.

Sometimes lohalo scales down without introducing the problems.

Liam


-- 
Liam R. E. Quin 
___
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?

[Ofnuts]

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

___
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] Cubic Interpolation vs No Halo

[Nicolas Robidoux]

Liam:

Do you ever find LoHalo (snail crawling notwithstanding) worthwhile?

Nicolas
___
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] Cubic Interpolation vs No Halo

[Liam R. E. Quin]

On Wed, 2016-04-27 at 09:03 +0100, C R wrote:
> 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.

It depends on what you're doing - in some cases Cubic gives better
results. In addition nohalo and lohalo can take several minutes to
scale an image.

You can change the default tool option in preferences/tool options.

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

I'd rather see it moved out of tool options and into preferences with a
single setting in that case. In practice I fairly often copy a small
section of an image and experiment with a cobination of blur and
different downsizing algorithms. In addition, more upscaling options
would be good, maybe after 2.10 - waifu2x, if unencumbered, would be a
good candidate. So I think having the algorithm choice right there in
scale image makes experimentation easier, and helps people dscover the
option.

So maybe a preference to say the default would be good. And hey! there
is one :-)

Liam

-- 
Liam R. E. Quin 
___
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?

[Simon Budig]

Michael Natterer (mi...@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
-- 
  si...@budig.de  http://simon.budig.de/
___
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?

[Michael Natterer]

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

___
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/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
___
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/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 ")
   

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

[Carmelo DrRaw]

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

___
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] Re: Darktable plug-in in GIMP - Darktable for Windows?

[William Ferguson]

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 <
matth...@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 <
> p...@wahoo.no-ip.org > 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.orgopenSUSE Community Member
> facebook/ptilopteri
> > http://wahoo.no-ip.orgPhoto 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+unsubscr...@lists.darktable.org  darktable-dev%2bunsubscr...@lists.darktable.org>
> >
> >
> >
> >
>  ___
> darktable developer mailing list to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org  darktable-dev%2bunsubscr...@lists.darktable.org>
> >
> >
> >
> >
> 

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

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

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.orgopenSUSE Community Member
>> facebook/ptilopteri
>> http://wahoo.no-ip.orgPhoto 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+unsubscr...@lists.darktable.org
>>
>>
>
> ___
> darktable developer mailing list to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>
___
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

[aferrero1975]

Since a little while there is one more RAW loading plug-in available for
GIMP, based on the  PhotoFlow editor   
source code.

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.

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.

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!



--
View this message in context: 
http://gimp.1065349.n5.nabble.com/Introducing-the-PhotoFlow-GIMP-plug-in-tp47636.html
Sent from the Developers mailing list archive at Nabble.com.
___
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?

[Ofnuts]

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

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

[Elle Stone]

On 04/28/2016 06:00 AM, Tobias Ellinghaus wrote:

Am Mittwoch, 27. April 2016, 18:18:38 schrieb Elle Stone:



The darktable sRGB profile is a "V2 according to V4" profile with a
point TRC. So this profile clips out of gamut channel values in floating
point images.


Yes, what would you suggest? Using a different encoding for the TRC?


GIMP's internal sRGB profile is a V4 profile with a parametric TRC, so
GIMP's sRGB profile doesn't clip out of gamut channel values in floating
point images.


So is darktable's internal sRGB profile (the one you can select in "input color
profile"). We just export with a V2 to make it easy to actually look at the
image. And I don't expect people to export float images in sRGB.



I don't have any suggestions. You pinpoint the problem exactly:

* A V2 version of sRGB is better for images that are uploaded to the 
web, which I think is what you mean by "make it easy to actually look at 
the image". But if you mean something else, please clarify.


* Exporting floating point images that aren't encoded linearly seems 
like an odd thing to do, and especially so if the image contains out of 
gamut channel values.


The only solution to the problem that I can think of is user education:

1. For output of a finished "ready to display" image directly from 
darktable, export the image using darktable's V2 sRGB profile.


2. For exporting to disk for further editing at floating point 
precision, export a floating point linear gamma image. And deal with any 
out of gamut (and especially negative) channel values before using 
editing operations that involve multiplying by a non-gray color, and 
before trying to edit using nonlinearized RGB. This is a bit difficult 
to keep track of in GIMP as some editing operations do work by default 
on RGB encoded using the sRGB TRC, even if the image was opened in GIMP 
as a linear gamma image.


People wanting to export images for printing on wider gamut photographic 
printers of course aren't covered by these two options. They probably 
would want to export using a wider gamut color 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

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

[Elle Stone]

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
___
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, 18:18:38 schrieb Elle Stone:
> On 04/27/2016 05:11 PM, Tobias Ellinghaus wrote:
> > 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]?
> > 
> > [0] https://houz.org/tmp/darktable_profiles_2.0.4.tgz
> 
> Using iccToXml to check the colorants and chad, the colorants and chad
> are perfect for all four profiles.

Good, thanks for checking.

> The darktable sRGB profile is a "V2 according to V4" profile with a
> point TRC. So this profile clips out of gamut channel values in floating
> point images.

Yes, what would you suggest? Using a different encoding for the TRC?

> GIMP's internal sRGB profile is a V4 profile with a parametric TRC, so
> GIMP's sRGB profile doesn't clip out of gamut channel values in floating
> point images.

So is darktable's internal sRGB profile (the one you can select in "input color 
profile"). We just export with a V2 to make it easy to actually look at the 
image. And I don't expect people to export float images in sRGB.

> I don't know what the actual rationale is for darktable to make a V2
> version of sRGB. But at this point in time a V2 profile is the right
> choice for output to the web, for maximum compatibility with the various
> browsers (even Firefox doesn't read V4 profiles unless the user changes
> the gfx settings in about.config).

That.

> 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

[johannes hanika]

On Thu, Apr 28, 2016 at 10:18 AM, Elle Stone
 wrote:
> On 04/27/2016 05:11 PM, Tobias Ellinghaus wrote:
>>
>> 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]?
>>
>> [0] https://houz.org/tmp/darktable_profiles_2.0.4.tgz
>>
>
> Using iccToXml to check the colorants and chad, the colorants and chad are
> perfect for all four profiles.
>
> The darktable sRGB profile is a "V2 according to V4" profile with a point
> TRC. So this profile clips out of gamut channel values in floating point
> images.
>
> GIMP's internal sRGB profile is a V4 profile with a parametric TRC, so
> GIMP's sRGB profile doesn't clip out of gamut channel values in floating
> point images.
>
> I don't know what the actual rationale is for darktable to make a V2 version
> of sRGB. But at this point in time a V2 profile is the right choice for
> output to the web, for maximum compatibility with the various browsers (even
> Firefox doesn't read V4 profiles unless the user changes the gfx settings in
> about.config).

yeah, the rationale was exactly the compatibility issue. fwiw, the
tonecurve code in darktable will not clip any values, but extrapolate
the tonecurves using a fitted gamma extension (that holds for all
curves, some are clipped at 0, others are extended both ways).

also, darktable will happily output negative floating point values
(out of gamut ones) and store them in pfm (making the exact choice of
output colour space somewhat irrelevant). i would need to check the
exr code about this.

it's probably a good idea to double check what kind of data makes it
into gimp in all those cases (clipped tonecurves, out of gamut
negative values).

-jo
___
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] Introducing the PhotoFlow GIMP plug-in

[Shlomi Fish]

Hi Andrea,

thanks for your contribution!

Regards,

Shlomi Fish

On Wed, 27 Apr 2016 17:57:52 +0200
Carmelo DrRaw  wrote:

> 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. 
> 
___
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] Cubic Interpolation vs No Halo

[C R]

Thanks Liam. I suppose this will work okay for my purpose. Thanks for the
tip.

-C
On 27 Apr 2016 6:09 pm, "Liam R. E. Quin"  wrote:

> On Wed, 2016-04-27 at 09:03 +0100, C R wrote:
> > 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.
>
> It depends on what you're doing - in some cases Cubic gives better
> results. In addition nohalo and lohalo can take several minutes to
> scale an image.
>
> You can change the default tool option in preferences/tool options.
>
> > 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.
>
> I'd rather see it moved out of tool options and into preferences with a
> single setting in that case. In practice I fairly often copy a small
> section of an image and experiment with a cobination of blur and
> different downsizing algorithms. In addition, more upscaling options
> would be good, maybe after 2.10 - waifu2x, if unencumbered, would be a
> good candidate. So I think having the algorithm choice right there in
> scale image makes experimentation easier, and helps people dscover the
> option.
>
> So maybe a preference to say the default would be good. And hey! there
> is one :-)
>
> Liam
>
> --
> Liam R. E. Quin 
>
___
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