Re: [darktable-dev] git master crashes at entering darkroom mode

[parafin]

Clean your install directory.


On Tue, 3 Nov 2020 22:36:14 +0300
Alexander Rabtchevich  wrote:

> Hello. Current git master crushes at attempt to enter darkroom mode.
> Mint Mate 20 x64.
> Here is the output.
> 
> (darktable:23644): GdkPixbuf-CRITICAL **: 22:31:36.345:
> gdk_pixbuf_new_from_data: assertion 'data != NULL' failed
> 
> (darktable:23644): GdkPixbuf-CRITICAL **: 22:31:36.346:
> gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
> 
> (darktable:23644): GdkPixbuf-CRITICAL **: 22:31:36.347:
> gdk_pixbuf_new_from_file_at_scale: assertion 'width > 0 || width == -1'
> failed
> [New LWP 23645]
> [New LWP 23647]
> [New LWP 23648]
> [New LWP 23649]
> [New LWP 23650]
> [New LWP 23651]
> [New LWP 23652]
> [New LWP 23653]
> [New LWP 23654]
> [New LWP 23656]
> [New LWP 23658]
> [New LWP 23667]
> [New LWP 23668]
> [New LWP 23669]
> [New LWP 23670]
> [New LWP 23671]
> [New LWP 23704]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 0x7fafd2ddadff in __GI___wait4 (pid=pid@entry=23705,
> stat_loc=stat_loc@entry=0x0, options=options@entry=0,
> usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:27
> 27    ../sysdeps/unix/sysv/linux/wait4.c: Нет такого файла или каталога.
> warning: Currently logging to /tmp/darktable_bt_QJGNT0.txt.  Turn the
> logging off and on to make the new setting effective.
> #0  0x7fafd2ddadff in __GI___wait4 (pid=pid@entry=23705,
> stat_loc=stat_loc@entry=0x0, options=options@entry=0,
> usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:27
> #1  0x7fafd2ddad7b in __GI___waitpid (pid=pid@entry=23705,
> stat_loc=stat_loc@entry=0x0, options=options@entry=0) at waitpid.c:38
> #2  0x7fafd304bfb8 in _dt_sigsegv_handler (param=11) at
> /home/sasha/Install/darktable/src/common/system_signal_handling.c:114
> #3  0x7fafd2d3b210 in  () at
> /lib/x86_64-linux-gnu/libc.so.6
> #4  0x7faf9a88ae5c in fprintf (__fmt=0x7faf9a88d00c "error loading
> file `%s': %s\n", __stream=) at
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:100
> #5  load_image (filename=filename@entry=0x7fff944be7d0
> "/opt/darktable/share/darktable/pixmaps/plugins/darkroom/soften.svg") at
> /home/sasha/Install/darktable/src/libs/modulelist.c:162
> #6  0x7faf9a88b464 in _lib_modulelist_populate_callback
> (instance=, user_data=) at
> /home/sasha/Install/darktable/src/libs/modulelist.c:267
> #7  0x7fafd1d85802 in g_closure_invoke () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #8  0x7fafd1d99814 in  () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #9  0x7fafd1da4b9e in g_signal_emit_valist () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #10 0x7fafd1da50d3 in g_signal_emit () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #11 0x7fafd2606479 in gtk_widget_realize () at
> /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #12 0x7fafd2606758 in gtk_widget_map () at
> /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #13 0x7fafd2535836 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #14 0x7fafd23e0a83 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #15 0x7fafd2536395 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #16 0x7fafd1d85965 in  () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #17 0x7fafd1da4b28 in g_signal_emit_valist () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #18 0x7fafd1da50d3 in g_signal_emit () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #19 0x7fafd260671a in gtk_widget_map () at
> /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #20 0x7fafd23e0a83 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #21 0x7fafd24320c0 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #22 0x7fafd1d85965 in  () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #23 0x7fafd1da4b28 in g_signal_emit_valist () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #24 0x7fafd1da50d3 in g_signal_emit () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #25 0x7fafd260671a in gtk_widget_map () at
> /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #26 0x7fafd24652d4 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #27 0x7fafd23e0a83 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #28 0x7fafd1d85965 in  () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #29 0x7fafd1da4b28 in g_signal_emit_valist () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #30 0x7fafd1da50d3 in g_signal_emit () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #31 0x7fafd260671a in gtk_widget_map () at
> /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #32 0x7fafd2395670 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #33 0x7fafd23e0a83 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #34 0x7fafd1d85a56 in  () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #35 0x7fafd1da4b28 in g_signal_emit_valist () at
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #36 

Re: [darktable-dev] dt build from git crashes on Ubuntu 20

[parafin]

Clean your install dir in this case, not just build.


On Mon, 12 Oct 2020 15:09:41 +0200
Hubert Kowalski  wrote:

> People keep making same mistake
> 
> Clean your build dir before compiling darktable after git update. the error
> is with "modulelist.c" file which was removed in recent module groups
> rework by AlicVB
> 
> pon., 12 paź 2020 o 15:03 Jesus Arocho  napisał(a):
> 
> > I had not used dt for a couple of weeks,  I did an update from git and
> > compiled, no error messages.  Program opened ok and I opened the new photo
> > directory.  Applied stars ok and then limited the selection to 4 stars.
> > When trying to open an image, the program locked up.  I attached an error
> > file created in /tmp.  I installed the recent version from ppa and it works
> > fine.
> >
> > ___
> > darktable developer mailing list to unsubscribe send a mail to
> > darktable-dev+unsubscr...@lists.darktable.org
> >  
> 
> 
> -- 
> Pozdrawiam,
> Hubert Kowalski
> 
> ___
> 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

Re: [darktable-dev] dt & macOS compatitbility

[parafin]

macOS 10.7 is the oldest supported version, as stated here:
https://www.darktable.org/install/#macos
or here:
https://github.com/darktable-org/darktable/blob/master/packaging/macosx/BUILD.txt
Well, when I say supported, I just mean that it should work, I'm not
sure if it actually works on anything but 10.14 and 10.15.

On the other hand dt doesn't work with the latest macOS 11.0 Beta:
https://github.com/darktable-org/darktable/issues/5878


On Mon, 28 Sep 2020 09:53:31 -0400
FF  wrote:

> Hello,
> 
> I was looking for this info., but probably missed it somewhere in the dt 
> release description.
> What is the oldest macOS compatible with the current and the Dec. release of 
> the dt?
> With the new sky high Mac Pro prices, the older Mac Pro machines look very 
> attractive.
> Will EL Capitan (10.11) work with the new dt?
> 
> 
> ___
> 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

Re: [darktable-dev] Catalina build problem

[parafin]

OK, I have missed that you used the correct cmake call in your first
email and I saw that you are missing dependencies that should have been
installed when following the procedure, so I assumed you skipped some
steps. I can see now that one step failed and you haven't noticed, which
I didn't expect to happen (lesson to me). Maybe some advice - if you
don't want to read the whole output, you can at least check the return
code with "echo $?" command (expected output is "0").

For the issues when installing dependencies from macports their bug
tracker is a good place to find help, which I can see you've already
found out for yourself (https://trac.macports.org/ticket/61024).


On Wed, 19 Aug 2020 11:06:42 +0100
Con Cunningham  wrote:

> No need for the sneering "if you actually" attitude. I write software for a
> living, I would never reach out for support unless I had spent a lot of my
> time investigating. In this case, I followed the instructions to the letter
> (Cut and paste). Here are the appropriate lines from my history;
> 
> 1023  sudo port install git exiv2 libgphoto2 gtk-osx-application-gtk3
> lensfun librsvg libsoup openexr json-glib flickcurl GraphicsMagick openjpeg
> lua webp libsecret pugixml osm-gps-map adwaita-icon-theme tango-icon-theme
> intltool iso-codes libomp gmic
> 
> 1024  cmake .. -DCMAKE_OSX_DEPLOYMENT_TARGET=10.7
> -DCMAKE_CXX_FLAGS=-stdlib=libc++
> -DOpenMP_C_INCLUDE_DIR=/opt/local/include/libomp
> -DOpenMP_CXX_INCLUDE_DIR=/opt/local/include/libomp
> -DCMAKE_LIBRARY_PATH=/opt/local/lib/libomp -DBINARY_PACKAGE_BUILD=ON
> -DRAWSPEED_ENABLE_LTO=ON -DBUILD_CURVE_TOOLS=ON -DBUILD_NOISE_TOOLS=ON
> 
> So on my machine, running Catalina 10.15.6, those instructions do not work.
> 
> But thanks for taking the time for your very constructive comments.
> 
> ___
> 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

Re: [darktable-dev] Catalina build problem

[parafin]

If you'd actually followed the BUILD.txt instructions exactly, you
wouldn't have had problems with either OpenMP or current failure. Look
for "Install required dependencies" (the list contains intltool, which
you are missing in your system) and for "Finally build and install
darktable" (there are parameters to cmake that you need to specify).
If you are not too familiar with the build process on macOS, I suggest
first to replicate BUILD.txt steps without changing anything, before
trying to come up with alternative ways.


On Tue, 18 Aug 2020 23:34:18 +0100
Con Cunningham  wrote:

> Spoke to some of the good people on IRC #darktable, and at the suggestion
> of RobbieAB, tried to invoke build.sh --disable-openomp.
> 
> This got me further, I think, and it now fails like this;
> 
> Darktable build script
> 
> Building directory:
>  /Users/concunningham/Documents/Projects/Personal/darktable/build
> Installation prefix: /opt/darktable
> Build type:  RelWithDebInfo
> Build generator: Unix Makefiles
> Build tasks: 10
> 
> 
> -- Is the target platform supported: 1
> -- Found little endian system. Good.
> -- Building SSE2-optimized codepaths: ON
> -- Performing Test C_COMPILER_UNDERSTANDS_-Wno-error=varargs
> -- Performing Test C_COMPILER_UNDERSTANDS_-Wno-error=varargs - Success
> -- Performing Test CXX_COMPILER_UNDERSTANDS_-Wno-error=varargs
> -- Performing Test CXX_COMPILER_UNDERSTANDS_-Wno-error=varargs - Success
> -- Performing Test
> C_COMPILER_UNDERSTANDS_-Wno-error=address-of-packed-member
> -- Performing Test
> C_COMPILER_UNDERSTANDS_-Wno-error=address-of-packed-member - Success
> -- Performing Test
> CXX_COMPILER_UNDERSTANDS_-Wno-error=address-of-packed-member
> -- Performing Test
> CXX_COMPILER_UNDERSTANDS_-Wno-error=address-of-packed-member - Success
> -- Looking for external programs
> -- Found perl
> -- Missing intltool-merge
> -- Missing desktop-file-validate, problems in darktable.desktop might go
> unnoticed
> -- Could NOT find LLVM (missing: LLVM_DIR)
> -- Could NOT find LLVM (missing: LLVM_DIR)
> -- Could NOT find LLVM (missing: LLVM_DIR)
> -- Could NOT find LLVM (missing: LLVM_DIR)
> -- Could NOT find LLVM (missing: LLVM_DIR)
> -- Could NOT find LLVM (missing: LLVM_DIR)
> -- Could NOT find LLVM (missing: LLVM_DIR)
> -- Could NOT find LLVM (missing: LLVM_DIR)
> -- Test-compilation of OpenCL programs is disabled.
> -- Missing jsonschema, problems in noiseprofiles.json might go unnoticed
> -- Found xsltproc
> -- Found xmllint
> -- Missing exiftool
> -- Configuring incomplete, errors occurred!
> 
> ___
> 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

Re: [darktable-dev] 3.0.2 for Mac wont start: file system relative paths not allowed in hardened programs

[parafin]

For the record if someone will encounter this problem - the culprit
turned out to be an antivirus software quarantining libepoxy.0.dylib.


On Sat, 11 Jul 2020 18:38:09 +0200
parafin  wrote:

> Could you please try the following package?
> http://paraf.in/junk/darktable-3.0.2.9.dmg
> 
> 
> On Tue, 7 Jul 2020 06:28:33 -1000
> Ken Ellinwood  wrote:
> 
> > FYI, I've solved my problem by building darktable from the source code.
> > When I launch /usr/local/bin/darktable I don't get the error.
> > 
> > On Thu, Jul 2, 2020 at 10:58 PM Ken Ellinwood  wrote:
> >   
> > > I get similar behavior when trying to run from the dmg...
> > >
> > > Termination Reason:DYLD, [0x1] Library missing
> > >
> > > Application Specific Information:
> > > dyld: launch, loading dependent libraries
> > >
> > > Dyld Error Message:
> > >   Library not loaded: @executable_path/../Resources/lib/libepoxy.0.dylib
> > >   Referenced from:
> > > /Volumes/darktable/darktable.app/Contents/Resources/lib/libgtk-3.0.dylib
> > >   Reason: no suitable image found.  Did find:
> > > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> > > mmap() errno=5 at address=0x10FBB2000, size=0x0008D000 segment=__TEXT in
> > > Segment::map() mapping
> > > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib
> > > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> > > stat() failed with errno=25
> > > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> > > mmap() errno=5 at address=0x10FCEC000, size=0x0008D000 segment=__TEXT in
> > > Segment::map() mapping
> > > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib
> > > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> > > stat() failed with errno=5
> > > file system relative paths not allowed in hardened programs
> > >
> > > On Thu, Jul 2, 2020 at 3:26 AM August Schwerdfeger <
> > > aug...@schwerdfeger.name> wrote:
> > >
> > >> Darktable starts normally from the DMG.
> > >>
> > >> --
> > >> August Schwerdfeger
> > >> aug...@schwerdfeger.name
> > >>
> > >> On Thu, Jul 2, 2020 at 4:05 AM Moritz Moeller 
> > >> wrote:
> > >>
> > >>> I'm running 3.0.2. on 10.15.5 w/o any issues since that DT version was
> > >>> released.
> > >>> Not sure though when I upgraded from 10.15.4. Maybe I had 3.0.2 already
> > >>> installed by then.
> > >>>
> > >>> .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 developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] 3.0.2 for Mac wont start: file system relative paths not allowed in hardened programs

[parafin]

Could you please try the following package?
http://paraf.in/junk/darktable-3.0.2.9.dmg


On Tue, 7 Jul 2020 06:28:33 -1000
Ken Ellinwood  wrote:

> FYI, I've solved my problem by building darktable from the source code.
> When I launch /usr/local/bin/darktable I don't get the error.
> 
> On Thu, Jul 2, 2020 at 10:58 PM Ken Ellinwood  wrote:
> 
> > I get similar behavior when trying to run from the dmg...
> >
> > Termination Reason:DYLD, [0x1] Library missing
> >
> > Application Specific Information:
> > dyld: launch, loading dependent libraries
> >
> > Dyld Error Message:
> >   Library not loaded: @executable_path/../Resources/lib/libepoxy.0.dylib
> >   Referenced from:
> > /Volumes/darktable/darktable.app/Contents/Resources/lib/libgtk-3.0.dylib
> >   Reason: no suitable image found.  Did find:
> > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> > mmap() errno=5 at address=0x10FBB2000, size=0x0008D000 segment=__TEXT in
> > Segment::map() mapping
> > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib
> > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> > stat() failed with errno=25
> > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> > mmap() errno=5 at address=0x10FCEC000, size=0x0008D000 segment=__TEXT in
> > Segment::map() mapping
> > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib
> > /Volumes/darktable/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> > stat() failed with errno=5
> > file system relative paths not allowed in hardened programs
> >
> > On Thu, Jul 2, 2020 at 3:26 AM August Schwerdfeger <  
> > aug...@schwerdfeger.name> wrote:  
> >  
> >> Darktable starts normally from the DMG.
> >>
> >> --
> >> August Schwerdfeger
> >> aug...@schwerdfeger.name
> >>
> >> On Thu, Jul 2, 2020 at 4:05 AM Moritz Moeller 
> >> wrote:
> >>  
> >>> I'm running 3.0.2. on 10.15.5 w/o any issues since that DT version was
> >>> released.
> >>> Not sure though when I upgraded from 10.15.4. Maybe I had 3.0.2 already
> >>> installed by then.
> >>>
> >>> .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

Re: [darktable-dev] 3.0.2 for Mac wont start: file system relative paths not allowed in hardened programs

[parafin]

August, Ken,

what happens if you do a fresh download of 3.0.2 DMG package (so it
gets quarantined), open it and start darktable from there? Do not
delete installed darktable (or copy from DMG) in order not to lose
original behavior. Link to DMG:
https://github.com/darktable-org/darktable/releases/download/release-3.0.2/darktable-3.0.2.dmg


On Wed, 1 Jul 2020 15:06:14 -0500
August Schwerdfeger  wrote:

> I have no problem running Darktable 3.0.2 on macOS 10.15.5.
> 
> --
> August Schwerdfeger
> aug...@schwerdfeger.name
> 
> On Wed, Jul 1, 2020 at 2:39 PM parafin  wrote:
> 
> > That's how app bundles work, so I'm not sure how it can be forbidden.
> > But maybe it wants @rpath, not @executable_path... Is it reproducible by
> > anyone else? I don't have 10.15 macOS here.
> >
> >
> > On Wed, 1 Jul 2020 09:08:35 -1000
> > Ken Ellinwood  wrote:
> >  
> > > $ ls -l
> > >  
> > /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib
> >   
> > > -rwxr-xr-x  1 ken.ellinwood  admin  1269408 Apr 16 09:23
> > >  
> > /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib
> >   
> > >
> > > I don't see a permissions issue.  I think the system is complaining that
> > > relative paths are not allowed for dylib dependencies.
> > >
> > > On Wed, Jul 1, 2020 at 7:26 AM parafin  wrote:
> > >  
> > > > errno=13 is EACCES /* Permission denied */
> > > > Maybe you have broken permissions on some files. What does the
> > > > following command show:
> > > > ls -l
> > > >  
> > /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib
> >   
> > > >
> > > >
> > > > On Wed, 1 Jul 2020 07:11:08 -1000
> > > > Ken Ellinwood  wrote:
> > > >  
> > > > > This is on OSX 10.15.5
> > > > >
> > > > > dyld: Library not loaded:  
> > > > @executable_path/../Resources/lib/libepoxy.0.dylib  
> > > > >   Referenced from:
> > > > > /Applications/darktable.app/Contents/Resources/lib/libgtk-3.0.dylib
> > > > >   Reason: no suitable image found.  Did find:
> > > > >  
> > > >  
> > /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> >  
> > > > > open() failed with errno=13
> > > > >  
> > > >  
> > /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> >  
> > > > > open() failed with errno=13
> > > > >  
> > > >  
> > /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> >  
> > > > > stat() failed with errno=13
> > > > > file system relative paths not allowed in hardened programs
> > > > > Abort trap: 6
> > > > >
> > > > > Any ideas?
> > > > >
> > > > > Ken
> > > > >
> > > > >  
> > > >  
> > ___
> >  
> > > > > 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 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

Re: [darktable-dev] 3.0.2 for Mac wont start: file system relative paths not allowed in hardened programs

[parafin]

That's how app bundles work, so I'm not sure how it can be forbidden.
But maybe it wants @rpath, not @executable_path... Is it reproducible by
anyone else? I don't have 10.15 macOS here.


On Wed, 1 Jul 2020 09:08:35 -1000
Ken Ellinwood  wrote:

> $ ls -l
> /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib
> -rwxr-xr-x  1 ken.ellinwood  admin  1269408 Apr 16 09:23
> /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib
> 
> I don't see a permissions issue.  I think the system is complaining that
> relative paths are not allowed for dylib dependencies.
> 
> On Wed, Jul 1, 2020 at 7:26 AM parafin  wrote:
> 
> > errno=13 is EACCES /* Permission denied */
> > Maybe you have broken permissions on some files. What does the
> > following command show:
> > ls -l
> > /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib
> >
> >
> > On Wed, 1 Jul 2020 07:11:08 -1000
> > Ken Ellinwood  wrote:
> >  
> > > This is on OSX 10.15.5
> > >
> > > dyld: Library not loaded:  
> > @executable_path/../Resources/lib/libepoxy.0.dylib  
> > >   Referenced from:
> > > /Applications/darktable.app/Contents/Resources/lib/libgtk-3.0.dylib
> > >   Reason: no suitable image found.  Did find:
> > >  
> > /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> >   
> > > open() failed with errno=13
> > >  
> > /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> >   
> > > open() failed with errno=13
> > >  
> > /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> >   
> > > stat() failed with errno=13
> > > file system relative paths not allowed in hardened programs
> > > Abort trap: 6
> > >
> > > Any ideas?
> > >
> > > Ken
> > >
> > >  
> > ___ 
> >  
> > > 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

Re: [darktable-dev] 3.0.2 for Mac wont start: file system relative paths not allowed in hardened programs

[parafin]

errno=13 is EACCES /* Permission denied */
Maybe you have broken permissions on some files. What does the
following command show:
ls -l 
/Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib


On Wed, 1 Jul 2020 07:11:08 -1000
Ken Ellinwood  wrote:

> This is on OSX 10.15.5
> 
> dyld: Library not loaded: @executable_path/../Resources/lib/libepoxy.0.dylib
>   Referenced from:
> /Applications/darktable.app/Contents/Resources/lib/libgtk-3.0.dylib
>   Reason: no suitable image found.  Did find:
> /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> open() failed with errno=13
> /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> open() failed with errno=13
> /Applications/darktable.app/Contents/MacOS/../Resources/lib/libepoxy.0.dylib:
> stat() failed with errno=13
> file system relative paths not allowed in hardened programs
> Abort trap: 6
> 
> Any ideas?
> 
> Ken
> 
> ___
> 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

Re: [darktable-dev] Trouble compiling lens.cc with lensfun 0.3.95

[parafin]

You shouldn't use this version anyway:
https://github.com/darktable-org/darktable/issues/2813


On Wed, 1 Apr 2020 10:16:46 -0400
Patrick Shanahan  wrote:

> * Hossam Elgabarty  [04-01-20 10:05]:
> > Dear developers,
> > 
> > Many thanks for the great work!
> > 
> > I am recently having trouble building darktable, the problem starts with 
> > iop/lens.cc when a 
> > call to lfModifier constructur is made:
> > 
> > */home/hossam/.programs/darktable/src/iop/lens.cc:365:60:* *error: *no 
> > matching 
> > function for call to ‘*lfModifier::lfModifier(const float&, int&, int&, 
> > lfPixelFormat, const 
> > int&)*’
> > 
> > My system is OpenSuse tumbleweed, and I do have lensfun 0.3.95. Has anyone 
> > else faced 
> > a similar problem?  
> 
> see:
>   https://build.opensuse.org/package/show/graphics:darktable:master/darktable
>   
> -- 
> (paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
> http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
> Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
> ___
> 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

Re: [darktable-dev] HDR and SDR

[parafin]

HLG gamma curve was designed to be compatible with SDR displays, so you
can just display HDR content with HLG gamma applied on SDR monitor
(which will assume it's BT.709/sRGB gamma) and get a reasonable picture.


On Thu, 26 Dec 2019 01:04:24 +0100
Aurélien Pierre  wrote:

> Hi,
> 
> … and that's where the image processing pipeline mixed with people's
> misunderstandings backfires.
> 
> What's HDR here ? The scene or the display ?
> 
> The image only encodes a scene-referred light emission with 0 and 1.
> That scene-referred light emission has infinite dynamic range, with a
> more limited region of interest for human vision. The encoded recording
> by the camera has not an infinite DR, but still has a dynamic range much
> wider than any display. In this encoding, each bit can only encode 1 EV
> of dynamic range. So, 8 bits => 8 EV, and bit depth => dynamic range.
> Using a tone curve/gamma/OETF only redistributes the bits more evenly
> over that dynamic range.
> 
> The point you make is valid : an SDR file can be an HDR scene backed
> into an SDR image adapted for SDR display. Yet we don't care, an 8-bits
> file has a contrast of 255:1, a 10-bits one has a contrast of 1023:1, no
> matter the scene that it actually encodes. It would appear that any bit
> depth > 8 bits is to be assumed HDR until proved otherwise.
> 
> So the issue seems more general to me than mapping "tonecurve" to
> "dynamic range". The classical imaging pipeline expects 100% RGB (255 in
> 8 bits) to encode 100 Cd/m² (display white point), and (18%
> RGB)^(1/gamma) to encode middle grey. We can say one file is HDR is 100%
> RGB encodes more than 100 Cd/m², in which case the colour management
> needs to apply an highlight roll-off to tonemap the image for SDR
> displays. From what I understand, PQ and HLG tonecurve are just fancy
> maths tricks to optimize the distribution of bits over the dynamic range
> among high bit-depths to reduce posterization. They don't tonemap
> anything in themselves. So these transfer functions can't be assumed to
> be linked to HDR files all the time, they are only encodings (same as
> sRGB gamma, but more refined).
> 
> Say your 16 bits file (contrast of 65535:1) encodes SDR (65535 = 100
> Cd/m²), to display it on a regular monitor (contrast of 255:1), you
> simply need to rescale every pixel linearly (×255 / 65535). If it
> encodes HDR (65535 = 200, 400, 1000… Cd/m²), you will probably rescale
> linearly below middle grey, and roll-off progressively to compress
> highlights in the [117; 255] display-referred space.
> 
> My point here is we need to be absolutely clear about *what* is encoded
> (scene-referred dynamic range), *for what* it is encoded
> (display-referred dynamic range), and *how* it is encoded (OETF + bit
> depth).
> 
> Bit-depth and OETF are stored in ICC metadata of images, but the
> scene-referred dynamic range should be deduced from the white point
> luminance tag if provided (if white > 100 Cd/m² then HDR ; else SDR),
> and I don't know for the display-referred dynamic range (if the file has
> been saved with a tonemapping already or if the colour management needs
> to roll-off highlights on-the-fly before sending to GPU memory buffer).
> 
> Merry Christmas,
> 
> Aurélien.
> 
> Le 18/12/2019 à 07:59, Wiktor Nowak a écrit :
> > Why thinking of bit depth in terms of dynamic range? Dynamic range is a
> > range between the brightest and darkest part of image with no clipping.
> > HDR image could be 16, 10, 8 or whatever bit depth or format with a base
> > curve applied or not i think...
> >
> > W dniu 17.12.2019 o 14:24, Andreas Schneider pisze:  
> >> On Tuesday, 17 December 2019 14:12:48 CET Sturm Flut wrote:  
> >>> Hi Andreas,
> >>>
> >>> On 16.12.19 20:13, Andreas Schneider wrote:  
>  sRGB -> SDR
>  AdobeRGB -> SDR
> 
>  PQ Rec2020 -> HDR
>  HLG Rec2020 -> HDR
> 
>  Does that make sense? I could look into that next.  
> >>> Where do RAW files fit into this definition? They have no color space.
> >>>
> >>> A 16 Bit AdobeRGB out-of-camera TIFF file might have more dynamic range
> >>> than 10 Bit Rec.2020 data. Color space alone might not be a sufficient
> >>> measure.  
> >> If you have a better idea, I'm open to suggestions!
> >>
> >> All TIFF files are currently set to SDR ...
> >>
> >>
> >>Andreas
> >>  
> > ___
> > 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

Re: [darktable-dev] Cannot create darktable DMG — make-app-bundle doesn't work properly

[parafin]

There are issues with fonts on macOS, but it's a GTK bug or/and font
compatibility issue:
https://github.com/darktable-org/darktable/issues/3345
https://github.com/darktable-org/darktable/issues/3500

Nothing I can do. Edit the theme or/and remove extra fonts.


On Mon, 2 Dec 2019 19:09:10 +0100
Sébastien Chaurin  wrote:

> I confirm that it works fine, if you build it correctly using the right 
> options……. Thanks a lot for that.
> 
> However I have some issues with the fonts now. I have roboto installed, and 
> It was working fine with 2.7.0, but now it’s come back in the sense that I 
> see some Japanese symbol in the date and time field of the image information 
> on the left hand side of the screen when in the light table module.
> That’s workable of course, what is less convenient on the other hand is that 
> it crashes immediately if I try to switch themes. Im pretty sure I was 
> running elegant but now I just can’t move from the standard as it crashes 
> instantly. Is there some option I can start it from the terminal so we can 
> see what’s going on ?
> 
> Should I open a new email thread for this ?
> 
> Thanks for helping in any case.
> 
> Ps : I can surely provide screenshot but do not want to bother the whole list 
> with a lot a attachments.
> 
> Cheers
> 
> > On 30 Nov 2019, at 00:29, Sébastien Chaurin  
> > wrote:
> > 
> > And you’re absolutely right, wrong copy paste… I do miss this one as well 
> > as the noise tool. I’ll clean it and rebuild it in the morning but I trust 
> > I should be fine now.
> > 
> > Somehow I knew it was something stupid ;)
> > 
> > Thanks !!
> >   
> >> On 29 Nov 2019, at 22:57, parafin  wrote:
> >> 
> >> Re-check that the options you are passing to cmake matche the ones in
> >> BUILD.txt. Specifically I think you are missing at least
> >> -DBUILD_CURVE_TOOLS=ON
> >> 
> >> make-app-bundle script really needs better error-handling;)
> >> 
> >> 
> >> On Fri, 29 Nov 2019 20:41:20 +0100
> >> Sébastien Chaurin  wrote:
> >>   
> >>> Hi everyone,
> >>> 
> >>> I just upgraded from MacOS 10.14 (Mojave) to 10.15 Catalina. I’ve 
> >>> struggled a bit getting my MacPorts configuration right again, but 
> >>> somehow managed to do it.
> >>> 
> >>> I’ve completely started over all the instructions in the BUILD.TXT file 
> >>> to make sure I was not overlooking something.
> >>> 
> >>> I now have DT installed in /usr/local, and am able to fire it up even 
> >>> with openCL enabled using the provided instructions.
> >>> 
> >>> However when I try to make it a proper dmg file, it fails miserably and 
> >>> I’m not sure why.
> >>> 
> >>> This is what I have in my terminal :
> >>> 
> >>> $ sudo ./make-app-bundle
> >>> Password:
> >>> Reading http://lensfun.sourceforge.net/db/versions.json …
> >>> Reading http://wilson.bronger.org/lensfun-db/versions.json …
> >>> Info: No newer database was found for last installed Lensfun.
> >>> Cannot find source to copy: 
> >>> /usr/local/libexec/darktable/tools/darktable-curve-tool
> >>> mv: rename package/darktable.app/Contents/MacOS/darktable-bin to 
> >>> package/darktable.app/Contents/MacOS/darktable: No such file or directory
> >>> mv: rename 
> >>> package/darktable.app/Contents/Resources/lib/gdk-pixbuf-2.0/*/loaders.cache
> >>>  to package/darktable.app/Contents/Resources/etc/gtk-3.0/: No such file 
> >>> or directory
> >>> sed: package/darktable.app/Contents/Resources/etc/gtk-3.0/gtk.immodules: 
> >>> No such file or directory
> >>> Error opening directory 
> >>> “package/darktable.app/Contents/Resources/share/glib-2.0/schemas/”: No 
> >>> such file or directory
> >>> sed: package/darktable.app/Contents/Info.plist: No such file or directory
> >>> sed: package/darktable.app/Contents/Info.plist: No such file or directory
> >>> error: install_name_tool: can't open file: 
> >>> package/darktable.app/Contents/MacOS/darktable (No such file or directory)
> >>> error: install_name_tool: can't open file: 
> >>> package/darktable.app/Contents/MacOS/darktable-chart (No such file or 
> >>> directory)
> >>> error: install_name_tool: can't open file: 
> >>> package/darktable.app/Contents/MacOS/darktable-cli (No such file or 
> >>> directory)
> >>> error: install_name_tool

Re: [darktable-dev] Cannot create darktable DMG — make-app-bundle doesn't work properly

[parafin]

Re-check that the options you are passing to cmake matche the ones in
BUILD.txt. Specifically I think you are missing at least
-DBUILD_CURVE_TOOLS=ON

make-app-bundle script really needs better error-handling;)


On Fri, 29 Nov 2019 20:41:20 +0100
Sébastien Chaurin  wrote:

> Hi everyone,
> 
> I just upgraded from MacOS 10.14 (Mojave) to 10.15 Catalina. I’ve struggled a 
> bit getting my MacPorts configuration right again, but somehow managed to do 
> it.
> 
> I’ve completely started over all the instructions in the BUILD.TXT file to 
> make sure I was not overlooking something.
> 
> I now have DT installed in /usr/local, and am able to fire it up even with 
> openCL enabled using the provided instructions.
> 
> However when I try to make it a proper dmg file, it fails miserably and I’m 
> not sure why.
> 
> This is what I have in my terminal :
> 
> $ sudo ./make-app-bundle
> Password:
> Reading http://lensfun.sourceforge.net/db/versions.json …
> Reading http://wilson.bronger.org/lensfun-db/versions.json …
> Info: No newer database was found for last installed Lensfun.
> Cannot find source to copy: 
> /usr/local/libexec/darktable/tools/darktable-curve-tool
> mv: rename package/darktable.app/Contents/MacOS/darktable-bin to 
> package/darktable.app/Contents/MacOS/darktable: No such file or directory
> mv: rename 
> package/darktable.app/Contents/Resources/lib/gdk-pixbuf-2.0/*/loaders.cache 
> to package/darktable.app/Contents/Resources/etc/gtk-3.0/: No such file or 
> directory
> sed: package/darktable.app/Contents/Resources/etc/gtk-3.0/gtk.immodules: No 
> such file or directory
> Error opening directory 
> “package/darktable.app/Contents/Resources/share/glib-2.0/schemas/”: No such 
> file or directory
> sed: package/darktable.app/Contents/Info.plist: No such file or directory
> sed: package/darktable.app/Contents/Info.plist: No such file or directory
> error: install_name_tool: can't open file: 
> package/darktable.app/Contents/MacOS/darktable (No such file or directory)
> error: install_name_tool: can't open file: 
> package/darktable.app/Contents/MacOS/darktable-chart (No such file or 
> directory)
> error: install_name_tool: can't open file: 
> package/darktable.app/Contents/MacOS/darktable-cli (No such file or directory)
> error: install_name_tool: can't open file: 
> package/darktable.app/Contents/MacOS/darktable-cltest (No such file or 
> directory)
> error: install_name_tool: can't open file: 
> package/darktable.app/Contents/MacOS/darktable-generate-cache (No such file 
> or directory)
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/ca.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/cs.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/da.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/de.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/en.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/es.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/eu.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/fa.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/fi.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/fr.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/he.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/hu.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/it.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/ja.lproj: No such file or 
> directory
> mkdir: package/darktable.app/Contents/Resources: No such file or directory
> cp: package/darktable.app/Contents/Resources/ko.lproj: No such file or 
> directory
> mkdir: 

Re: [darktable-dev] basic adjustments

[parafin]

Well, that’s the problem with basic adjustment module - IMHO it shouldn’t 
exist, because it duplicates functionality of other modules, while adding 
problems like the one discussed here.


> On 18 Nov 2019, at 16:13, Moritz Moeller  wrote:
> 
> On 15.11.19 12:02, parafin wrote:
>> I think these numbers don't have units, so why do expect them to mean
>> the same thing in different modules, even if we ignore the pipe order?
> 
> Because that's the most basic requirement of usability. That things named the 
> same way act the same way and mean the same thing across a single app – at 
> the very least.
> 
>> It's not promised anywhere in the documentation as far as I can see.
> 
> 
> I went through the Photoshop & Lightroom docs and I can't find any promise in 
> the entirety of them that slider ranges of things sharing a name will match 
> in range & effect.
> Yet they do.
> Go figure ...
> 
> 
> Beers,
> 
> .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

Re: [darktable-dev] darktable 3.0.0rc0 released

[parafin]

The reason macOS users complain is because it is standard on macOS to
not scale anything to screen's DPI. DPI is assumed constant (either 72,
or 96, I'm not sure). When I originally ported darktable to macOS I
introduced a code that detects actual monitor DPI and applies it, which
results in darktable looking differently from all other applications.
It might have been a wrong choice, and it can be easily reverted. But
on macOS systems where I checked darktable it looked fine to me, not
oversized. And IMHO scaling UI so that physical size of the font
doesn't depend on connected monitor (like it's done in Linux) makes more
sense than macOS approach.
Anyway, to better understand the problem the following information is
required: monitor resolution and physical dimensions, DPI that
darktable auto-detects (printed when run with "-d control" command line
option).


On Tue, 5 Nov 2019 21:45:55 +0100
Nicolas Auffray  wrote:

> em size and how it works is not related to GTK but a standard usage on 
> screen rendering. So all apps, system should use this standard thing. 
> It's noted for example on CSS standard W3C page : 
> https://www.w3.org/Style/Examples/007/units.en.html
> 
> Anyway, it seems as Aurelien precise it, that some systems/configuration 
> applied a default dpi not too standard that change that. So quite 
> difficult to find that if any people who develop darktable have these 
> specific systems. So, in other dpi standard screen (if I remember well, 
> default dpi is 72dpi), the 1em=1.333px is no more avalaible, making the 
> font size acting differently...
> 
> 
> Le 05/11/2019 à 20:54, Timur Irikovich Davletshin a écrit :
> > On Tue, 2019-11-05 at 20:47 +0100, Aurélien Pierre wrote:  
> >> Setting font size to 1em should tell GTK to use the default OS font
> >> size, no matter its value.  
> > Size doesn't match default OS settings (Debian 10 default installation)
> > on 3 displays I tried (2 low-dpi, 1 high-dpi). Do you have link on GTK
> > documentation which says that 1em equals default size? I'd be glad to
> > know logic behind it.
> >
> > Thank you in advance,
> >
> > Timur.
> >
> > ___
> > 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

Re: [darktable-dev] darktable crashes when opening styles list

[parafin]

Can't reproduce. Which darktable version are you talking about? Please
try starting darktable with empty config (move away ~/.config/darktable
for the test). Also it's better to report issues on github, not in
mailing list or/and pixl.us forum.


On Mon, 4 Nov 2019 20:56:06 +0200
Henkka  wrote:

> Darktable crashes when opening.. or trying to open styles list (at 
> darkroom). It does so at this latest macos version and it did the same 
> thing in previous macos version. Using mojave.
> 
> ___
> 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

Re: [darktable-dev] Drag-and-drop to change module order

[parafin]

People are confused even with history (left panel) and iop list (right
panel) being in different order, and you are proposing to introduce
third ordering of modules. I'm strongly against complicating things
like that. Favorites tab doesn't look any different from any other tab
on the right panel, so why would it behave differently? What makes
sense is to forbid iop re-order if any group is selected, so allow it
only when all iops are displayed.


On Fri, 1 Nov 2019 09:13:01 -0400
Julian Rickards  wrote:

> I agree with David, re-ordering the modules in the Favourites tab should
> *not* affect the pixel-pipe order but I wonder if David and Pascal are
> thinking differently. As I understand it, Aurlien was re-ordering the
> modules in the "Pixel-pipe" tab, which of course affected the pp order.
> However, some of us have been talking about asking that the modules in the
> Favourites tab be able to be re-ordered and this should be designed so as
> to not affect the pp order, in the same way that the order in which you
> apply the modules (i.e., History) does not affect the pp order.
> 
> On Fri, Nov 1, 2019 at 7:56 AM Pascal Obry  wrote:
> 
> > David,
> >  
> > > Shurely  changing the order of the modules located in the
> > > 'favorites' tab does not change the individual modules position in
> > > the pixel-pipeline?  that would be unthinkable!  
> >
> > Of course it does! Re-ordering the iop is not for fun, it really does
> > change the pixel-pipe order.
> >
> > --
> >   Pascal Obry /  Magny Les Hameaux (78)
> >
> >   The best way to travel is by means of imagination
> >
> >   http://www.obry.net
> >
> >   gpg --keyserver keys.gnupg.net --recv-key F949BD3B
> >
> > ___
> > 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

Re: [darktable-dev] New 2.6.x release

[parafin]

OK, I found that backport:
http://distfiles.gentoo.org/distfiles/darktable-2.6.2-gcc9.patch.tar.xz

Not sure where it came from or the quality.


On Sat, 19 Oct 2019 15:30:46 +0300
Roman Lebedev  wrote:

> On Fri, Oct 18, 2019 at 9:28 AM Roman Lebedev  wrote:
> >
> > On Fri, Oct 18, 2019 at 9:06 AM Pascal Obry  wrote:  
> > >
> > > Hello Parafin,
> > >  
> > > > I would vote for doing a 2.6.3 in order to release a fix for this macOS
> > > > bug:
> > > > https://github.com/darktable-org/darktable/issues/3107
> > > > and I will try to fix another one this week too:
> > > > https://github.com/darktable-org/darktable/issues/1977
> > > >
> > > > Not sure what else we might want to add.  
> > >
> > > A new release why not. It is quite some work and we are two months away
> > > from next release.  
> >  
> > > I suppose that we may want also to check with Roman if we can upgrade
> > > rawspeed at the same time to get support for new camera. Roman, what's
> > > your take on this?  
> > I'll try to take a look this weekend.  
> Maybe done.
> 
> Re OpenMP - that branch builds just fine with clang.
> I would suggest to just start sunsetting some projects.
> 
> > > Thanks,
> > >
> > > --
> > >   Pascal Obry /  Magny Les Hameaux (78)  
> > Roman  
> Roman
> 
> > >   The best way to travel is by means of imagination
> > >
> > >   http://www.obry.net
> > >
> > >   gpg --keyserver keys.gnupg.net --recv-key F949BD3B
> > >  
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] New 2.6.x release

[parafin]

Haven't some distribution rebased that patchset on 2.6 already?


On Fri, 18 Oct 2019 17:31:48 +0200
Pascal Obry  wrote:

> Le vendredi 18 octobre 2019 à 09:44 +0200, Germano Massullo a écrit :
> > Il ven 18 ott 2019, 08:28 Pascal Obry  ha scritto:  
> > > Le vendredi 18 octobre 2019 à 08:16 +0200, Germano Massullo a écrit :  
> > > > Will you include also the patch for OpenMP on GCC 9?  
> > > 
> > > Which one? There has been many changes/patches on this side. I doubt
> > > that it will be possible to merge those anyway.  
> > 
> > #2550  
> 
> There is conflict when rebased on top of darktable-2.6.x. So to have
> this in the darktable-2.6.x branch the author will have to rebase and
> resolved conflicts. This PR contains 98 commits :)
> 
> -- 
>   Pascal Obry /  Magny Les Hameaux (78)
> 
>   The best way to travel is by means of imagination
> 
>   http://www.obry.net
> 
>   gpg --keyserver keys.gnupg.net --recv-key F949BD3B
> 
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] New 2.6.x release

[parafin]

I would vote for doing a 2.6.3 in order to release a fix for this macOS
bug:
https://github.com/darktable-org/darktable/issues/3107
and I will try to fix another one this week too:
https://github.com/darktable-org/darktable/issues/1977

Not sure what else we might want to add.


On Mon, 14 Oct 2019 09:30:44 +0200
Andreas Schneider  wrote:

> Hi,
> 
> I see that in the 2.6.x trees are some fixes and support for e.g. the Sony 
> A6400 camera. People are looking for support for this camera.
> 
> 
> Pascal, could you release 2.6.3 with what we have? Maybe add Sony A7R3M4 
> support too. Roman just added it to rawspeed and darktable.
> 
> 
> Cheers,
> 
>   Andreas
> 
> 
> -- 
> Andreas Schneider a...@cryptomilk.org
> GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
> 
> 
> ___
> 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

Re: [darktable-dev] Vibrance slider in the Basic adjustments tool

[parafin]

Is it any different from velvia iop in darktable?


On Thu, 10 Oct 2019 20:44:25 +0200
Keresztes Barna  wrote:

> Hi all,
> 
> I'm a happy user of Darktable! One of my favorite tools in the 2.7 branch
> is the *Basic Adjustments tool*, where I can find in one place most of the
> tools I need to make quick adjustments for my image.
> 
> I would like to add a *vibrance* *slider* to this tool. It affects the
> saturation of the more saturated pixels. It can be used to accentuate the
> colors without becoming unnatural (as it's often the case of the saturation
> tool). It also has negative values, so you can use it to make your colors
> fade.
> Used together with the saturation slider, you can also work on less
> saturated areas of the image. Otherwise it doesn't change a lot the
> inderface and it fits well in the Basic Adjustments tool.
> 
> It is similar (and similarly positioned) as the vibrance tools in Lightroom
> and Aftershot Pro (ASP) and probably other similar software. Note that it
> uses a different algorithm than ASP, it's also different from the Vibrance
> tool of DT.
> 
> What do you think about the idea?
> 
> Before pushing it to the main branch, I would like to ask you to test it!
> You can find my modifications in my fork on Github:
> https://github.com/kbarni/darktable
> 
> What do you think? Do you like the results?
> 
> The OpenCL part is untested (don’t have the hardware), so it needs to be
> checked too.
> 
> P.S. This is my first contribution to DarkTable; however I developed
> several plugins for Bibble/Aftershot Pro, some of which become part of the
> core tools.
> 
> ___
> 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

Re: [darktable-dev] Re: Feature freeze for 3.0

[parafin]

On Tue, 01 Oct 2019 23:49:03 +0200
Pascal Obry  wrote:

> Dear developers !
> 
> As announced back in August, we are now entering feature freeze. That
> is, at this point only bugs will be considered to be merged into
> master.

Let's hope it's the opposite - bugs got merged before this point, and
now fixes will be introduced;)

> I have one exception discussed with Aurélien which is working on the
> OpenCL version of Filmic RGB.
> 
> Pending bugs worked on are:
> 
> - fix implementation of iop-order to avoid possible clashes
> 
> - fix metadata export to save status between session
> 
> Of course bugs are malicious and we'll discover some others. So do not
> hesitate to test the current code base and report issues.
> 
> As a reminder, the next steps are:
> 
> - *strings* freeze end of October
> 
> - *RC0* end of October
> 
> - *RC1* end of November 
> 
> - Final version in December
> 
> Thanks again for the hard jobs done by all developers to make this
> release a reality... And I can say a very nice reality.
> 
> -- 
>   Pascal Obry /  Magny Les Hameaux (78)
> 
>   The best way to travel is by means of imagination
> 
>   http://www.obry.net
> 
>   gpg --keyserver keys.gnupg.net --recv-key F949BD3B
> 
> ___
> 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

Re: [darktable-dev] jsonschema version issues

[parafin]

It has nothing to do with darktable, you should probably just
delete /usr/local/bin/jsonschema file (where did it come from?). It
references 3.0.1 version, and it's not part of darktable.


On Thu, 05 Sep 2019 21:03:12 +1000
"Terry Duell"  wrote:

> On Thu, 05 Sep 2019 17:54:02 +1000, parafin  wrote:
> 
> > Please provide the error message you're seeing. I can't find any
> > mentions of specific jsonscheme version in darktable sources.
> >  
> 
> OK, here is the rpmbuild error message generated when jsonschema-3.0.2 is  
> installed.
> 
> pkg_resources.VersionConflict: (jsonschema 3.0.2  
> (/usr/lib/python3.7/site-packages), Requirement.parse('jsonschema==3.0.1'))
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>File "/usr/local/bin/jsonschema", line 5, in 
>  from pkg_resources import load_entry_point
>File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line  
> 3191, in 
>  @_call_aside
>File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line  
> 3175, in _call_aside
>  f(*args, **kwargs)
>File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line  
> 3204, in _initialize_master_working_set
>  working_set = WorkingSet._build_master()
>File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line  
> 585, in _build_master
>  return cls._build_from_requirements(__requires__)
>File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line  
> 598, in _build_from_requirements
>  dists = ws.resolve(reqs, Environment())
>File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line  
> 786, in resolve
>  raise DistributionNotFound(req, requirers)
> pkg_resources.DistributionNotFound: The 'jsonschema==3.0.1' distribution  
> was not found and is required by the application
> make[2]: ***  
> [data/CMakeFiles/validate_noiseprofiles_json.dir/build.make:62:  
> data/CMakeFiles/validate_noiseprofiles_json] Error 1
> make[2]: Leaving directory  
> '/home/terry/rpmbuild/BUILD/darktable-2.7.0/build'
> make[1]: *** [CMakeFiles/Makefile2:8258:  
> data/CMakeFiles/validate_noiseprofiles_json.dir/all] Error 2
> make[1]: Leaving directory  
> '/home/terry/rpmbuild/BUILD/darktable-2.7.0/build'
> make: *** [Makefile:155: all] Error 2
> 
> Hope that helps.
> 
> Cheers,
> -- 
> Regards,
> Terry Duell
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Changes to minimum GTK 3 version required?

[parafin]

https://packages.ubuntu.com/search?keywords=libgtk

xenial (16.04LTS) (libs): GTK+ graphical user interface library 
3.18.9-1ubuntu3: amd64 arm64 armhf i386 powerpc ppc64el s390x

bionic (18.04LTS) (libs): GTK+ graphical user interface library 
3.22.30-1ubuntu1: amd64 arm64 armhf i386 ppc64el s390x


On Mon, 15 Jul 2019 15:19:39 +0100
Richard Hobday  wrote:

> With Ubuntu 18.04/Linux Mint 19.1, I no longer seem to be able to
> compile from the current GIT.
> 
> > -- Checking for module 'gtk+-3.0' > --   Found gtk+-3.0, version 3.18.9
> > CMake Error at 
> > /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 
> > (message):
> >   Could NOT find GTK3 (missing: VERSION_OK) (Required is at least version
> >   "3.22")
> > Call Stack (most recent call first):
> >   /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 
> > (_FPHSA_FAILURE_MESSAGE)
> >   cmake/modules/FindGTK3.cmake:58 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
> >   src/CMakeLists.txt:263 (find_package)  
> 
> 3.18.9 is the latest version available with Ubuntu 18.04 as far as I can
> see.
> 
> 
> Anyone have any ideas?
> ___
> 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

Re: [darktable-dev] implementation question: remove all unused modules

[parafin]

> On 12 Jun 2019, at 20:21, Aurélien Pierre  wrote:
> 
> Hi,
> 
> I'm the author of the lighttable's compress history button. White balance and 
> highlight reconstruction should never be turned off, so what would be 
> the purpose of having them disabled in the first place ?
> 

Yet they can be disabled, some other modules can’t.

> Then, we can discuss what the history compression should do/avoid/prevent. 
> 

History compression shouldn’t modify the image.

> Aurélien.
> 
>> Le 12/06/2019 à 11:40, dt-l...@stefan-klinger.de a écrit :
>> thokster (2019-Jun-11, excerpt):
>>> Hi,
>>> 
>>> Am 11.06.19 um 15:32 schrieb dt-l...@stefan-klinger.de:
>>> 
 This option is not about saving disk space, but rather about cleaning
 up.
>>> Is the "compress history" button in lighttable view doing anything else?
>> Woha.  I have been talking about "compress history" in darkroom, not
>> lighttable.
>> 
>> They seem not to use the same code internally.
>> 
>> I have to admit that I have not thought about the "compress history"
>> button in lighttable.  That one already seems to remove switched-off
>> modules in current master [1].  And it seems to do this incorrectly
>> wrt. parafin's email:
>> 
>> * In darkroom, disable "white balance" and/or "highlight
>>   reconstruction".
>> 
>> * Go to lighttable, select that image, and apply "history stack →
>>   compress history"
>> 
>> * When you open the image again, "white balance" and "highlight
>>   reconstruction" will be enabled again.
>> 
>> So if compressing should not change the image, then my current
>> implementation [2] is even more correct, although it only is
>> applicable from darkroom, not lighttable.
>> 
>> Cheers
>> Stefan
>> 
>> 
>> [1] 2.7.0+1443~g9bfbb225e
>> [2] 
>> https://github.com/darktable-org/darktable/compare/master...s5k6:compressHistory
>> 
>> 
>> --
>> http://stefan-klinger.deo/X
>> I prefer receiving plain text messages, not exceeding 32kB. /\/
>>   \
>> ___
>> 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

Re: [darktable-dev] implementation question: remove all unused modules

[parafin]

I think we still have default-on modules not recorded in history stack 
(highlight reconstruction and white balance), so removing all “off” steps might 
modify the image. Therefore I’m afraid your implementation is incorrect. Best 
approach would be to record all applied iops to history, but it’s a little 
tricky due to backwards compatibility (though I think we did similar change 
before) - then your commit will work. Another approach is to add exceptions for 
specific iops, but that’s ugly IMHO.


> On 10 Jun 2019, at 15:05, dt-l...@stefan-klinger.de wrote:
> 
> Hi,
> 
> I've drafted [1] an implementation to make "compress history stack" to
> also remove all unused modules, i.e., the ones switched off.  But
> there are some questions:
> 
>  1. This was so easy to do, maybe it's a bad idea to do this at all?
> 
>  2. I have derived the SQL from looking at other statements in the
> source.  I have no deep knowledge about DT's architecture, so
> someone needs to verify that the query does not mess with other
> stuff.
> 
>  3. I think deleting unused modules should be optional.  How should I
> implement that?
> 
>   * There could be a checkbox "remove unused moduls" next to the
> "compress history stack" button.  I think this is the most
> simple option.
> 
>   * Maybe "remove unused moduls" and "compress history stack"
> should be entirely separate operations?  I'm not sure about
> the exact semantics though: What, precisely, should the
> former do without the latter?  Maybe delete all mentions of a
> module below and up to the one where it's switched off?
> 
>   * Maybe the (currently unused) "presets" menu of darktable's
> "history" module should be used to host these operations?
> 
> Cheers,
> Stefan
> 
> 
> [1] 
> https://github.com/darktable-org/darktable/compare/master...s5k6:compressHistory
> 
> 
> 
> --
> http://stefan-klinger.deo/X
> I prefer receiving plain text messages, not exceeding 32kB. /\/
>  \
> ___
> 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

Re: [darktable-dev] dt master branch → Debian Next deps

[parafin]

Basically it was decided that depending on just fonts-roboto is the
right thing to do. In oldstable Debian it's the only package that exists
and it contains the actual fonts, in other Debians it's a meta-package
that depends on actual package (-hinted in stable, -unhinted in
newer). Looks like that in testing and unstable -hinted package is
dummy and doesn't contain anything. So your original request to depend
on all variants makes sense only for stable, but you mention Debian
Next, which I assume is testing. I'm not sure what's this whole mess
with -hinted and -unhinted is all about, but anyway it doesn't look
like packagers should care about it, fonts-roboto is the right thing to
depend on.

As for requires vs recommends dependency there was a disagreement.
pmjdebruijn chose "recommends" for his Ubuntu packages, darix on the
other hand thinks that "requires" is the right thing to do. I don't
think we managed to convince him otherwise, it's his decision in the
end after all.


On Sun, 26 May 2019 13:02:34 +0300
Timur Irikovich Davletshin  wrote:

> On Sun, 2019-05-19 at 19:50 +0200, parafin wrote:
> > 
> > I have forwarded this thread to darix on IRC, so consider him
> > informed.
> >   
> 
> Hi parafin!
> 
> Any update from darix?
> 
> Timur.
> 
> ___
> 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

Re: [darktable-dev] DT bad on skin tones?

[parafin]

While I really like the idea behind filmic module, still it's not
always easy to get the colors I want with it. I guess, depending on the
camera, base curve might give better colors by default, but will make
much trouble in other departments. Obvious point that it's not that
easy as just using filmic is the fact that it has "preserve the
chrominance" toggle, so it's not very clear what "real" colors really
should look like.


On Tue, 28 May 2019 11:01:42 +0200
Aurélien Pierre  wrote:

> Sure, there are people who want to fight the theory of signal processing
> to complain about the consequences, and people who do the right thing at
> the right time in the pixelpipe. Surprisingly, the latter get better
> results faster.
> 
> Filmic is simple to use if you understand what exposure means in the
> scene-referred space and in the display-referred space. It just remaps
> scene-referred exposure (in ]0 ; + inf[) to display-referred one (in
> [0.0 ; 1.0]), by letting users control what is considered white, black
> and grey in the picture, and to what values they should be mapped on the
> display. But it does so at the end of the pipe, leaving your pixelpipe
> linear before, to preserve the consistency of every physically-bounded
> filter :
> 
>   * blur == optical diffusion -> needs linearity,
>   * denoising == gradient smoothing -> needs linearity,
>   * color profile == linear algebra -> needs linearity,
>   * etc.
> 
> Base curves do exactly the same (look at the shape of the curves… S
> curves with raised mid-tones), but too early in the pipe, and with
> pre-baked curves done by reverse-engineering raw->JPEG conversion from
> cameras manufacturers. Thus, you cross the non-linearity wall too early
> in the pipe, and get a one-size-fits-all look. No matter how you put it,
> call it different retouching approaches or masochism, it's wrong. I
> don't care about opinions or styles, this is signal processing, not
> democracy.
> 
> Why ? Because photons live on a linear scale of energy, and good-looking
> filters do nothing but simulate numerically on RGB channels what
> would/should have happened on photons in real life. So, blurring,
> sharpening, masking and denoising need scene-linear RGB code values.
> Whereas every tone/base-curve (including filmic) is raising the
> mid-tones and adding more contrast (S curve) to reproduce our
> logarithmic scale of *perceived* energy. You go from scene-linear to
> perceptual space with a logarithm, so you rescale the gradients of
> energy (EVs are a log scale, perceptually uniform).
> 
> Once you have crossed that wall of non-linearity, you can kiss your
> color accuracy good-bye if you try to apply physically-bounded filters
> in a perceptual space. That's exactly what people see with the "wrong
> profiles" inconsistencies in this thread. The profiles are not faulty
> here, proof is made by using dcraw with the same matrices. But the input
> profiles are applied *after* the base curve in the pipe, which was a
> design mistake in the first place because you are applying a matrice
> profile expecting scene-linear input on perceptually-encoded data.
> 
> As of now, I will stop answering messages from people complaining about
> color artifacts while using base curves. They are asking for trouble,
> they get it. I have offered an alternative, if people don't want to
> listen, it's not my problem.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] dt master branch → Debian Next deps

[parafin]

On Sun, 19 May 2019 13:42:11 -0400
Patrick Shanahan  wrote:

> * Patrick Shanahan  [05-19-19 13:36]:
> > * Timur Irikovich Davletshin  [05-19-19 13:01]: 
> >  
> > > On Sun, 2019-05-19 at 12:43 -0400, Patrick Shanahan wrote:  
> > > > 
> > > > probably being built by both in different places.  darix's builds are
> > > > utilizing OBS (openSUSE Build System) iianm, and Bernd's something
> > > > else.
> > > >   
> > > 
> > > Thanks! Do you know, what is the best way to reach him? Does he read
> > > darktable-dev?  
> > 
> > if you mean darix, he is usually on irc, 
> > freenode #pixls.us and/or #darktable  
> 
> 
> fwiw:   most of the discussion re: darktable
>   was conducted on freenode irc, #darktable
>   but present contributors seem to dislike that and do
> not go there.  discussion has become disjointed and
> difficult to follow.  but I am a user and bug contributor
> will little/no programming.  this is what I see.
>   there has been discussion about the preferred forum but
> no agreement or resolution that I have seen.

I have forwarded this thread to darix on IRC, so consider him informed.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] dt master branch → Debian Next deps

[parafin]

On Sun, 19 May 2019 15:12:43 +0200
Pascal Obry  wrote:

> Le dimanche 19 mai 2019 à 14:40 +0200, parafin a écrit :
> > On Sun, 19 May 2019 13:34:54 +0200
> > Pascal Obry  wrote:
> >   
> > > And let me add that there is no Roboto issue at all.
> > > 
> > > 1. the default theme does not use it
> > > 
> > > 2. the elegant theme use it as first proposal but there is many other
> > > fallbacks. If none found the system font will be picked.
> > > 
> > > 3. fact is that Gtk has a but and select either Roboto if found and if
> > > not the system font. The fallback are not propoerly checked. This bug
> > > has been fixed and will be in next minor release IIRC.  
> > 
> > What bug? I don't quite get this point  
> 
> On elegant we have:
> 
> font-family: "Roboto Light", "Segoe UI Light",
>  "SF Pro Display Light", "Ubuntu Light",
>  "Cantarell", sans-serif;
> 
> And current Gtk look for Roboto and if not found just default to system
> font. The fallback are not looked at all.

OK, I see.

> 
> That's why we have all those report. That's why we have elegant whereas
> the default theme should have never been created if there was no bug.

I don't think that's the reason why default theme was created, but it
doesn't matter for this discussion.

> 
> > And you still haven't answered how custom user themes would work. Or is
> > there no plan to support custom themes and we will only allow themes
> > included with dt itself? That seems to unnecessary limit usefulness of
> > the whole theming refactoring IMHO.  
> 
> Of course we can support other themes. People will certainly provide
> some new CSS for dt and some font packages could be required to be
> installed. If you don't (can't) install it, just use the standard
> theme. If you want to use a new theme install whatever the developer
> will ask for best experience.
> 
> I'm sorry but I don' see any issues here.
> 
> We are not talking about dt being unusable, the default theme is safe
> and should work for everyone.
> 
> Maybe I'm missing something?

I see a couple of questions that I would like an answer to:

1). How do we define what is dt theme? Is it just CSS file? Or can it
include a font? I guess the answer is "only CSS".

2). How should packagers consider a Roboto font? Is it a required
dependency or optional (e.g. suggested in Debian or USE-flag in
Gentoo)? Should it be included in macOS and Windows packages or can we
just say in release notes that user has to install Roboto font himself
if he wants to? Keep in mind that I don't think that just because
elegant theme isn't the default option this question doesn't matter - if
some feature is included, it should work.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] dt master branch → Debian Next deps

[parafin]

On Sun, 19 May 2019 13:34:54 +0200
Pascal Obry  wrote:

> And let me add that there is no Roboto issue at all.
> 
> 1. the default theme does not use it
> 
> 2. the elegant theme use it as first proposal but there is many other
> fallbacks. If none found the system font will be picked.
> 
> 3. fact is that Gtk has a but and select either Roboto if found and if
> not the system font. The fallback are not propoerly checked. This bug
> has been fixed and will be in next minor release IIRC.

What bug? I don't quite get this point

> 
> So at the end Roboto is not mandatory even on elegant theme so all this
> is a non issue.

That's not the impression I got from every response about elegant theme
- basically each time it was said that you have to install Roboto,
because elegant theme was designed for it.

And you still haven't answered how custom user themes would work. Or is
there no plan to support custom themes and we will only allow themes
included with dt itself? That seems to unnecessary limit usefulness of
the whole theming refactoring IMHO.

For me as macOS packager there's actually no difference in how we answer
that last question, because I still have to find a way to allow dt to
use a non-system font - I'm not planning to install anything system-wide
(aside that I don't like that idea, it's just not possible with DMG
package format anyway and I have no plans to switch to other packaging
options). Or of course I can just take your word that there's no Roboto
problem and just ignore it altogether, so that elegant theme will use
available system fonts. I'm not sure what is the plan with Windows
package.

Last note - bundling data like font is not the same as bundling
libraries - most arguments against bundling code just doesn't work if
you try to apply them to this situation.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] dt master branch → Debian Next deps

[parafin]

You seem to ignore my point about custom themes - splitting (or
ignoring) elegant theme from dt doesn't solve the problem of how
theming in dt can work.
Simple example I can give is web design - web site can rely on some
standard fonts every system has, or it can optionally supply its own
font using @font-face in CSS. Given that dt themes are CSS files I think
it's a good analogy. Elegant theme falls into second category. And yes,
since we have elegant theme in dt repo, we should add Roboto font there
also.


On Sun, 19 May 2019 11:58:06 +0200
dt-l...@stefan-klinger.de wrote:

> parafin (2019-May-19, excerpt):
> > I think dt should just include needed custom fonts and not depend on
> > system ones if theme requires specific font.  
> 
> Imagine every program packing the fonts it likes, each of them in the
> version the developer found the time to include.  Should the fonts
> also be maintained in the darktable source repository?
> 
> Packages tend to specify their dependencies, rather than including
> them.  If darktable now requires a special font, add that as a
> dependency.  If depending on a non-standard font seems unfortunate,
> then maybe it is.
> 
> > So for example default theme uses system font, that's fine, elegant
> > theme uses specifically Roboto font - it should be bundled together
> > with the theme then.  
> 
> Does darktable *depend* on the elegant theme?  Or is it optional?  If
> it's optional, the whole theme should be packaged separately, having
> roboto as a required dpendency.  That would remove the dependency on
> roboto from darktable, and also reflect the true requirements.
> 
> Cheers
> Stefan
> 
> 
> -- 
> http://stefan-klinger.deo/X
> I prefer receiving plain text messages, not exceeding 32kB. /\/
>   \
> ___
> 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

Re: [darktable-dev] dt master branch → Debian Next deps

[parafin]

I think dt should just include needed custom fonts and not depend on
system ones if theme requires specific font. So for example default
theme uses system font, that's fine, elegant theme uses specifically
Roboto font - it should be bundled together with the theme then.

The reasoning for it is the following:
Since dt now supports different themes, I assume there should be a way
for users to install additional themes, not included in DT repository.
Such additional themes too may depend on custom fonts, and requiring
user to somehow install these fonts by themselves is not a workable
approach. So there should be a way for dt to use fonts not installed in
the system (which also will help packagers with existing Roboto font
problem). The main problem of course is how to do it, especially since
dt supports 3 OSes with different font systems. But IMHO this must be
solved before doing next major release.


On Sun, 19 May 2019 08:22:22 +0300
Timur Irikovich Davletshin  wrote:

> Hello, dear developers!
> 
> There is one minor problem with current debs from OBS. They depend on
> fonts-roboto package, but Roboto font is available via several other
> packages — fonts-roboto-hinted, fonts-roboto-unhinted.
> 
> Probably fonts-roboto|fonts-roboto-hinted|fonts-roboto-unhinted will be
> more logical than just fonts-roboto.
> 
> Kind regards,
> 
> Timur.
> 
> ___
> 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

Re: [darktable-dev] where to discuss big changes

[parafin]

I think we mix up 2 (or 3) different things in this topic. Let's say
a contributor wants to implement some feature:

First some discussion should probably happen, for example other
developers can help with pointers on how said feature can and should be
integrated into DT core. I don't see any need for this to be stored
anywhere or accessed by everyone else, because a lot of it will be
discarded ideas and just thoughts "out loud". Having to formulate them
carefully (as it's expected with mailing lists or forums) will just
impede communications at this stage. Historically IRC was used and I
think it's still the best tool, the only problem here is timezone
differences between developers.

Another issue is documenting the design of said feature. Right now such
documentation is basically absent in DT, but I think it would be very
useful. Something like wiki can be used for this purpose and DT actually
already had it for a long time:
https://redmine.darktable.org/projects/darktable/wiki
Of course nobody wants to write documentation, and my suggestions that
it should be done were already rejected for a couple of big features
recently merged into git master. I don't really see this changing just
because we choose some platform that currently is in fashion.

Somewhat separate issue are discussions about release planning and so
on. These I think concern only a limited number of people (specifically
developers with commit rights and package maintainers) and also
historically happened in IRC. Probably mailing list can be used also
for these, depending on the topic (if there's a lot to discuss it's
more efficient to have real-time communication though).

But all this of course is just idealisation, real life makes
corrections and compromises have to be taken. So I would suggest not to
overthink it with "pros" and "cons" of various technologies and just
make sure that necessary people are included in the loop of decision
making whatever way is actually possible.


On Wed, 17 Apr 2019 13:26:08 -0400
William Ferguson  wrote:

> We are facing the same issue, where to discuss things, with the lua-scripts
> repository.  We've thought about using github issues and discuss.pixls.us,
> but we still haven't come up with a solution.  I think I'm just going to
> try the github issues and see how it goes.
> 
> Bill
> 
> On Wed, Apr 17, 2019 at 1:22 PM Pascal Obry  wrote:
> 
> > Le mercredi 17 avril 2019 à 14:12 -0300, Moritz Moeller a écrit :  
> > > But I agree with parent that it is not the right tool to discuss big
> > > changes.
> > > IRC has no history. IRC has no message threads.
> > > That's why I mentioned NNTP.  
> >
> > My first best is GitHub Issues.
> >
> > You create an enhancement request there. It is discussed, we can add
> > some design notes...
> >
> > Then a PR is created for this and the PR can (should) reference the
> > issue number for tracking purpose. Then you'll end up with a commit
> > with a reference to the design.
> >
> > We can't do best :)
> >
> > --
> >   Pascal Obry /  Magny Les Hameaux (78)
> >
> >   The best way to travel is by means of imagination
> >
> >   http://www.obry.net
> >
> >   gpg --keyserver keys.gnupg.net --recv-key F949BD3B
> >
> > ___
> > 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

Re: [darktable-dev] Lens correction with FF lenses used on APS-C

[parafin]

dxomark.com website seems to have relevant numbers, see for example
Nikon lens mentioned by Sturm Flut:
https://www.dxomark.com/Lenses/Nikon/AF-S-Nikkor-24-70mm-f-2.8G-ED-mounted-on-Nikon-D750__975
https://www.dxomark.com/Lenses/Nikon/AF-S-Nikkor-24-70mm-f-2.8G-ED-mounted-on-Nikon-D7100__865

Interestingly enough on D810 number is higher than on D750 even though
sensor's physical dimensions are the same, probably due to the absence
of optical low-pass filter:
https://www.dxomark.com/Lenses/Nikon/AF-S-Nikkor-24-70mm-f-2.8G-ED-mounted-on-Nikon-D810__963


On Sun, 24 Feb 2019 13:32:54 +0100
Florian W  wrote:

> Thanks for the details Simon.
> 
> I also thought about it a bit and had a reasoning similar to yours, that
> basically something designed for a specific acquisition chain will probably
> perform worse on an acquisition chain farther from its spec.
> 
> However thinking about it more deeply, 2 things are still boggling my mind.
> 
> 1 This reasoning is mixing description of digital features with analog ones
> . A lens quality and specs is not defined by MP resolution (rather by like
> purity of the glass, glass curvature homogeneity, CoC, TCA, and so on).
> 
> 2 Some of the lenses we're talking about were developed and (partially)
> targeted to FF cameras having a sensor with less MP than a current APS-C
> (for example in Canon, the 6D is a 2012 FF with 20MP).
> 
> If the reasoning is valid, a lens released at times of FF with 24MP or
> higher wouldn't be a good match to the previous cameras with less MP. Which
> doesn't seems to be the case.
> 
> What I mean by this is that at some point, to ensure a lens will perform
> well on FF cameras that will be released the following decade, one can
> assume that the optical manufacturing quality is probably one order of
> magnitude above the quality required to fit the current camera sensor
> capabilities. Maybe explaining why you can see problems in older lenses.
> 
> Please feel free to point any mistake in this reasoning.
> 
> Maybe are we lucky enough that someone working in the optical lenses or
> cameras industry is part of this mailing list and provide us some insights
> about it :)
> 
> Florian Wernert
> Software engineer INSA
> In-training Neuroscience researcher
> https://www.linkedin.com/in/wernertflorian
> 
> 
> 
> Le sam. 23 févr. 2019 à 18:12, Sturm Flut  a
> écrit :
> 
> > Hi,
> >
> > Am 23.02.19 um 16:34 schrieb Florian W:  
> > > Thanks for your answers guys.
> > >
> > > Simon, I'm curious to know why to you it's not the best idea ?  
> >
> > (oversimplifying it a bit)
> >
> > Full-frame lenses are designed to deliver their full sharpness across
> > the whole full-frame image circle. If I put a full-frame lens on my
> > APS-C D7100, I am basically expecting it to deliver 24 megapixels within
> > the smaller APS-C image circle the sensor is cropping out. That means I
> > expect the lens to deliver about 24*2,25 = 54 megapixels over the whole
> > full-frame image circle. Which not that many standard lenses will do.
> >
> > If put my standard 24-70/2.8 on a Nikon D850 and (let's say) it only
> > delivers 40 megapixels of actual resolution instead of the ~46 the
> > sensor wants, that's not going to be a catastrophe. If I put it on a
> > camera with a lower resolution sensor, e.g. the 24 megapixel sensor in
> > the D750, there is zero problem. But if I put the same lens on the
> > D7100, the cropped area will only get around 40 / 2,25 = 17 megapixels.
> > That's suddenly 30% less than what the sensor needs. And not every lens
> > will even deliver these 40 megapixels. Good APS-C and especially
> > Micro-Four-Thirds lenses are expensive and hard to make because they
> > have to be very sharp within the smaller image circle.
> >
> > Prime lenses are usually sharper to begin with, so with your 50/1.8 and
> > 28/2.8 it might not be that much of an issue. But I can clearly see the
> > problem with my 24-70/2.8, and especially with the good old 70-300/4.5-5.6.
> >
> > cheers,
> > Simon
> >  
> 
> ___
> 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

Re: [darktable-dev] Dynamic Memory Allocation Overhaul

[parafin]

One can argue that crashing might be helpful for debugging - backtrace
is produced and it's possible to deduce the reason DT exited. E.g. if
some allocation size is computed too high (say due to integer
underflow) malloc can fail and if we just exit cleanly we will lose all
context of the failure. Also it might be surprising for user unless DT
prints some error message (which BTW won't be seen in most cases
because DT is usually started by users without opening a terminal
window).


On Tue, 5 Feb 2019 08:47:36 -0500
Mark Feit  wrote:

> On 2/5/19 3:10 AM, Stefan Klinger wrote:
> > IMHO it would not make sense to try to be overly smart here.  A system
> > with failing `malloc` is on the brink of desaster, and writing
> > failsave code under these conditions is extremely difficult.  For one,
> > the recovery routines must not try to allocate memory.  
> 
> Not looking for fail-safe so much as fail-nicely:  don't SIGESEGV by 
> trying to use the NULL from a failed malloc(), just close the database, 
> remove the lock file and head for the exit().  I've had dt crash hard 
> enough times that I'm not worried about state.  The most I can recall 
> losing is what I was doing on one image.
> 
> What I added exits through a function called dt_fail(), which provides a 
> good single point of exit.  What happens there can be a subject for 
> later discussion.
> 
> --Mark
> 
> 
> ___
> 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

Re: [darktable-dev] darktable 2.6 - windows and mac

[parafin]

Hi,

I plan on creating 2.6 macOS packages starting with RCs, but no, I don't
test master currently. Maybe someone else on Mac does it.


On Wed, 28 Nov 2018 17:45:38 +0100
Pascal Obry  wrote:

> Hi!
> 
> Just wanted to know what is the plan for the MacOS and Windows
> releases. Are the maintainers ready to create the corresponding
> installers? Are the current master being tested? Will there be pre-
> releases (RCn) for those OS?
> 
> Best,
> 
> -- 
>   Pascal Obry /  Magny Les Hameaux (78)
> 
>   The best way to travel is by means of imagination
> 
>   http://www.obry.net
> 
>   gpg --keyserver keys.gnupg.net --recv-key F949BD3B
> 
> ___
> 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: 2.4.0 build for MacOS?

[parafin]

And it's done:
https://github.com/darktable-org/darktable/releases/download/release-2.4.0/darktable-2.4.0.dmg


On Wed, 17 Jan 2018 13:06:33 +0100
para...@paraf.in wrote:

> I will build the package this weekend, sorry everyone for delay, I am
> very busy with work after my vacation. I have Apple certificate from
> my workplace (with permission to use it for DT), no need for anyone
> else to buy it.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] 2.4.0 build for MacOS?

[parafin]

I will build the package this weekend, sorry everyone for delay, I am very busy 
with work after my vacation. I have Apple certificate from my workplace (with 
permission to use it for DT), no need for anyone else to buy it.

> On 16 Jan 2018, at 23:14, Neil Schemenauer  wrote:
> 
>> On 2018-01-16, Bernhard wrote:
>> That's the downside of a mailing list: New users don't have a possibility to
>> read topics of the past like it would be possible in a forum ...
>> (and the gmane archive is still offline).
> 
> The third Google search result for me with the terms "darktable
> mailing list" returns a blog post that refers to the non-existing
> SourceForge mailing list archives.  I did check the devel list
> archives but did not think to check the user list archives.  A
> Google search on Friday for something like 'darktable 2.4.0 macos'
> or similar terms did not return anything useful.  I think the
> discussion happened after that or maybe wasn't indexed yet.
> 
> I'm going to look into paying the "Apple Tax" and getting a code
> signing certificate.  I can totally understand people not wanting to
> pay to sign open-source apps.  However, having a signed package will
> make it easier for people to install.  Once they see how great
> Darktable is, maybe we can get them to convert their OS to Linux.
> 
> Regards,
> 
>  Neil
> ___
> 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

Re: [darktable-dev] Trouble with following OS X build instructions (cp command at line 14 fails)

[parafin]

Hi!

I'm not sure why you are missing this port. Did you install MacPorts to
default location (/opt/local)? Maybe try running `sudo port selfupdate`
command.
As for building just for current OSX version - you can skip
/opt/local/etc/macports/macports.conf settings, python and
GraphicsMagick patches (but you still need pango patch) and don't pass
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.7 option to cmake.


On Mon, 11 Dec 2017 21:13:00 +0200
Sarge Borsch  wrote:

> I've been following 
> https://github.com/darktable-org/darktable/blob/master/packaging/macosx/BUILD.txt
> I've got a VirtualBox VM with OS X (El Capitan), installed everything as 
> written before this point, plus system updates.
> When I got to line 14, the command fails:
> $ cp -R 
> /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/lang/python36
>  ~/ports/lang
> > cp: 
> > /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/lang/python36:
> >  No such file or directory
> 
> What could be missing?
> Also, maybe I can skip (some of) these patching steps if I don't need to 
> build for OS X < 10.11? I'm building only to do some test drive by myself, so 
> it doesn't have to work on other 
> machines.___
> 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

Re: [darktable-dev] Are OS X build instructions up to date? (i.e. are official darktable .dmg builds being produced as described in the wiki article?)

[parafin]

https://github.com/darktable-org/darktable/blob/master/packaging/macosx/BUILD.txt


On Mon, 4 Dec 2017 20:44:01 +0200
Sarge Borsch  wrote:

> https://redmine.darktable.org/projects/darktable/wiki/Darktable_on_OS_X
> I thought that I'd like to test darktable from the latest source code, but 
> I'm not sure… the article is last updated in 12/09/2016 according to edit 
> history (idk what month it is by the way), and I guess it's safe to assume 
> that a lot of things changed since that time?
> Or it's still just fine?
> (I'm on macOS 10.12.6 
> currently).___
> 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

Re: quick fix for brew build on Sierra /XCode8 (was: [darktable-dev] Warning: git master now uses rawspeed as submodule !)

[parafin]

> On 4 Jan 2017, at 18:21, Roman Lebedev  wrote:
> 
>> On Wed, Jan 4, 2017 at 10:20 AM,   wrote:
>> Changes to cmake files is probably the culprit - rawspeed now doesn't 
>> inherit CFLAGS from darktable and so is missing include path for libjpeg.
> 
> But from where did darktable get that jpeg include path? From user?
> rawspeed does look for jpeg:
> https://github.com/darktable-org/rawspeed/blob/c42c358973b40a266f41de62e06a09a8d309c289/RawSpeed/CMakeLists.txt#L26-L27

Hmm, you're right and git master actually compiles for me as is. I'm using 
macports here. So the question is where brew is different. Grep for 
JPEG_INCLUDE_DIRS in CMakeCache.txt in build directory (which BTW should be 
cleaned of course) should help.

> 
>> P.S.
>> About switching from stable to master branch and back - there're also issues 
>> with cherry-picking commits for some reason. We need to come up with correct 
>> and clean way of branch checkout… Maybe git clean is needed…
> Yeah, it will be a painful expirience. At least it will end one way or
> another once 2.4 is out.
> 
> Roman.
> 
>>> On 4 Jan 2017, at 05:05, Wolfgang Goetz  wrote:
>>> 
>>> Roman Lebedev wrote:
>>> 
 On Tue, Jan 3, 2017 at 1:46 AM, Wolfgang Goetz
  wrote:
> MacOS/brew broken:
> ...
> [  2%] Building CXX object
> src/external/rawspeed/RawSpeed/CMakeFiles/rawspeed.dir/ArwDecoder.cpp.o
> In file included
> from 
> /Users/wolfganggoetz/repos/darktable/src/external/rawspeed/RawSpeed/ArwDecoder.cpp:1:
>  
> /Users/wolfganggoetz/repos/darktable/src/external/rawspeed/RawSpeed/StdAfx.h:97:10:
> fatal error: 'jpeglib.h' file not found #include "jpeglib.h" ^
> 1 error generated.
 Hmm, you do have jpeg or jpeg-turbo formula installed?
>>> 
>>> 
>>> 
 Because travis-ci osx builds do not fail, e.g.
 https://travis-ci.org/darktable-org/rawspeed/jobs/188323509
>>> 
>>> 
>>> 
>>> to make it short:  
>>> http://stackoverflow.com/questions/14525898/cmake-doesnt-set-xcodes-user-include-path
>>> 
>>> not sure if it's the right place, looks more like sledgehammer:
>>> 
>>> 
>>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>>> index 6b7a1530f..d8e57008b 100644
>>> --- a/CMakeLists.txt
>>> +++ b/CMakeLists.txt
>>> @@ -32,7 +32,7 @@ endif()
>>> IF(DEFINED DT_FORCE_CXX_COMPILER)
>>>  set(CMAKE_CXX_COMPILER ${DT_FORCE_CXX_COMPILER})
>>> endif()
>>> -
>>> +include_directories(/usr/local/include)
>>> include(CheckCCompilerFlag)
>>> include(TestBigEndian)
>>> 
>>> 
>>> 
>>> build OK, dt 2.3.0+142 running :-)
>>> 
>>> 
>>> 
>>> kind regards
>>> Wolfgang
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> the long way:
>>> 
>>> 
>>> travis is cool.
>>> attention: default is OSX 10.11/XCode 7.3.1
>>> 
>>> i'm on real hardware more like osx_image: xcode8.2
>>> exact:macOS Sierra Version 10.12.2, XCode Version 8.2.1 (not avail in 
>>> travis)
>>> 
>>> 
>>> 
>>> brew is cool. (in darktable: 'brew bundle' for dependencies, atm just 
>>> updating to gcc-6.3.0, this will take some time!)
>>> 
>>> tags/release-2.2.1 build is ok.
>>> 
>>> /usr/local/include/jpeglib.h exists.
>>> 
>>> playing around with CC and CXX environments doesnt help. (fun to see gcc-6 
>>> as CC and clang as CXX)
>>> 
>>> sandboxing: same error
>>> export PATH=.:$PATH
>>> brew bundle exec build.sh
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> VERBOSE=1
>>> 
>>> 
>>> with submodule:
>>> 
>>> [  3%] Building CXX object 
>>> src/external/rawspeed/RawSpeed/CMakeFiles/rawspeed.dir/ArwDecoder.cpp.o
>>> cd 
>>> /Users/wolfganggoetz/repos/darktable/build/src/external/rawspeed/RawSpeed 
>>> && 
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>>>-DDEBUG -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED 
>>> -DGTK_DISABLE_SINGLE_INCLUDES -DOS_OBJECT_USE_OBJC=0 -D_XOPEN_SOURCE=700 
>>> -D__GDK_KEYSYMS_COMPAT_H__ -isystem 
>>> /usr/local/Cellar/pugixml/1.8.1/include/pugixml-1.8  -D_DARWIN_C_SOURCE 
>>> -Wall -fno-strict-aliasing -Wformat -Wformat-security -Wshadow 
>>> -Wtype-limits -Wvla -Wno-error=varargs -Wframe-larger-than=32768 
>>> -Wlarger-than=524288 -std=c++11 -fno-strict-aliasing -Wall 
>>> -fno-strict-aliasing -Wformat -Wformat-security -Wshadow -Wtype-limits 
>>> -Wvla -Wno-error=varargs -Wframe-larger-than=32768 -Wlarger-than=524288 -O2 
>>> -g -DNDEBUG -O2 -isysroot 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>>>  -fPIC   -march=native -g3 -ggdb3 -o 
>>> CMakeFiles/rawspeed.dir/ArwDecoder.cpp.o -c 
>>> /Users/wolfganggoetz/repos/darktable/src/external/rawspeed/RawSpeed/ArwDecoder.cpp
>>> In file included from 
>>> /Users/wolfganggoetz/repos/darktable/src/external/rawspeed/RawSpeed/AriDecoder.cpp:1:
>>> /Users/wolfganggoetz/repos/darktable/src/external/rawspeed/RawSpeed/StdAfx.h:97:10:
>>> fatal error: 'jpeglib.h' file not found
>>> 
>>> 
>>> 
>>> 
>>> good output from release-2.2.1:
>>> 

Re: quick fix for brew build on Sierra /XCode8 (was: [darktable-dev] Warning: git master now uses rawspeed as submodule !)

[parafin]

Changes to cmake files is probably the culprit - rawspeed now doesn't inherit 
CFLAGS from darktable and so is missing include path for libjpeg.

P.S.
About switching from stable to master branch and back - there're also issues 
with cherry-picking commits for some reason. We need to come up with correct 
and clean way of branch checkout… Maybe git clean is needed…

> On 4 Jan 2017, at 05:05, Wolfgang Goetz  wrote:
> 
> Roman Lebedev wrote:
> 
>> On Tue, Jan 3, 2017 at 1:46 AM, Wolfgang Goetz
>>  wrote:
>>> MacOS/brew broken:
>>> ...
>>> [  2%] Building CXX object
>>> src/external/rawspeed/RawSpeed/CMakeFiles/rawspeed.dir/ArwDecoder.cpp.o
>>> In file included
>>> from 
>>> /Users/wolfganggoetz/repos/darktable/src/external/rawspeed/RawSpeed/ArwDecoder.cpp:1:
>>>  
>>> /Users/wolfganggoetz/repos/darktable/src/external/rawspeed/RawSpeed/StdAfx.h:97:10:
>>> fatal error: 'jpeglib.h' file not found #include "jpeglib.h" ^
>>> 1 error generated.  
>> Hmm, you do have jpeg or jpeg-turbo formula installed?
> 
> 
> 
>> Because travis-ci osx builds do not fail, e.g.
>> https://travis-ci.org/darktable-org/rawspeed/jobs/188323509
> 
> 
> 
> to make it short:  
> http://stackoverflow.com/questions/14525898/cmake-doesnt-set-xcodes-user-include-path
> 
> not sure if it's the right place, looks more like sledgehammer:
> 
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 6b7a1530f..d8e57008b 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -32,7 +32,7 @@ endif()
> IF(DEFINED DT_FORCE_CXX_COMPILER)
>   set(CMAKE_CXX_COMPILER ${DT_FORCE_CXX_COMPILER})
> endif()
> -
> +include_directories(/usr/local/include)
> include(CheckCCompilerFlag)
> include(TestBigEndian)
> 
> 
> 
> build OK, dt 2.3.0+142 running :-)
> 
> 
> 
> kind regards
> Wolfgang
> 
> 
> 
> 
> 
> 
> the long way:
> 
> 
> travis is cool. 
> attention: default is OSX 10.11/XCode 7.3.1 
> 
> i'm on real hardware more like osx_image: xcode8.2  
> exact:macOS Sierra Version 10.12.2, XCode Version 8.2.1 (not avail in travis)
> 
> 
> 
> brew is cool. (in darktable: 'brew bundle' for dependencies, atm just 
> updating to gcc-6.3.0, this will take some time!)
> 
> tags/release-2.2.1 build is ok.
> 
> /usr/local/include/jpeglib.h exists.
> 
> playing around with CC and CXX environments doesnt help. (fun to see gcc-6 as 
> CC and clang as CXX)
> 
> sandboxing: same error
> export PATH=.:$PATH
> brew bundle exec build.sh
> 
> 
> 
> 
> 
> 
> 
> VERBOSE=1 
> 
> 
> with submodule:
> 
> [  3%] Building CXX object 
> src/external/rawspeed/RawSpeed/CMakeFiles/rawspeed.dir/ArwDecoder.cpp.o
> cd /Users/wolfganggoetz/repos/darktable/build/src/external/rawspeed/RawSpeed 
> && 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>-DDEBUG -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED 
> -DGTK_DISABLE_SINGLE_INCLUDES -DOS_OBJECT_USE_OBJC=0 -D_XOPEN_SOURCE=700 
> -D__GDK_KEYSYMS_COMPAT_H__ -isystem 
> /usr/local/Cellar/pugixml/1.8.1/include/pugixml-1.8  -D_DARWIN_C_SOURCE -Wall 
> -fno-strict-aliasing -Wformat -Wformat-security -Wshadow -Wtype-limits -Wvla 
> -Wno-error=varargs -Wframe-larger-than=32768 -Wlarger-than=524288 -std=c++11 
> -fno-strict-aliasing -Wall -fno-strict-aliasing -Wformat -Wformat-security 
> -Wshadow -Wtype-limits -Wvla -Wno-error=varargs -Wframe-larger-than=32768 
> -Wlarger-than=524288 -O2 -g -DNDEBUG -O2 -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>  -fPIC   -march=native -g3 -ggdb3 -o CMakeFiles/rawspeed.dir/ArwDecoder.cpp.o 
> -c 
> /Users/wolfganggoetz/repos/darktable/src/external/rawspeed/RawSpeed/ArwDecoder.cpp
> In file included from 
> /Users/wolfganggoetz/repos/darktable/src/external/rawspeed/RawSpeed/AriDecoder.cpp:1:
> /Users/wolfganggoetz/repos/darktable/src/external/rawspeed/RawSpeed/StdAfx.h:97:10:
> fatal error: 'jpeglib.h' file not found
> 
> 
> 
> 
> good output from release-2.2.1:
> 
> [  2%] Building CXX object 
> src/external/rawspeed/CMakeFiles/rawspeed.dir/RawSpeed/ArwDecoder.cpp.o
> cd /Users/wolfganggoetz/repos/darktable_old/build/src/external/rawspeed && 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>-DGDK_DISABLE_DEPRECATED -DGDK_VERSION_MIN_REQUIRED=GDK_VERSION_3_14 
> -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_MIN_REQUIRED 
> -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGTK_DISABLE_DEPRECATED 
> -DGTK_DISABLE_SINGLE_INCLUDES -DHAVE_CONFIG_H -DHAVE_GPHOTO2 
> -DHAVE_GPHOTO_25_OR_NEWER -DHAVE_GRAPHICSMAGICK -DHAVE_HTTP_SERVER 
> -DHAVE_KWALLET -DHAVE_LENSFUN -DHAVE_LIBSECRET -DHAVE_OPENCL -DHAVE_OPENEXR 
> -DHAVE_OPENJPEG -DMAC_INTEGRATION -DOS_OBJECT_USE_OBJC=0 -DUSE_LUA 
> -D_XOPEN_SOURCE=700 -D__GDK_KEYSYMS_COMPAT_H__ 
> -I/Users/wolfganggoetz/repos/darktable_old/src 
> -I/Users/wolfganggoetz/repos/darktable_old/src/external -isystem 
> /usr/local/include/glib-2.0 -isystem 
>