[darktable-dev] Re: opencl fails on darktable git

[Matthias Bodenbinder]

Thank you! So easy. It was already fixed. Just needed another git pull.

Am 16.06.19 um 23:50 schrieb Axel Gerber:
> 
> See this:
> https://github.com/darktable-org/darktable/issues/2725
> 
> Von meinem Mobiltelefon gesendet
> 


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

[darktable-dev] Re: clang vs. gcc: dramatic performance difference

[Matthias Bodenbinder]

Am 15.09.18 um 10:30 schrieb Matthias Andree:
> Are you looking at stripped files, or what does "size" print? Are

Here is what "size" is saying:

clang binaries:

4# size *
   textdata bss dec hex filename
   2233 672   82913 b61 darktable
  975972400  48  100045   186cd darktable-chart
  100991000   8   111072b63 darktable-cli
   2668 720   83396 d44 darktable-cltest
  109681128   8   121042f48 darktable-cmstest
  108791000   8   118872e6f darktable-generate-cache
 6974188656   57680  763754   ba76a darktable-rs-identify

gcc binaries:

8# size *
   textdata bss dec hex filename
   2117 648 6083373 d2d darktable
  781202280  16   80416   13a20 darktable-chart
   9774 974 624   113722c6c darktable-cli
   2440 664   83112 c28 darktable-cltest
  108091104  16   119292e99 darktable-cmstest
  10386 960 624   119702ec2 darktable-generate-cache
 7474808040   57808  813328   c6910 darktable-rs-identify



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

[darktable-dev] Re: clang vs. gcc: dramatic performance difference

[Matthias Bodenbinder]

Am 13.09.18 um 07:38 schrieb Matthias Bodenbinder:
> export CC=/usr/bin/clang
> export CXX=/usr/bin/clang++
> INSTALL_PREFIX_DEFAULT="/opt/darktable-clang"
> 

This is working now. I had to remove the build directory after editing build.sh

I have the following packages installed on Manjaro:

clang 6.0.1-2
lib32-llvm-libs 6.0.1-1
llvm 6.0.1-4
llvm-libs 6.0.1-4
openmp 6.0.1-1

And the result is: The DT performance is the same! pixelpipe time differences 
are less than 3 %.

22# ./bench-script-clang-vs-gcc.sh   
3 runs no opencl
run clang 1: 16,704839 [dev_process_export] pixel pipeline processing took 
16,401 secs (128,498 CPU)
run gcc   1: 16,537099 [dev_process_export] pixel pipeline processing took 
16,205 secs (124,564 CPU)
run clang 2: 17,087163 [dev_process_export] pixel pipeline processing took 
16,798 secs (130,706 CPU)
run gcc   2: 16,566993 [dev_process_export] pixel pipeline processing took 
16,240 secs (124,351 CPU)
run clang 3: 16,728366 [dev_process_export] pixel pipeline processing took 
16,440 secs (128,643 CPU)
run gcc   3: 16,588298 [dev_process_export] pixel pipeline processing took 
16,260 secs (124,372 CPU)

3 runs with opencl
run clang 1: 7,668977 [dev_process_export] pixel pipeline processing took 7,298 
secs (20,387 CPU)
run gcc   1: 7,533379 [dev_process_export] pixel pipeline processing took 7,129 
secs (17,671 CPU)
run clang 2: 7,599311 [dev_process_export] pixel pipeline processing took 7,235 
secs (20,150 CPU)
run gcc   2: 7,516472 [dev_process_export] pixel pipeline processing took 7,115 
secs (17,731 CPU)
run clang 3: 7,639706 [dev_process_export] pixel pipeline processing took 7,275 
secs (20,923 CPU)
run gcc   3: 7,662320 [dev_process_export] pixel pipeline processing took 7,257 
secs (17,884 CPU)

But the binaries are a lot smaller: 

With clang:

13# ll /opt/darktable-clang/bin
insgesamt 4,6M
-rwxr-xr-x 1 matthias matthias  18K 15. Sep 09:29 darktable
-rwxr-xr-x 1 matthias matthias 273K 15. Sep 09:29 darktable-chart
-rwxr-xr-x 1 matthias matthias  44K 15. Sep 09:29 darktable-cli
-rwxr-xr-x 1 matthias matthias  19K 15. Sep 09:29 darktable-cltest
-rwxr-xr-x 1 matthias matthias  44K 15. Sep 09:29 darktable-cmstest
-rwxr-xr-x 1 matthias matthias  38K 15. Sep 09:29 darktable-generate-cache
-rwxr-xr-x 1 matthias matthias  11M 15. Sep 09:26 darktable-rs-identify

with gcc:

14# ll /opt/darktable-gcc/bin  
insgesamt 9,8M
-rwxr-xr-x 1 matthias matthias  32K 13. Sep 07:18 darktable
-rwxr-xr-x 1 matthias matthias 381K 13. Sep 07:18 darktable-chart
-rwxr-xr-x 1 matthias matthias  90K 13. Sep 07:18 darktable-cli
-rwxr-xr-x 1 matthias matthias  43K 13. Sep 07:18 darktable-cltest
-rwxr-xr-x 1 matthias matthias  59K 13. Sep 07:18 darktable-cmstest
-rwxr-xr-x 1 matthias matthias  58K 13. Sep 07:18 darktable-generate-cache
-rwxr-xr-x 1 matthias matthias  20M 13. Sep 07:17 darktable-rs-identify

Kind Regards
Matthias


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

[darktable-dev] Re: clang vs. gcc: dramatic performance difference

[Matthias Bodenbinder]

Am 14.09.18 um 10:15 schrieb johannes hanika:
> hi,
> 
> clang needs libomp-dev, not libgomp which gcc uses. i assume you have
> that installed?

There is no such package in manjaro.  I have  openmp 6.0.1-1 with these files 
install

/usr/include/omp.h
/usr/include/ompt.h
/usr/lib/libiomp5.so
/usr/lib/libomp.so
/usr/lib/libomptarget.rtl.x86_64.so
/usr/lib/libomptarget.so
/usr/share/licenses/openmp/LICENSE



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

[darktable-dev] Re: clang vs. gcc: dramatic performance difference

