darktable

Every now and then the question arises why we don’t have a button in darktable to open the current image in GIMP. Everytime I answer more or less the same. The arguments of those requesting the button are along the line of “$PROGRAM has it, so it ... [More] shouldn’t be hard to do” and “I really need to do some small retouching, so it would save me lots of time”. Well, to understand why we don’t have it I have to stress two features of darktable. First of all, every action is done non-destructive. What that means is that you never edit the actual data in your raw file, but “record” a list of actions (the history in darkroom mode and the XMP files) which shall be executed to get the final image. This list can be changed afterwards without negative side effects since those actions can just be recomputed. The second nice thing in darktable is that we work with high bit depths (32 bit floating point) to get the best possible result. Let’s have a look at GIMP next. None of the operations (with a few exceptions like layer creation, …) are non-destructive, and about bit depth in GIMP has been written enough. “What are the consequences?” you might wonder. Well, we would have to export the image and tell GIMP to open it, since plain image files is the only common language these two applications speak. That’s easy. However, what happens if you want to change the processing in darktable afterwards (remember, non-destructive editing)? All your work in GIMP is useless now. There is hope though. GIMP is currently moving to gegl as the new underlying core. This will bring two features (besides others): non-destructive editing and high bit depths. Sounds familiar? Once that is about to happen we can resurrect the use of gegl in darktable (we actually had it once, but it didn’t work well). Having all our processing as gegl operators it should be straight forward to hand all of the darktable processing over to gimp which can carry on with editing the file and passing the result back to darktable. At no point in this process we would lose control over the result as anything can be tweaked later on and has the best possible quality. Until then, it doesn’t make sense to ask for passing an image over to GIMP (or any other image manipulation program for that matter) as it would be a sink in our pipeline. One last thing: I love GIMP, use it all the time and think these guys (and gals) are doing a great job. They have about the same number of developers as we have, while their code base is several orders of magnitude bigger. [Less]

Every now and then the question arises why we don’t have a button in darktable to open the current image in GIMP. Everytime I answer more or less the same. The arguments of those requesting the button are along the line of “$PROGRAM has it, so it ... [More] shouldn’t be hard to do” and “I really need to do some small retouching, so it would save me lots of time”. Well, to understand why we don’t have it I have to stress two features of darktable. First of all, every action is done non-destructive. What that means is that you never edit the actual data in your raw file, but “record” a list of actions (the history in darkroom mode and the XMP files) which shall be executed to get the final image. This list can be changed afterwards without negative side effects since those actions can just be recomputed. The second nice thing in darktable is that we work with high bit depths (32 bit floating point) to get the best possible result. Let’s have a look at GIMP next. None of the operations (with a few exceptions like layer creation, …) are non-destructive, and about bit depth in GIMP has been written enough. “What are the consequences?” you might wonder. Well, we would have to export the image and tell GIMP to open it, since plain image files is the only common language these two applications speak. That’s easy. However, what happens if you want to change the processing in darktable afterwards (remember, non-destructive editing)? All your work in GIMP is useless now. There is hope though. GIMP is currently moving to gegl as the new underlying core. This will bring two features (besides others): non-destructive editing and high bit depths. Sounds familiar? Once that is about to happen we can resurrect the use of gegl in darktable (we actually had it once, but it didn’t work well). Having all our processing as gegl operators it should be straight forward to hand all of the darktable processing over to gimp which can carry on with editing the file and passing the result back to darktable. At no point in this process we would lose control over the result as anything can be tweaked later on and has the best possible quality. Until then, it doesn’t make sense to ask for passing an image over to GIMP (or any other image manipulation program for that matter) as it would be a sink in our pipeline. One last thing: I love GIMP, use it all the time and think these guys (and gals) are doing a great job. They have about the same number of developers as we have, while their code base is several orders of magnitude bigger. [Less]

we released version 0.8, which obsoletes 0.7.1 in a lot of ways: much faster image loading due to rawspeed, an awesome new library by klaus post @rawstudio lots of performance improvements in our caches and pixel pipelines (together with the above ... [More] like 5x—10x) gpu computing using opencl (for graphics boards that support it) for a lot of common modules, to give a huge performance boost overhauled collection module for more flexible image collections metadata editor (set author and copyright information etc) fast demosaicing now done on roi and in floating point HDR bracketing and tone mapping (somewhat experimental) flickr upload new languages: thai and japanese lots of new color matrices and white balance presets lots of bugfixes according to the git log, this release introduces over 900 new commits brought to you by (in order of commits): johannes hanika, Tobias Ellinghaus, Henrik Andersson, Pascal de Bruijn, Ger Siemerink, Bruce Guenter, Jose Carlos Garcia Sogo, Boucman, Alexandre Prokoudine, Simon Spannagel, Olivier, Jochen, Karl Mikaelsson, Jochen Schroeder, Brian Teague, Pascal Obry, calca, Ville Pätsi, Uli Scholler, Thierry Leconte, Pacsal de Bruijn, and Alex Chateau. special thanks to Pacsal ;) and to Robert Park for an awesome amount of color matrices created with his help, also for Klaus Staedtler for the new icons. [Less]

we released version 0.8, which obsoletes 0.7.1 in a lot of ways: much faster image loading due to rawspeed, an awesome new library by klaus post @rawstudio lots of performance improvements in our caches and pixel pipelines (together with the above ... [More] like 5x—10x) gpu computing using opencl (for graphics boards that support it) for a lot of common modules, to give a huge performance boost overhauled collection module for more flexible image collections metadata editor (set author and copyright information etc) fast demosaicing now done on roi and in floating point HDR bracketing and tone mapping (somewhat experimental) flickr upload new languages: thai and japanese lots of new color matrices and white balance presets lots of bugfixes according to the git log, this release introduces over 900 new commits brought to you by (in order of commits): johannes hanika, Tobias Ellinghaus, Henrik Andersson, Pascal de Bruijn, Ger Siemerink, Bruce Guenter, Jose Carlos Garcia Sogo, Boucman, Alexandre Prokoudine, Simon Spannagel, Olivier, Jochen, Karl Mikaelsson, Jochen Schroeder, Brian Teague, Pascal Obry, calca, Ville Pätsi, Uli Scholler, Thierry Leconte, Pacsal de Bruijn, and Alex Chateau. special thanks to Pacsal ;) and to Robert Park for an awesome amount of color matrices created with his help, also for Klaus Staedtler for the new icons. [Less]

we released version 0.8, which obsoletes 0.7.1 in a lot of ways: much faster image loading due to rawspeed, an awesome new library by klaus post @rawstudio lots of performance improvements in our caches and pixel pipelines (together with the above ... [More] like 5x–10x) gpu computing using opencl (for graphics boards that support it) for a lot of common plugins, to give a huge performance boost overhauled collection plugin for more … Continue reading → [Less]

we released version 0.7.1, a small bugfix release to fix up some nuisances in 0.7: some more white balance presets layout fixes for overlong profile names styles now actually work extensive documentation in form of screencasts enjoy the release ... [More] , but be aware that you’ll be missing out on a lot of significant speed improvements and cool new features when using the release instead of git :) [Less]

we released version 0.7.1, a small bugfix release to fix up some nuisances in 0.7: some more white balance presets layout fixes for overlong profile names styles now actually work extensive documentation in form of screencasts enjoy the release, but ... [More] be aware that you’ll be missing out on a lot of significant speed improvements and cool new features when using the release instead of git :) [Less]