[Matthias Bodenbinder]

Am 13.09.18 um 15:58 schrieb sturmflut:
> Hi all,
> 
> IIRC this has something to do with clang not linking against libatomic
> by default, but GCC doing so.
> 
> regards,
> Simon


And how to I make this happen with clang?


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

[darktable-dev] Re: clang vs. gcc: dramatic performance difference

[Matthias Bodenbinder]

Am 13.09.18 um 07:38 schrieb Matthias Bodenbinder:
> I assume I am missing some significant compiler options for clang. But dont 
> know what that is.
> Can somebody help me with that and tell me what I need to do to make the 
> clang binary faster?

I found these messages with clang enabled:

-- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) 
-- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES) 
-- Could NOT find OpenMP (missing: OpenMP_C_FOUND OpenMP_CXX_FOUND) 
CMake Warning at src/external/rawspeed/cmake/OpenMP.cmake:18 (message):
  Looking for OpenMP - failed.  utilities will not use openmp-based
  parallelization
Call Stack (most recent call first):
  src/external/rawspeed/CMakeLists.txt:186 (include)


What is missing? I installed openmp.


PS
I am using Manjaro


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

[darktable-dev] clang vs. gcc: dramatic performance difference

[Matthias Bodenbinder]

Hi,

now that google announced that they are using clang for compiling chrome I 
wanted to give it a try with DT. I was mainly interested to see what the 
performance impact is for the DT binary when using clang. 

I simply edited build.sh like this to use clang:

export CC=/usr/bin/clang
export CXX=/usr/bin/clang++
INSTALL_PREFIX_DEFAULT="/opt/darktable-clang"

Result: Without opencl the clang binary of DT is three(!) times slower than the 
gcc binary. And with opencl enabled it is two times slower. 

19# ./bench-script-clang-vs-gcc.sh
3 runs no opencl
run clang 1: 48,421557 [dev_process_export] pixel pipeline processing took 
48,120 secs (47,050 CPU)
run gcc   1: 16,068927 [dev_process_export] pixel pipeline processing took 
15,733 secs (121,951 CPU)
run clang 2: 48,346575 [dev_process_export] pixel pipeline processing took 
48,054 secs (47,014 CPU)
run gcc   2: 16,240577 [dev_process_export] pixel pipeline processing took 
15,914 secs (123,015 CPU)
run clang 3: 48,445406 [dev_process_export] pixel pipeline processing took 
48,151 secs (47,046 CPU)
run gcc   3: 16,402528 [dev_process_export] pixel pipeline processing took 
16,073 secs (122,371 CPU)

3 runs with opencl
run clang 1: 17,418728 [dev_process_export] pixel pipeline processing took 
14,533 secs (12,262 CPU)
run gcc   1: 9,936274 [dev_process_export] pixel pipeline processing took 7,124 
secs (17,697 CPU)
run clang 2: 14,816236 [dev_process_export] pixel pipeline processing took 
14,448 secs (12,028 CPU)
run gcc   2: 7,755369 [dev_process_export] pixel pipeline processing took 7,342 
secs (17,904 CPU)
run clang 3: 14,897759 [dev_process_export] pixel pipeline processing took 
14,528 secs (12,253 CPU)
run gcc   3: 7,838780 [dev_process_export] pixel pipeline processing took 7,437 
secs (17,954 CPU)

I assume I am missing some significant compiler options for clang. But dont 
know what that is.
Can somebody help me with that and tell me what I need to do to make the clang 
binary faster?

Thanks
Matthias



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

[darktable-dev] how to export files for gen_profile

[Matthias Bodenbinder]

Hi

I want to play around with noise profile for my Canon G9X MkII to verify if 
issue #11928 is really related to the noise profile 
(https://redmine.darktable.org/issues/11928 )

But I am struggling with the instructions: 
https://www.darktable.org/2012/12/profiling-sensor-and-photon-noise/

I have a series of shots, I import to DT and I apply 'raw linear.dtstyle'. It 
says I need to export the pictures but in which format? jpg, pfm, etc.?

And then, I understand that I need to export into the same directory where the 
RAW files are located. No subdirectory. Is that correct?

Thanks
Matthias



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

[darktable-dev] Re: color pixel artefacts with profiled denoise and blend mode HSV-Lightness

[Matthias Bodenbinder]

I created  bug report for this issue: https://redmine.darktable.org/issues/11928

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

[darktable-dev] Re: color pixel artefacts with profiled denoise and blend mode HSV-Lightness

[Matthias Bodenbinder]

Am 10.01.2018 um 20:56 schrieb Matthias Bodenbinder:
> Hi,
> 
> I see weird colored pixel when using profiled denoise with non-local means 
> and blend mode HSV-Lightness. Just using blend mode Lightness is fine. Please 
> see the attached screenshot. The corresponding RAW is here: 
> 
> https://www.dropbox.com/s/fx0sctylp6wbs28/IMG_0263.CR2?dl=0
> 
> Matthias
> 
> ___
> darktable developer mailing list
> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
> 


By the way, this is DT 2.4.0 on Manjaro.



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

[darktable-dev] Re: Canon Powershot G9X II not supported

[Matthias Bodenbinder]

Am 08.12.2017 um 10:31 schrieb Roman Lebedev:
>> I found that RAW from Canon Powershot G9X Mark II are not supported although 
>> the camera is listed as supported: 
>> http://www.darktable.org/resources/camera-support/
> Hmm, now that i actually look at the release notes, the camera is
> supported in 2.4.0rc0, *NOT* in any stable release.
> 

Thank you for this clarification. I was getting more and more confused.

So that means that http://www.darktable.org/resources/camera-support/ is wrong 
in the sense that it is not referring to latest stable DT, which is 2.2.5. But 
it actually shows the supported cameras for next release 2.4.

Matthias

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

[darktable-dev] Canon Powershot G9X II not supported

[Matthias Bodenbinder]

Hi,

since I did not get feedback on the user list I try it here.

I found that RAW from Canon Powershot G9X Mark II are not supported although 
the camera is listed as supported: 
http://www.darktable.org/resources/camera-support/

I am using DT 2.2.5 on Manjaro Linux. I am testing with this RAW file: 
https://raw.pixls.us/getfile.php/1575/nice/Canon%20-%20PowerShot%20G9%20X%20Mark%20II%20-%20RAW%20(3:2).CR2


7# darktable -d lighttable
RawSpeed:Unable to find camera in database: 'Canon' 'Canon PowerShot G9 X Mark 
II' ''
Please consider providing samples on , thanks!
[rawspeed] (Canon - PowerShot G9 X Mark II - RAW (3_2).CR2) Camera 'Canon' 
'Canon PowerShot G9 X Mark II', mode '' not supported, and not allowed to 
guess. Sorry.
[temperature] failed to read camera white balance information from `Canon - 
PowerShot G9 X Mark II - RAW (3_2).CR2'!
[temperature] failed to read camera white balance information from `Canon - 
PowerShot G9 X Mark II - RAW (3_2).CR2'!
allocation failed???
[colorin] `Canon Canon PowerShot G9 X Mark II' color matrix not found!
[colorin] `Canon Canon PowerShot G9 X Mark II' color matrix not found!
[colorin] `Canon Canon PowerShot G9 X Mark II' color matrix not found!
[temperature] failed to read camera white balance information from `Canon - 
PowerShot G9 X Mark II - RAW (3_2).CR2'!
[colorin] `Canon Canon PowerShot G9 X Mark II' color matrix not found!
[colorin] `Canon Canon PowerShot G9 X Mark II' color matrix not found!
[colorin] `Canon Canon PowerShot G9 X Mark II' color matrix not found!
[temperature] failed to read camera white balance information from `Canon - 
PowerShot G9 X Mark II - RAW (3_2).CR2'!
[colorin] `Canon Canon PowerShot G9 X Mark II' color matrix not found!
[colorin] `Canon Canon PowerShot G9 X Mark II' color matrix not found!
[colorin] `Canon Canon PowerShot G9 X Mark II' color matrix not found!

Matthias

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

[darktable-dev] german documentation

[Matthias Bodenbinder]

Hello,

I just want to bring to your attention that there is a new translation engine 
available which translates much, much better than anything google or Microsoft 
are doing: https://www.deepl.com/translator

May be it is a good idea to use this engine to translate the englisch 
documentation to german, french, spanish, italian, netherlands.

A few examples.

#1)
english:

The basic element for organizing images in darktable is called a film 
roll – a kind of virtual folder. Whenever you import images from disk, the 
images are organized in a film roll whose name is derived from the name of the 
disk folder. Re-importing a disk folder will add any new images to the existing 
film roll; images already present in the film roll are not touched.

german translation:

Das Grundelement für die Organisation von Bildern in Darktable heißt 
Filmrolle - eine Art virtueller Ordner. Immer wenn Sie Bilder von der 
Festplatte importieren, werden die Bilder in einer Filmrolle organisiert, deren 
Name sich vom Namen des Laufwerksordners ableitet. Beim Neuimport eines 
Disk-Ordners werden neue Bilder zum bestehenden Filmlauf hinzugefügt; bereits 
im Filmlauf befindliche Bilder bleiben unberührt.

#2) 
english:
First off, select what aspect ratio you want and size the crop 
boundaries by dragging border and corner handles. Use the button right of the 
aspect box, to swap between portrait and landscape mode. You can move around 
the crop rectangle by holding down left mouse button and move around. When you 
are done and want to execute the crop, just give focus to another module or 
double-click into the image base. You can at any time change your crop area by 
just revisiting this module. 

german translation:

Wählen Sie zunächst das gewünschte Seitenverhältnis aus und ziehen Sie die 
Rahmen- und Eckpunkte mit der Maus in die gewünschte Größe. Benutzen Sie die 
Schaltfläche rechts neben dem Seitenfenster, um zwischen Hoch- und Querformat 
umzuschalten. Sie können sich um das Rechteck herum bewegen, indem Sie die 
linke Maustaste gedrückt halten und sich bewegen. Wenn Sie fertig sind und den 
Zuschlag ausführen möchten, geben Sie einfach einem anderen Modul den Fokus 
oder doppelklicken Sie in die Bilddatenbank. Sie können jederzeit Ihren 
Schnittbereich ändern, indem Sie dieses Modul erneut aufrufen. 


I find the results pretty good!

Matthias

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

[darktable-dev] Re: DT 2.2.3 much faster than 2.2.1 !!

[Matthias Bodenbinder]

FYI

The performance difference DT self-compiled vs. distributions binary package 
has been confirmed for debian: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855359

Not sure about other distros. But could be similar.

Matthias



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

[darktable-dev] Re: DT 2.2.3 much faster than 2.2.1 !!

[Matthias Bodenbinder]

Am 17.02.2017 um 06:57 schrieb Matthias Bodenbinder:
> Am 16.02.2017 um 23:27 schrieb Tobias Ellinghaus:
> 
>> Neither module was changed between those two releases. Did you compile both 
>> versions yourself and are you sure that the compile flags are identical?
>>
>>> Good job! Thank you!
>>>
>>> Matthias
>>
> 
> I compiled 2.2.3 myself and took 2.2.1 from debian testing .
> 
> I will compile 2.2.1 myself and see.
> 
> Matthias
> 
> 

I checked it. This is indeed an issue with the self-compilation.

If I pull the source from debian testing (apt-get source darktable) and compile 
it by myself the benchmark is fast (15 s) compared to 22 s when I use the 
debian testing binaries.

This is somewhat shocking to me. Why is that? And could I eventually see 
similar performance improvements with other apps?

Matthias

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

[darktable-dev] Re: DT 2.2.3 much faster than 2.2.1 !!

[Matthias Bodenbinder]

Am 16.02.2017 um 23:27 schrieb Tobias Ellinghaus:

> Neither module was changed between those two releases. Did you compile both 
> versions yourself and are you sure that the compile flags are identical?
> 
>> Good job! Thank you!
>>
>> Matthias
> 

I compiled 2.2.3 myself and took 2.2.1 from debian testing .

I will compile 2.2.1 myself and see.

Matthias


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

[darktable-dev] DT 2.2.3 much faster than 2.2.1 !!

[Matthias Bodenbinder]

Hi,

since I have a new CPU and mainboard I did a lot of benchmarking. What I am 
basically doing is executing

darktable-cli bench.SRW test.jpg --core -d perf -d opencl

I got bench.SRW and bench.SRW.xmp somewhere from a darktable group. 

Anyhow, I am comparing the DT processing times shown in the log file like this:

[dev_process_export] pixel pipeline processing took 22,524 secs (173,824 CPU)

Today I compared DT 2.2.1 with 2.2.3. I did each benchmark 10 times and 
compared the results:

for i in $(seq 1 10); do echo $i; sh bench-script.sh | grep "pipeline 
processing took"; done

Interesting finding:
With DT 2.2.1 the processing time is around 22 seconds while with DT 2.2.3 the 
processing time is around 14 seconds. I briefly crosschecked with a testfile 
from a Canon 5Ds and the difference is 58 seconds to 34 seconds. 

This is an amazing speed up! Most of the time is saved in the profiled denoise 
(from 33 s to 25 s) and equalizer module (22 s to 7 s). I assume somebody did a 
really good job in optimizing the code of these modules.

Good job! Thank you!

Matthias

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

[darktable-dev] Re: kernel performance: 3.16 vs. 4.9

[Matthias Bodenbinder]

Am 05.02.2017 um 15:37 schrieb johannes hanika:
> hi,
> 
> how much do you trust your numbers? they look very weird to me. such a
> speedup sounds more like one is running single threaded :)
> 
> did you run it a couple of times one after the other? to rule out disk
> prefetching etc? using the minimum time of three consecutive runs may
> be a good indication. do you have any detailed logs where the time
> goes (i.e. which dt module)? i mean the detailed outputs of dt, or
> maybe a run through the kernel's perf? you sure the dt version is
> exactly the same? you didn't recompile?
> 
> cheers,
>  jo

Here are the 4 DT logs: kernel 3.6 with and without opencl and kernel 4.9 the 
same.

Matthias




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

3.6-with-opencl.out.gz
Description: application/gzip


3.6-without-opencl.out.gz
Description: application/gzip


4.9-with-opencl.out.gz
Description: application/gzip


4.9-without-opencl.out.gz
Description: application/gzip

[darktable-dev] Re: kernel performance: 3.16 vs. 4.9

[Matthias Bodenbinder]

Am 05.02.2017 um 15:37 schrieb johannes hanika:
> hi,
> 
> how much do you trust your numbers? they look very weird to me. such a
> speedup sounds more like one is running single threaded :)
> 
> did you run it a couple of times one after the other? to rule out disk
> prefetching etc? using the minimum time of three consecutive runs may
> be a good indication. do you have any detailed logs where the time
> goes (i.e. which dt module)? i mean the detailed outputs of dt, or
> maybe a run through the kernel's perf? you sure the dt version is
> exactly the same? you didn't recompile?

I reproduced the results a dozent times. The variance is between 1-2 seconds 
only.

I am comparing the time darktable is giving me in the debug output:

[dev_process_export] pixel pipeline processing took 9,080 secs (16,184 CPU)

Matthias

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

[darktable-dev] kernel performance: 3.16 vs. 4.9

[Matthias Bodenbinder]

Hi,

I have upgraded my PC to newest chipset and CPU: Kaby Lake, Z270 with i7-7700K.

Out of curiosity I did a kernel benchmark. Comparing darktable performance with 
kernel 3.16.0-4-amd64 and 4.9.0-1-amd64. I use the following command to run 
darktable:
darktable-cli test.CR2 test.jpg --core -d perf -d opencl

The results are surprising for me. Kernel 4.9 very much outperformance kernel 
3.16. Here are the results with and without opencl (using a Geforce GTX750TI):

kernel 3.16 kernel 4.9
with opencl 16 s9 s
without opencl  120 s   23 s

Without opencl, that is with pure CPU performance, the difference is a factor 
of 5! 

Why is that? What am I missing? I can hardly believe that kernel 4.9 is so much 
faster. 

Matthias

PS 
I have also posted this message to debian.user and I know that it is probably 
better placed into a kernel developer list. But may be some DT expert knows the 
answer or can eventually verify my results.

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

[darktable-dev] Re: compile DT with new exiv2 version

[Matthias Bodenbinder]

It is working now. Here is what I did:

I just upgraded to exvi2 0.25 from debian testing and elimitated all packages 
associated with version 0.24:

39# dpkg -l | grep exiv
ii  exiv2   0.25-3  
  amd64EXIF/IPTC/XMP metadata manipulation tool
ii  libexiv2-14:amd64   0.25-3  
  amd64EXIF/IPTC/XMP metadata manipulation library
ii  libexiv2-dev0.25-3  
  amd64EXIF/IPTC/XMP metadata manipulation library 
- development files

But that alone is not sufficient because it gives compilation errors with DT:

libdarktable.so: undefined reference to 
`Exiv2::XmpProperties::registerNs(std::string const&, std::string const&)'
libdarktable.so: undefined reference to `Exiv2::XmpParser::encode(std::string&, 
Exiv2::XmpData const&, unsigned short, unsigned int)'

Reason is that exvi2 from testing was compiled with the newer gcc in testing. 
So I had to upgrade that as well: sudo apt-get install -t testing gcc g++

That was it. I hope there are no other dependencies to old libexiv2 0.24 which 
I destroyed with this activitiy.

Matthias

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

[darktable-dev] Re: compile DT with new exiv2 version

[Matthias Bodenbinder]

Am 03.01.2017 um 17:31 schrieb c...@0n0e.com:
> On 01/03/2017 03:22 AM, Matthias Bodenbinder wrote:
>> Hello,
>>
>> I am running Mint LMDE and can not easily install exiv2 0.25 from testing 
>> because it has too many dependencies.
>> I compiled version 0.25 by myself and installed it in /home/software/exiv2. 
>> In parallel I still have the default exiv2 version 0.24.
>>
>> How can I tell my self compiled darktable to use the new exvi2 0.25? It is 
>> still grabing the old version:
>> libexiv2.so.13 => /usr/lib/x86_64-linux-gnu/libexiv2.so.13
> 
> Does the following work? (Change filepaths and filenames as needed.)
> 
> $ export LD_PRELOAD=/home/software/exiv2/libexiv2.so.13
> $ /opt/darktable/bin/darktable

That is interesting. With this setting it does ot work either but I see a 
different behaviour. The lens identifier in DT is left blank and on the 
commandline I see the following errors during import of the CR2 files:

[exiv2] /home/matthias/Bilder/Fotos/tmp/16-35/IMG_0972.CR2: Image type 
/home/matthias/Bilder/Fotos/tmp/16-35/IMG_0972.CR2 is not supported
[exiv2] /home/matthias/Bilder/Fotos/tmp/16-35/IMG_0972.CR2: Image type 
/home/matthias/Bilder/Fotos/tmp/16-35/IMG_0972.CR2 is not supported
[exiv2] /home/matthias/Bilder/Fotos/tmp/16-35/IMG_0983.CR2: Image type 
/home/matthias/Bilder/Fotos/tmp/16-35/IMG_0983.CR2 is not supported

Weird.
Matthias



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

[darktable-dev] compile DT with new exiv2 version

[Matthias Bodenbinder]

Hello,

I am running Mint LMDE and can not easily install exiv2 0.25 from testing 
because it has too many dependencies.
I compiled version 0.25 by myself and installed it in /home/software/exiv2. In 
parallel I still have the default exiv2 version 0.24.

How can I tell my self compiled darktable to use the new exvi2 0.25? It is 
still grabing the old version:
libexiv2.so.13 => /usr/lib/x86_64-linux-gnu/libexiv2.so.13

Your help is appreciated.
Thank you
Matthias

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

[darktable-dev] Re: darktable 2.2.0 released

[Matthias Bodenbinder]

Many many thanks to the developers. What a Christmas present!

Matthias

Am 24.12.2016 um 17:50 schrieb Tobias Ellinghaus:
> we're proud to finally announce the new feature release of darktable, 2.2.0!
> 
> the github release is here: https://github.com/darktable-org/darktable/
> releases/tag/release-2.2.0.
> 
> as always, please don't use the autogenerated tarball provided by github, but 
> only our tar.xz. the sha256 checksum is:
> 
> 3eca193831faae58200bb1cb6ef29e658bce43a81706b54420953a7c33d79377  
> darktable-2.2.0.tar.xz
> 75d5f68fec755fefe6ccc82761d379b399f9fba9581c0f4c2173f6c147a0109f  
> darktable-2.2.0.dmg
> 
> and the changelog as compared to 2.0.0 can be found below.
> 
> when updating from the currently stable 2.0.x series, please bear in mind 
> that 
> your edits will be preserved during this process, but it will not be possible 
> to downgrade from 2.2 to 2.0.x any more.
> 
> - Well over 2k commits since 2.0.0
> - 298 pull requests handled
> - 360+ issues closed
> 
> Gource visualization of git log from 2.0.0 to right before 2.2.0:
> https://youtu.be/E2UU5x7sS3g
> 
> The Big Ones:
> 
> - Add new automatic perspective correction module (https://www.darktable.org/
> 2016/03/a-new-module-for-automatic-perspective-correction/)
> - Liquify tool for all your fancy pixel moving (https://www.darktable.org/
> 2016/04/liquify-liquify/)
> - A new image module to use a Color Look Up Table (CLUT) to change colors in 
> the image 
> (https://www.darktable.org/2016/05/colour-manipulation-with-the-colour-checker-lut-module/)
> - In Highlight reconstruction module, the mode LCh reconstruction was 
> completely rewritten, and is no longer useless!
> - A new tool, darktable-chart, that goes along with the CLUT module, to 
> create 
> styles for the latter
> - Exposure fusion in the basecurve module to lower the dynamic range of 
> images 
> (https://www.darktable.org/2016/08/compressing-dynamic-range-with-exposure-fusion/)
> - Add new raw overexposure indication 
> (https://www.darktable.org/2016/10/raw-overexposed/)
> - Darkroom: the preview (in top-left corner) is now no longer pre-demosaiced 
> (but just downscaled without demosaicing it at the same time), thus the 
> preview, color picker, histogram show the proper results, especially when 
> there is highlight clipping.
> 
> Quite Interesting Changes:
> 
> - Split the database into a library containing images and a general one with 
> styles, presets and tags. That allows having access to those when for example 
> running with a :memory: library
> - Support running on platforms other than x86 (64bit little-endian, currently 
> ARM64 only) (https://www.darktable.org/2016/04/running-on-non-x86-platforms/)
> - darktable is now happy to use smaller stack sizes (no less than 256Kb). 
> That 
> should allow using musl libc
> - Allow darktable-cli to work on directories
> - Allow to import/export tags from Lightroom keyword files
> - Allow using modifier keys to modify the step for sliders and curves. 
> Defaults: Ctrl - x0.1; Shift - x10
> - Allow using the [keyboard] cursor keys to interact with sliders, comboboxes 
> and curves; modifiers apply too
> - Support presets in "more modules" so you can quickly switch between your 
> favorite sets of modules shown in the GUI
> - Add range operator and date compare to the collection module
> - Add basic undo/redo support for the darkroom (masks are not accounted !)
> - Support the Exif date and time when importing photos from camera
> - Input color profile module, when profile is just matrix (and linear curve), 
> is 
> 1/3 faster now.
> - Rudimentary CYGM and RGBE color filter array support
> - Nicer web gallery exporter -- now touch friendly!
> - OpenCL implementation of VNG/VNG4 demosaicing methods
> - OpenCL implementation of Markesteijn demosaicing method for X-Trans sensors
> - Filter-out some useless EXIF tags when exporting, helps keep EXIF size 
> under 
> ~64Kb
> - OpenCL: properly discard CPU-based OpenCL devices. Fixes crashes on startup 
> with some partially-working OpenCL implementations like pocl.
> - darktable-cli: do not even try to open display, we don't need it.
> - Hotpixels module: make it actually work for X-Trans
> - Cmstest tool should now produce correct output in more cases, especially in 
> multi-monitor setups.
> - Darkroom histogram now uses more bins: use all 8-bit of the output, not 
> just 
> 6.
> 
> Some More Changes, Probably Not Complete:
> 
> - Drop darktable-viewer tool in favor of slideshow view
> - Remove gnome keyring password backend, use libsecret instead
> - When using libsecret to store passwords then put them into the correct 
> collection
> - Hint via window manager when import/export is done
> - Quick tagging searches anywhere, not just at the start of tags
> - The sidecar XMP schema for history entries is now more consistent and less 
> error prone
> - Rawspeed: fixes for building with libjpeg (as opposed to libjpeg-turbo)
> - Give the choice of 

[darktable-dev] Re: Bottom buttons right click

[Matthias Bodenbinder]

Am 08.12.2016 um 20:58 schrieb Tobias Ellinghaus:
> I just installed Ubuntu in a VM, installed Gnome Shell and darktable from the 
> PPA. Everything is working normal for me. 

May be this is something Timur can test on his PC as well. If it is working for 
him in a VM he just needs to do the diff to his physical system to find the 
root cause. ;-)

Matthias


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

[darktable-dev] Re: RAW presets get applied to JPG, PNG and TIF

[Matthias Bodenbinder]

Am 28.05.2016 um 18:55 schrieb Tobias Ellinghaus:
> Please file a bug report

https://redmine.darktable.org/issues/11039


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

[darktable-dev] Re: RAW presets get applied to JPG, PNG and TIF

[Matthias Bodenbinder]

Am 24.05.2016 um 07:18 schrieb Matthias Bodenbinder:
> I will do more testing the next days.


After a few more tests it is clear that I can not change the basecurve preset 
"test" after it is created. This is true not only for the format value, but 
also for the filter when it should be applied. The preset is writeprotected. 

This bevahour is different from any other module presets, like for the sharpen 
module for example. I can edit those presets just fine. Only basecurve presets 
are affected.

Matthias


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

[darktable-dev] Re: RAW presets get applied to JPG, PNG and TIF

[Matthias Bodenbinder]

Am 23.05.2016 um 15:14 schrieb Tobias Ellinghaus:
> Just to reiterate:
>  - Which of those presets gets applied?
> 
>  - When editing that preset, is any change done to the auto-apply settings 
> remembered? Maybe even try restarting darktable (that shouldn't matter, but 
> who knows what edge cases there are). Note that we are talking about the 
> settings for auto-apply, NOT for the images to show the preset for!
> 
> - What version of darktable is this exactly? Please show the output of
>  darktable --version

I tried to make this behaviour reproducible and plyed a bit with presets. The 
behaviour is strange. 

1) move .config/darktable out of the way to start clean
2) Import a Canon 6D RAW (CR2). 
3) Open in darkroom. Canon basecurve gets applied.
4) Select the "Canon 6D" basecurve. Edit this as a new preset "test" 
automatically applied to: model="%6D%" ; camera maker="%Canon%" ; format = all 
three boxes checked.
6) Create a new sharpen preset "test" with the same autoapply setting:  
model="%6D%" ; camera maker="%Canon%" ; format = all three boxes checked.
7) Always delete history stack before you open the picture in darkroom

Findings:

5) Next time you open the image the format for the basecurve preset is changed 
to only RAW. You can not change that. When you check all three boxes or just 
two boxes, it is coming back with just "RAW" the next time you start DT.
This is NOT true for the sharpen preset. Here you can change the format 
checkboxes any time. 

Somehow the basecurve preset is treated differently. I can not even delete the 
new basecurve preset because DT refers to the original "Canon 6D" basecurve and 
refuses to delete it. The sharpen preset can be deleted just fine.

I will do more testing the next days.

Matthias

PS

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

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



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

[darktable-dev] Re: RAW presets get applied to JPG, PNG and TIF

[Matthias Bodenbinder]

Am 20.05.2016 um 12:10 schrieb Tobias Ellinghaus:
> echo 'select name, format, autoapply from presets where 
> operation="basecurve";' | sqlite3 ~/.config/darktable/library.db

meine Canon 6D|2|1
test|7|0
Reinhards Sony RX100M3|2|1
kubischer Spline|2|0
neutral|2|0
Canon EOS-artig|2|1
Canon EOS-artig, Alternative|2|1
Nikon-artig|2|1
Nikon-artige Alternative|2|1
Sony Alpha-artig|2|1
Pentax-artig|2|1
Ricoh-artig|2|1
Olympus-artig|2|1
Olympus-artige Alternative|2|1
Panasonic-artig|2|1
Leica-artig|2|1
Kodak EasyShare-artig|2|1
Konica Minolta-artig|2|1
Samsung-artig|2|1
Fujifilm-artig|2|1
Nokia-artig|2|1
Nikon D750|2|0
Nikon D5100|2|0
Nikon D7000|2|0
Nikon D7200|2|0
Sony DSC-RX100M2|2|0
Fujifilm X100S|2|0
Fujifilm X100T|2|0
Canon EOS 5D Mark II|2|0
Pentax K-5|2|0
Nikon D90|2|0
Nikon D800|2|0
Canon EOS 6D|7|0


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

[darktable-dev] Re: RAW presets get applied to JPG, PNG and TIF

[Matthias Bodenbinder]

Am 19.05.2016 um 19:30 schrieb Matthias Bodenbinder:
> Am 19.05.2016 um 19:03 schrieb Tobias Ellinghaus:
>> and finally those where format is "7", i.e., every image:
>>
>>>> meine Canon 6D|basecurve|7
>>>> Eizo FS2331|colorout|7
>>>> Fuji X100|colorin|7
>>>> Schärfen aus|sharpen|7
>>>> Sony DSC-RX100M3|lens|7
>>>> Reinhards Sony RX100M3|basecurve|7
>>>> Fuji X100|lens|7
>>>> stark|rawdenoise|7
>> You should go through the list of presets in the preferences and check those.
> 
> 
> Interesting. But how come? I am only using the GUI. No manipulation of the db 
> with sqllite or such. 
> 
> I tested with the basecurve preset "meine Canon 6D". Only "RAW" is checked as 
> Format but still your sql command shows: 
> 
> meine Canon 6D|basecurve|7
> 
> I can make any change to the Format checkboxes including unchecking 
> everything the settings are not change. Next time I start DT only "RAW" is 
> checked and your sql command gives the same result:
> 
> "|basecurve|7
> 
> What is happening here?
> 
> Matthias

I can not change the format value with the GUI. I did edit the "meine Canon 6D" 
preset with sqlitebrowser to value "2". That helped to prevent that the preset 
ist applied to PNG files. But then, when I change the format checkboxes in the 
GUI, example: checking all three boxes "normale Bilder", "RAW" and "HDR", the 
value stays at "2". That looks like a bug to me. 

Matthias


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

[darktable-dev] Re: RAW presets get applied to JPG, PNG and TIF

[Matthias Bodenbinder]

Am 19.05.2016 um 19:03 schrieb Tobias Ellinghaus:
> and finally those where format is "7", i.e., every image:
> 
>> > meine Canon 6D|basecurve|7
>> > Eizo FS2331|colorout|7
>> > Fuji X100|colorin|7
>> > Schärfen aus|sharpen|7
>> > Sony DSC-RX100M3|lens|7
>> > Reinhards Sony RX100M3|basecurve|7
>> > Fuji X100|lens|7
>> > stark|rawdenoise|7
> You should go through the list of presets in the preferences and check those.


Interesting. But how come? I am only using the GUI. No manipulation of the db 
with sqllite or such. 

I tested with the basecurve preset "meine Canon 6D". Only "RAW" is checked as 
Format but still your sql command shows: 

meine Canon 6D|basecurve|7

I can make any change to the Format checkboxes including unchecking everything 
the settings are not change. Next time I start DT only "RAW" is checked and 
your sql command gives the same result:

meine Canon 6D|basecurve|7

What is happening here?

Matthias





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

[darktable-dev] Re: RAW presets get applied to JPG, PNG and TIF

[Matthias Bodenbinder]

Am 18.05.2016 um 21:08 schrieb Tobias Ellinghaus:

>>> Please open src/libs/metadata_view.c in a text editor and make sure that
>>> SHOW_FLAGS is defined as 1 (around line 39). Then recompile/install and
>>> check the image information of the PNG. There should be a line "Flags"
>>> now. What does it say for the PNG?
>>
>> It says: Flags 0..l...ap...
>> The same flags are shown for the TIF.
>>
>> Both, PNG and TIF, have been created by DT.
> 
> That means that darktable doesn't think those are raw files. So it must be 
> something else. Could you upload a sample image exported from darktable that 
> shows the wrong behaviour please?

Here is a small example PNG (800x534) : 
https://www.dropbox.com/s/b7t6pufeym70b3q/IMG_4339-800.png?dl=0

Matthias

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

[darktable-dev] Re: RAW presets get applied to JPG, PNG and TIF

[Matthias Bodenbinder]

Am 18.05.2016 um 11:05 schrieb Tobias Ellinghaus:
> Am Mittwoch, 18. Mai 2016, 08:05:35 schrieb Matthias Bodenbinder:
>> Am 17.05.2016 um 22:44 schrieb Matthias Bodenbinder:
>>> Am 17.05.2016 um 10:36 schrieb Tobias Ellinghaus:
>>>> Am Samstag, 14. Mai 2016, 15:34:41 schrieb Matthias Bodenbinder:
>>>>> Hi,
>>>>>
>>>>> I am struggling with my presets (DT 2.0.4). I have a basecurve preset
>>>>> that
>>>>> is applied to all my RAW (CR2). Unfortunately the same preset is also
>>>>> applied to the exported PNG, JPG and TIF when I import them. How can I
>>>>> prevent that?
>>>>>
>>>>> I found this issue report https://redmine.darktable.org/issues/9540
>>>>> which is describing exactly my problem. It is from 2013 and the last
>>>>> comment is that it is fixed. But I can not find it.
>>>>>
>>>>> My basecurve presets are always applied. The attached screenshot shows
>>>>> the
>>>>> preset dialog. I have only selected "Format: RAW" but that does not
>>>>> help.
>>>>
>>>> It might be that the exported files look like a raw to darktable for some
>>>> reason, maybe because of embedded metadata copied over from the original
>>>> file.
>>>>
>>>> Do you have a way to compile darktable yourself? That would make it
>>>> easier to find out what is happening.
>>>
>>> I do compile myself.
>>>
>>> Matthias
>>
>> What should I test?
> 
> Please open src/libs/metadata_view.c in a text editor and make sure that 
> SHOW_FLAGS is defined as 1 (around line 39). Then recompile/install and check 
> the image information of the PNG. There should be a line "Flags" now. What 
> does it say for the PNG?


It says: Flags 0..l...ap...
The same flags are shown for the TIF.

Both, PNG and TIF, have been created by DT.

Matthias

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

[darktable-dev] Re: sRGB internal color profile

[Matthias Bodenbinder]

Am 08.05.2016 um 15:54 schrieb jmsarat:
> Hi Matthias,
> 
> With a clean $HOME/.config/darktable, the option lcms2 is deactivated by 
> default therefore the export function use lcms1-1.19. The resulting image 
> does not have defect in the blue shade but if the lcms2 option is activated 
> then the problem appears.

I do not see a difference with lcms2 activated or deactivated with either sRGB 
or Adobe RGB.

Matthias


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

[darktable-dev] Re: sRGB internal color profile

[Matthias Bodenbinder]

Hi Jean-Marc,

I can not reproduce your JPG output. Not even with your xmp file. I am using DT 
2.0.4, self compiled.

Have you tried with a different user resp. with a clean  
$HOME/.config/darktable ?

Matthias


Am 08.05.2016 um 12:35 schrieb jmsarat:
> Hi Jo,
> 
> With this clean xmp : https://1fichier.com/?rd1q8touto
> 
> I obtain this image : https://1fichier.com/?3uqu4ijx0g
> 
> No style on export and using the image parameters for color profile 
> (sRGB(web))  and rendering intent (perceptual).
> 
> The raw image is there  : https://1fichier.com/?5n9xbgf9ej
> 
> The problem is visible in the blue shade but could be present in other colors.
> 
> Jean-Marc
> 
> Le 08/05/2016 à 08:26, johannes hanika a écrit :
>> heya,
>>
>> this is what it looks like for me:
>>
>> https://jo.dreggn.org/img_0001.jpg
>>
>> much like your not broken reference image?
>>
>> do you apply any styles on export maybe? if you have an exported jpg i
>> could check the history stack in the xmp stored in that one..
>>
>> cheers,
>>   jo
>>
>>
>>
>> On Sat, May 7, 2016 at 4:42 AM, jmsarat  wrote:
>>> Bonjour Johannes,
>>>
>>> The problem occurs when exporting an image and using the internal sRGB color
>>> profile. The problem disappear if I select another sRGB color profile (Sony
>>> sRGB or RT sRGB).
>>> As the source is a sony arw raw image, I do not specify a particular icc
>>> profile and use the standard matrix. I tried sony dcp profiles for A6000
>>> converted to icc but if the result is different the problem has been moved
>>> to other places in the blue shades.
>>> Attached the xmp corresponding to the image. This is a simplified xmp with
>>> the minimal options that create the problem in blue shades.
>>> The arw file is there : https://1fichier.com/?8khnco34cy
>>>
>>> darktable version 2.1.0+1080~gfedb40
>>>
>>> Jean-marc
>>>
>>>
>>>
>>>
>>> Le 27/04/2016 à 15:06, johannes hanika a écrit :
 heya,

 i can't reproduce. is there anything else? can you share an .xmp
 sidecar file so we can precisely reproduce your steps? and just to
 double check: you are talking export, not display, right? so it can't
 be a display profile issue. are you using any particular icc profile
 as input colour space?

 -jo

 On Wed, Apr 27, 2016 at 2:06 PM, Moritz Moeller 
 wrote:
> On 25/04/16 12:43, jmsarat wrote:
>>
>> [...] lower image
>> result with an external profile (Sony Corp sRGB). [...]
>
>
> Can you share the source of the Sony profile?
>
> I have some images that have always shown exactly the artifacts you
> documented and which I could never develop through DT therefore. I
> thought
> it was some module inside DT causing this. If it is as simple as changing
> the profile, that would be really awesome.
>
> .mm
>
>
>
> ___
> 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
>>
>>
> 
> ___
> 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

[darktable-dev] Re: cannot change/delete whitepoint presets

[Matthias Bodenbinder]

Am 07.03.2016 um 16:38 schrieb Matthias Bodenbinder:
> Hi,
> 
> I just had a weird experience during playing around with DT 2.0.2. I have 
> white balance presets in the darkroom which I can neither select, update or 
> delete anymore.
> 
> Here is what I did:
> prerequisite: I have an existing preset for white balance called "temp". I 
> use this to temporarily save white balance values to copy them to other 
> images.
> 
> - Open image
> - set manual white point
> - select "save as new preset" (not update existing) and save with existing 
> name "temp"
> - this will render the preset unusable. Can not be selected or delete or 
> updated anymore.
> 
> This behaviour is true for 2.0.1 and 2.0.2. 
> 
> Can somebody please look into that?
> And how do I now actually delete this preset?
> 
> 
> Matthias
> 

I could not reproduce that behaviour. I used sqllitebrowser to delete the 
presets from the DB. That work. Everything back to normal now.

I saw in sql that for the temperature presets the op_version is either 2 or 3. 
The broken presets had 3, the new and good once have 2. Does that matter? Other 
than that that broken presets did not look different.

Matthias

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

[darktable-dev] cannot change/delete whitepoint presets

[Matthias Bodenbinder]

Hi,

I just had a weird experience during playing around with DT 2.0.2. I have white 
balance presets in the darkroom which I can neither select, update or delete 
anymore.

Here is what I did:
prerequisite: I have an existing preset for white balance called "temp". I use 
this to temporarily save white balance values to copy them to other images.

- Open image
- set manual white point
- select "save as new preset" (not update existing) and save with existing name 
"temp"
- this will render the preset unusable. Can not be selected or delete or 
updated anymore.

This behaviour is true for 2.0.1 and 2.0.2. 

Can somebody please look into that?
And how do I now actually delete this preset?


Matthias

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

[darktable-dev] Re: TIF: Unknown field with tag 18246 (

[Matthias Bodenbinder]

Am 28.01.2016 um 07:45 schrieb Matthias Bodenbinder:
> I just found that this already was a bug report with DT version 1.2! Status 
> changed from Triaged to Fixed over 1 year ago.
> 
> "exported TIFF missing ImageLength field, incompatible with ImageMagick 
> identify command"
> http://redmine.darktable.org/issues/8473
> 
> Somehow this issue seems to be back. According to this bug report I tested 
> with "convert" and got:
> 
> 1# convert IMG_2542.tif test.png
> convert: Unknown field with tag 18246 (0x4746) encountered. 
> `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 18249 (0x4749) encountered. 
> `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 36867 (0x9003) encountered. 
> `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 34864 (0x8830) encountered. 
> `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 34866 (0x8832) encountered. 
> `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 40965 (0xa005) encountered. 
> `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 42032 (0xa430) encountered. 
> `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 42033 (0xa431) encountered. 
> `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 42034 (0xa432) encountered. 
> `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 42036 (0xa434) encountered. 
> `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 42037 (0xa435) encountered. 
> `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 18246 (0x4746) encountered. 
> `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 18249 (0x4749) encountered. 
> `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/861.
> convert: Unknown field with tag 36867 (0x9003) encountered. 
> `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/861.
> 
> 
> Matthias
> 

Please check this page for field tag explanations:
http://www.digitalpreservation.gov/formats/content/tiff_tags.shtml

Matthias


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

[darktable-dev] TIF: Unknown field with tag 18246 (

[Matthias Bodenbinder]

Hi,

I started to experiment with focus stacking with enfuse, which needs the hugin 
tools for aligning the pictures. Therefore I exported 16 bit TIF from DT. But 
when I use these TIF with align_image_stack from hugin tools or in gimp I am 
getting these warnings:

align_image_stack:
TIFFReadDirectory: Warning, Unknown field with tag 18249 (0x4749) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 36867 (0x9003) encountered.

gimp:
Unknown field with tag 18249 (0x4749) encountered
Unknown field with tag 36867 (0x9003) encountered

But I can still work with the pictures. It doesnt matter if I export TIF 
uncompressed or deflated.

Why is that?

Matthias

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