Re: [darktable-dev] OpenCL failure on AMD kernel 6.6,x

2024-01-01 Thread Sturm Flut

Hi,

that sounds like one of the endless AMD GPU stability issues other 
people and myself (RX 570, RX 6600 XT, ...) have been having for years.


ROCm is simply not reliable on consumer cards and never has been. ROCm 
6.0 officially only supports the MI100/MI200/MI300 data center GPUs, the 
Radeon Pro W7900/W6800/V620/VII and the Radeon RX 7900/VII on at most 
kernel 6.2 (Ubuntu 22.04.3). Everything else is unsupported.


From what I have gathered over the years, I would say running both 
graphics and compute at the same time on the same AMD GPU without 
messing up the internal memory management/GPU state only seems to work 
reliably under *very* strict constraints.


The data center chips don't support any graphics at all, so no issues 
there (we run MI100/MI210/MI250s at work and I've never seen anything 
like this there). The Radeon Pro W7900/W6800/V620/VII GPUs are usually 
only available in very few and certified configurations, so probably 
less issues to keep track of. But the RDNA2/RDNA3-based consumer GPUs 
are being used in an endless variety of system builds and 
configurations, and I assume AMD developers simply don't invest a lot of 
time in making these more stable since ROCm doesn't support them anyways.


When the drm/amdgpu errors started appearing, I would usually have at 
most 20 minutes until the whole machine would lock itself up. So every 
time I noticed OpenCL issues in darktable, I had to reboot, breaking my 
workflow and concentration. If I had a lot of work before me, I would 
simply turn OpenCL off completely and trade speed for stability.


For me the situation became so unbearable last year, I ended up plugging 
in an Intel Arc A770 GPU besides my RX 6600 XT. The A770 only does 
OpenCL (not just for darktable), the RX 6600 XT only graphics (ROCm is 
not installed). I would maybe be able to get my hand on an MI100, but 
they're passively cooled and don't fit into a standard ATX case.


(The sorry state of OpenCL might also be a reason to put more emphasis 
on darktable's CPU codepaths and other optimisations again.)


cheers,
Simon


P.S. Not just using a different/recent kernel can break a working setup, 
but also changing the firmware files (usually installed in 
/lib/firmware/amdgpu/). An update of the firmware package might 
therefore also break a previously working kernel.




On 21.12.23 21:01, Šarūnas wrote:

Debian unstable,
kernel 6.6 from experimental,
ROCm 6.0,
Radeon RX 7600,
darktable 4.4.2.

OpenCL works 2 out of 3 times between reboots.
~/.cache and ~/.config/darktable are purged between reboots.

When it works, all is fine, no error messages.

When it doesn't (stuck at/before CL kernel compile), attaching to 
darktable process with `strace` shows endless FUTEX'es. dmesg shows 
repeating amdgpu drm and iommu errors (they keep repeating after 
darktable is stopped).





OpenPGP_0xCE9228264D6BD39A_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [darktable-dev] proposal about AI

2023-09-30 Thread Sturm Flut

Hi,

I'm against taking an official stand on this for the following reasons:

1. There is no consensus on what "AI" means. darktable already uses 
algorithms that may count as "artificial intelligence" depending on 
someone's viewpoint, and on the other hand algorithms classically used 
for generative AI can be used in endless other, "non-problematic" ways. 
The distinction is arbitrary.


2. There is no clarification what "100% AI free" or "mechanization of 
photography" or "human style" photography means in this context, or 
where you think exactly the software starts making "creative decisions". 
Depending on how one argues, one could e.g. see the existing "retouch" 
module or even the copy/paste functionality as already being problematic 
in these regards.


3. I'm actually in favor of the "mechanization of photography" at least 
to some degree. The machine doesn't have to take everything away from me 
or generate (parts of) images I've never taken, but stuff also doesn't 
have to be pointlessly hard because functionality is missing due to 
arbitrary decisions. Would it be nice to be able to train an algorithm 
on all my previous edits so freshly imported images automatically have 
the basic settings set up similar to what I would do to those images 
anyways? Sure. Create masks from auto-segmentation, so I don't have to 
manually draw all of them all the time? Sure. Content-aware denoise? 
Sure. Generative fill in the "retouch" module? Maybe, heavily depends on 
how it's done. Do I want darktable to go in the same direction as 
Luminar, where people can even automatically swap out the whole sky for 
a stock image? Probably not, but other people might see some value in 
something like that.


darktable is just a tool. Social issues cannot be solved by (limiting) 
technology.


With kind regards,
Simon


Am 22.09.23 um 12:29 schrieb Jason Polak:

Dear darktable devs,

I am not sure how well this will be received, but I have a proposal. 
Probably everyone knows that AI and particularly generative AI is taking 
the world by storm. Adobe and many other Raw developers embed it into 
their products.


One of the great things about darktable is that it does not offer any AI 
tools. This is amazing because people can use it as a product without 
supporting AI (simply using AI is supporting its development).


I was wondering what the devs thought about this?

My thinking is that AI takes us out of the realm of free-functioning 
creativity by making creative decisions for us. It's a mechanization of 
photography and it ultimately harms it.


So, IF you agree with this, I was wondering if the darktable team would 
like to make a stand with me against AI, by stating that darktable will 
not use AI in the future, or offer any AI tools? I know this email may 
seem rather strange to all of you but I think AI poses a real danger to 
humanity. I am creating a sort of informal coalition of artists and 
people who do not use AI.


I have a YouTube channel and I already put "AI Free" on my YouTube 
channel. I attached an example of the button I created in Inkscape for 
this and I provided an SVG for some ideas. I know this sounds rather 
radical, and I am not trying to force anything on anyone. Everyone has 
to make their own choice about AI.


Again, I know I'm a bit strange but please at least consider this 
message. The  more people that actively advocate against AI, the better. 
So, IF anyone reading this has any qualms about AI and there is some 
sort of consensus, please consider my proposal.


Thanks,
Jason Polak -- A long time darktable user and person who loves 
photography, "human style"

___
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.org down?

2023-07-16 Thread Sturm Flut
Hi,

can confirm, has been down since Friday.

Kind regards,
Simon

14.07.2023 12:50:24 Bernhard :

> Hi there,
> 
> I get
> Failed to connect to www.darktable.org port 443: Connection refused
> 
> anyone else also experiencing this?
> -- 
> 
> regards
> Bernhard
> 
> https://www.bilddateien.de
> ___
> 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] Is this a bug?

2022-08-25 Thread Sturm Flut

Hi,

Am 16.08.22 um 20:19 schrieb Jeronimo Pellegrini:

during GIMPLE pass: graphite


what CFLAGS are you using? Graphite is known to be error-prone and 
unmaintained.


cheers,
Simon


OpenPGP_0xCE9228264D6BD39A_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Re: [darktable-dev] Apparently the removal of the XMP file still causes darktable to crash ...

2021-04-07 Thread Sturm Flut
Hi,

there is a workaround:

darktable ships an utility called "purge_non_existing_images.sh". If you
move the problematic picture to a different location and run the script
with "purge_non_existing_images.sh --purge", it will remove the data for
this image from the database because the path stored in the database
does not exist anymore.

kind regards,
Simon


Am 07.04.21 um 16:35 schrieb Postmaster:
> Since i cant get darktable to run without crashing, i cant erase the
> picture from its memory.
> do I have to delete the .db file before i run darktable?
> 
> On 4/7/21 10:11 AM, Mica Semrick wrote:
>> Everything that is in the XMP is held in the db as well.
>>
>> On April 7, 2021 6:30:59 AM PDT, Postmaster 
>> wrote:
>>> Which leads me to think that the history of the picture is being kept
>>> in
>>> an alternate place. Like somewhere in .cache. Maybe a .db?
>>> OR is it my imagination that something more is happening to me.
>>> ___
>>>
>>> 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] Local Contrast Module broken using OpenCL

2020-08-16 Thread Sturm Flut

Hi,

Am 15.08.20 um 13:21 schrieb Dusenberg:
[..] I shouldn't be seeing the problem as it only affects the/open 
source/ OpenCL package running with the/open source/ amdgpu driver. Have 
I got this right?


Yes. There have been problems with ROCm, darktable and visual artifacts 
for years. AMDGPU-PRO works fine.



Is it possible I'm somehow using the open source 
OpenCL instead of the PRO? 


No Linux distribution I know of uses ROCm by default, many (e.g. Ubuntu) 
don't even include it in the repositories. Getting ROCm-OpenCL running 
on your RX 5500 (Navi 14) is also not trivial.


So ROCm is not something you would be running without knowing it.

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



Re: [darktable-dev] Dynamic Range Priority fujifilm

2019-12-24 Thread Sturm Flut

Hi Lorenzo,

as far as I understand, this is the same situation as with Sony's DRO, 
Canon's ALO, Nikon's Active D-Lighting and Fujifilm's D-Rng.


These dynamic range modes don't just affect in-camera JPEG processing, 
but also dynamically manipulate exposure metering (Nikon's Active 
D-Lighting can e.g. underexpose the picture up to 2/3 EV). It's quite 
hard to replicate the algorithms behind these modes in "generic" RAW 
developers like darktable, Lightroom, Capture One etc., which is why the 
developers of these applications usually don't handle them at all and 
leave it to the user.


So there will always be a difference between generic RAW developers and 
the manufacturer-supplied developers.


I personally always disable Active D-Lighting on my Nikons since even in 
the highest mode it usually doesn't do enough.


cheers,
Simoon



On 22.12.19 20:31, Lorenzo Fontanella wrote:

Hello to all,
I finally understood why I could not have even a similar correspondence 
between the jpeg files and the raf files of fujifilm X-H1.
 From the H1 model onwards, therefore also in the T3, T30 and Pro3 
models, fujifilm has adopted a new mode called Dynamic Range Priority 
(DR P) on camera.
This mode actually uses the DR 100-200-400 controls in combination with 
the active management of the highlights that "reduces" and the 
management of the shadows that "opens" according to an ad-hoc tone 
curve; in fact, when using this new mode, the management controls for 
highlights and shadows are disabled.
Even more important is that unlike the DR mode, which operates only on 
the jpeg files, in this case METATAGs are also saved in the RAF files, 
and the software capable of reading these metatags, elaborate when 
opening in mode "AUTO" the .RAF file in a very similar way to the jpeg 
sooc, when instead it goes to the processing in manual mode, it works on 
the raw file "clean as from snap".


I don't understand if DarkTable considers this mode, I don't think, but 
it would be interesting to evaluate this new mode, since presumably it 
will always be implemented on future models of Fujifilm cameras.

Lorenzo Fontanella
---
Calcinato Via Monte 2 - cell. 3288145594

___ 
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

2019-12-17 Thread Sturm Flut

Hi Andreas,

On 16.12.19 20:13, Andreas Schneider wrote:

darktable is setting a flag for images to be HDR and SDR. It doesn't really
make use of it, but we probably have to change that in future.


After thinking about it a bit more:

What is this flag going to be used for in the future? I think the answer 
to that question would help a lot with the design of a heuristic approach.


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



Re: [darktable-dev] HDR and SDR

2019-12-17 Thread Sturm Flut

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.


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



Re: [darktable-dev] Database lock file seems too lenient

2019-12-15 Thread Sturm Flut

Hi Owen,

On 14.12.19 19:02, Owen Mays wrote:

1) Why go to the trouble of adding hostname to PID in the lock file, why 
not just check for existence of the lock file and treat that as evidence 
that the database is open? It looks like many lines of code have been 
written in database.c dedicated to finding an excuse to ignore the lock 
file :-) (by checking for a running process, etc).


Since the backend database is not designed to be shared among machines 
via the network, darktable is a single-machine application by design. 
The point of the lock file is to keep multiple processes on the same 
machine from opening the database at the same time. If the lockfile 
exists on invocation, there are two possible cases:


- An instance of darktable is already running, so it's better to open 
the files passed to the second instance (if any) in the first one and 
quit the second instance. I use this all the time to open RAW files from 
the command line in the running darktable instance.


- A previous instance of darktable crashed and didn't remove the 
lockfile. Since SQLite does a basic sanity check on the database before 
opening it, it's much better usability to handle this case automatically 
and just overwrite the lock file. Otherwise users would complain about 
this easy-to-fix nuisance.



2) Since sharing the library is not recommended, is there a recommended 
way to have one computer be aware of edits made on/by another computer? 
The problem I'm trying to solve is: my photos live on my laptop and are 
usually imported and edited there. For large jobs, I would like to be 
able to do processing on my desktop, which has a GPU. My current 
solution is to mount my laptop harddrive on the desktop via sshfs and 
point both darktable instances to a library file in the shared folder.


I have the same requirement, my pictures live on a central file server. 
I keep local darktable databases on all machines and activate the "look 
for updated xmp files on startup" option in the "core options" in the 
darktable settings.


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



Re: [darktable-dev] Database lock file seems too lenient

2019-12-14 Thread Sturm Flut

Hi Owen,

the locking mechanism could probably be extended to also include the 
hostname in the lockfile.


The problem with putting SQLite databases on a network share is that 
it's discouraged by SQLite [1] to begin with because too many things can 
go wrong. If darktable's locking mechanism fails for any reason, you 
might end up with two darktable instances on two difference machines 
accessing your database and corrupting it.


cheers,
Simon


[1] https://www.sqlite.org/faq.html#q5


On 14.12.19 09:42, Owen Mays wrote:

Hello Darktable Devs,

First of all, thanks for a fantastic program!

I'm attempting to share a darktable library between two computers (using 
the same network storage), and I'm concerned about accidentally 
corrupting the database. Darktable creates a lock file, but when I 
launch darktable on the second computer, it just overwrites the lock file.


It appears this is due to logic in the database.c file that checks 
whether the PID in the lockfile belongs to an active process. Because 
the lockfile was created by a process on another computer, darktable 
thinks the lockfile is stale and overwrites it.


Is there a reason the lockfile is not more strict? Why go to the effort 
of checking the PID, why not assume the lockfile means a lock, and if 
it's stale, leave it to the user to resolve?


I can create a bash script wrapper to launch darktable that will first 
check for the lockfile, but I'd like to understand the design decision.


Thanks,
Owen

___ 
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] D850 does not appear in list (2)

2019-12-06 Thread Sturm Flut

Dear list,

for future reference:

The command was initially called "update-lensfun-data" and then later 
renamed to "lensfun-update-data".


Ubuntu actually didn't ship it before Ubuntu 18.04 (bionic). So it's not 
included in Ubuntu 16.04 (xenial).


cheers,
Simon




On 06.12.19 18:26, Dimitri Gathy wrote:
For a photographic (others than kernel, services, drivers) uses, the 
xenial is outdated. Liblensfun-bin is missing.


Le ven. 6 déc. 2019 à 14:35, Pascal Obry > a écrit :



And on Debian it is in : liblensfun-bin

-- 
   Pascal Obry /  Magny Les Hameaux (78)


   The best way to travel is by means of imagination

http://photos.obry.net
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] Camera D850

2019-12-05 Thread Sturm Flut

Hello Jesus,

I have a D850 too. At least Ubuntu 18.04.3 LT still seems to ship a 
lensfun database snapshot from 2015, so I usually have to run the 
"lensfun-update-data" command from the "liblensfun-bin" package once to 
make sure the local lensfun database is up to date.


cheers,
Simon


On 02.12.19 18:41, Jesus Arocho wrote:

Hello,

I found the compile issue with the libxml2 library,and successfully 
compiledthe3.0rcon a KDE/Ubuntuplatform.  No issues whenexecuting,so far.


However, theprogramdoes notassociatethe NikonD850inthelens 
correctionmodule,noris it displayed in the drop-downlist.  I did find 
thecamera listed inthefiles underthe rawspeeddirectory(filecameras.xml) 
and in the noiseprofiles.


What amI missing?

Thanks

___ 
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] Debian builds → proper naming

2019-12-05 Thread Sturm Flut

Hello Timur,

you probably have to suggest this on the matching website of this 
third-party service: 
https://build.opensuse.org/package/show/graphics%3Adarktable%3Amaster/darktable


cheers,
Simon




On 05.12.19 15:23, Timur Irikovich Davletshin wrote:

Nicolas, I'm talking about builds provided by dt developers —
https://software.opensuse.org/download.html?project=graphics:darktable:master&package=darktable

Timur.

On Thu, 2019-12-05 at 15:01 +0100, Nicolas Auffray wrote:

Hi Timur,

Maybe but linux packages builds are not related to darktable teams.
For
Debian builds, you have to see that with Debian team, not darktable
one.


Le 05/12/2019 à 05:08, Timur Irikovich Davletshin a écrit :

Hi developers!

It can be considered as a bug since creators of darktable insist on
lower case spelling. Debian builds use "Darktable" spelling which
should be fixed.

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 3.0 rc1 openCL

2019-11-20 Thread Sturm Flut

Hi,

AFAICT your card hasn't been on the list of supported chips since the 
AMDGPU-PRO 14.04 driver. This was discussed on the darktable mailing 
list two years ago 
(https://www.mail-archive.com/darktable-user@lists.darktable.org/msg02791.html).


If you want to run Ubuntu 18.04.3 with the Hardware Enablement kernel 
(5.0.x), you need the AMDGPU-PRO 19.30 driver, BTW.


cheers,
Simon






On 19.11.19 04:27, Jozef Dassen wrote:
After a lot of struggle I managed to install amdgpu drivers on my Ubuntu 
18.04.
It did not work with kernel 5.0 but going back to kernel 4.15 worked 
fine. Flawless installation of amdgpu 18.40.
Then I ran darktable-cltest  (darktable 3.0 rc1) and got the following 
result:

0.037740 [opencl_init] opencl related configuration options:
0.037752 [opencl_init]
0.037755 [opencl_init] opencl: 1
0.037757 [opencl_init] opencl_library: ''
0.037759 [opencl_init] opencl_memory_requirement: 500
0.037761 [opencl_init] opencl_memory_headroom: 0
0.037763 [opencl_init] opencl_device_priority: '*/!0,*/*/*'
0.037784 [opencl_init] opencl_mandatory_timeout: 200
0.037786 [opencl_init] opencl_size_roundup: 16
0.037788 [opencl_init] opencl_async_pixelpipe: 0
0.037790 [opencl_init] opencl_synch_cache: active module
0.037794 [opencl_init] opencl_number_event_handles: 25
0.037797 [opencl_init] opencl_micro_nap: 1000
0.037800 [opencl_init] opencl_use_pinned_memory: 0
0.037802 [opencl_init] opencl_use_cpu_devices: 0
0.037804 [opencl_init] opencl_avoid_atomics: 1
0.037806 [opencl_init]
0.037962 [opencl_init] found opencl runtime library 'libOpenCL'
0.037980 [opencl_init] opencl library 'libOpenCL' found on your system 
and loaded

0.170870 [opencl_init] found 1 platform
0.170885 [opencl_init] found 1 device
0.170923 [opencl_init] device 0 `Capeverde' supports image sizes of 
16384 x 16384
0.170927 [opencl_init] device 0 `Capeverde' allows GPU memory 
allocations of up to 1053MB

[opencl_init] device 0: Capeverde
  GLOBAL_MEM_SIZE:  1472MB
  MAX_WORK_GROUP_SIZE:  256
  MAX_WORK_ITEM_DIMENSIONS: 3
  MAX_WORK_ITEM_SIZES:  [ 1024 1024 1024 ]
  DRIVER_VERSION:   2686.5
  DEVICE_VERSION:   OpenCL 1.2 AMD-APP (2686.5)
0.171329 [opencl_init] could not create command queue for device 0: -6
0.171373 [opencl_init] FINALLY: opencl is NOT AVAILABLE on this system.
0.171376 [opencl_init] initial status of opencl enabled flag is OFF.
my display is:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Venus XTX [Radeon HD 8890M / R9 M275X/M375X] (rev 83) (prog-if 
00 [VGA controller])

     Subsystem: Dell Venus XTX [Radeon HD 8890M / R9 M275X/M375X]
     Flags: bus master, fast devsel, latency 0, IRQ 128
     Memory at b000 (64-bit, prefetchable) [size=256M]
     Memory at de30 (64-bit, non-prefetchable) [size=256K]
     I/O ports at e000 [size=256]
     Expansion ROM at 000c [disabled] [size=128K]
     Capabilities: [48] Vendor Specific Information: Len=08 
     Capabilities: [50] Power Management version 3
     Capabilities: [58] Express Legacy Endpoint, MSI 00
     Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
     Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 
Len=010 

     Capabilities: [150] Advanced Error Reporting
     Capabilities: [200] #15
     Capabilities: [270] #19
     Kernel driver in use: amdgpu
     Kernel modules: radeon, amdgpu
I have fresh Ubuntu 18.04-1 installation on a sytem with 64Gbyte RAM. 
Only Firefox is running. So no resource problems.
I have deferred all other installations until I can get darktable with 
openCL running. This is a sine-qua-non for me.

So no luck... Again
Any ideas what could be the problem ??
darktablerc parameters:
opencl=true
opencl_async_pixelpipe=false
opencl_avoid_atomics=true
opencl_checksum=
opencl_device_priority=*/!0,*/*/*
opencl_disable_drivers_blacklist=false
opencl_library=
opencl_mandatory_timeout=200
opencl_memory_headroom=0
opencl_memory_requirement=500
opencl_micro_nap=1000
opencl_number_event_handles=25
opencl_scheduling_profile=default
opencl_size_roundup=16
opencl_synch_cache=active module
opencl_use_cpu_devices=false
opencl_use_pinned_memory=false
Regards, Jozef Dassen

___ 
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] GCC version, optimisation options, split-loops

2019-10-19 Thread Sturm Flut
Hi,

GCC 6.3.0 is just three years old (December 21, 2016). Most codebases
don't profit as much from optimization as darktable does, so it's no
wonder most build with GCC 6.x and even much older releases. Red Hat 7.7
still ships GCC 4.8.5...

cheers,
Simon



Am 18.10.19 um 17:55 schrieb Marco Tedaldi:
> Hello
> 
> Thanks very much. I've now upgraded my GCC (which it was REALLY time
> for). Interestingly, it seemed to work quite ok until recently...
> 
> best regards
> 
> Marco
> 
> Am So., 6. Okt. 2019 um 15:58 Uhr schrieb Aurélien Pierre
> mailto:rese...@aurelienpierre.com>>:
> 
> Hi,
> 
> We support GCC 8 and 9. GCC 6 is quite old already.
> 
> The commit you refer to affects only CLang.
> 
> Cheers,
> 
> Aurélien.
> 
> Le 06/10/2019 à 15:26, Marco Tedaldi a écrit :
>> Hi Everyone
>> After a long time away from this list (but still regularly working
>> with git master) I'm back here...
>>
>>
>> I've just tried to compile dt master again and it failed on me...
>> The reason is that my GCC doesn't recognize the option split-loops
>>
>> Error:
>> /home/marco/build/darktable/src/iop/toneequal.c:1312:1: error:
>> unrecognized command line option ‘-fsplit-loops’
>>
>> My GCC-Version
>> marco@schwipschwap:~/build/darktable$ gcc --version
>> gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
>>
>> Interestingly,the last time I compiled dt it worked. It was: dt
>> 2.7.0+1709~g580bf49da
>>
>>
>> As a workaround for me I've just removed the option "split-loops"
>> from the following files:
>> src/common/fast_guided_filter.h
>> src/common/luminance_mask.h
>> src/iop/choleski.h
>> src/iop/filmicrgb.c
>> src/iop/toneequal.c
>>
>>
>> So my question is: what version of gcc is required to compile it?
>>
>> could it be that commit 50742fa02bdf511e62f3bbe10b11c61c2036e4e5 
>> 
>> https://github.com/darktable-org/darktable/commit/50742fa02bdf511e62f3bbe10b11c61c2036e4e5#diff-b93b6846a64705e34a1eb02a9d620317
>>
>> made my version of gcc stumble?
>>
>> best regards
>>
>> Marco
>>
>> 
>> ___
>> 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: Fwd: [darktable-dev] Standardization of the writing of mouse interactions in the user manual

2019-10-02 Thread Sturm Flut
Hi,

Am 02.10.19 um 14:31 schrieb Julian Rickards:
> This is not clear to me because the mouse wheel can be rolled towards
> the user or away from the user. Perhaps Ctrl+(scroll wheel away) and
> Ctrl+(scroll wheel towards).

Different environments have different defaults. In some "away from the
user" defaults to "up", in some it defaults to "down". Also most
enviroments allow the user to flip the directions.

(I for example always change the default scroll direction in GNOME.)

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



Re: [darktable-dev] jsonschema version issues

2019-09-05 Thread Sturm Flut
Hi,

this doesn't look like a problem with the actual build process, but more
like a problem with your local operating system installation.

Try running /usr/local/bin/jsonschema manually on a terminal. Does it
crash with the same error message?

Where did you get the spec file for the package from?

cheers,
Simon



Am 05.09.19 um 13:03 schrieb Terry Duell:
> 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,
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



Re: [darktable-dev] tagging module improvements

2019-08-06 Thread Sturm Flut
Hi,

I don't think there currently is a way to automatically apply a style to
a tag, and if it was there might be conflicting tags with conflicting
associated default styles etc.

At least in 2.7.x you can filter images by tag in the "collect images"
module and then apply a style to all filtered images.

kind regards,
Simon



Am 06.08.19 um 16:33 schrieb Julian Rickards:
> Not sure if this might be of interest.
> 
> When I see a composition that appears suitable for B&W, I switch my
> (Olympus E-M5) camera to Monochrome mode and when I import the image, I
> tag it "B&W". In Lighttable mode, the image shows up as B&W because of
> the embedded image in the RAW file but as soon as I load it into
> Darkroom mode, the image is shown in colour. It would be nice for me to
> be able to tag an image with B&W and have a style or preset
> automatically applied based on the tag. There may be other uses too.
> 
> On Fri, Aug 2, 2019 at 10:15 AM  > wrote:
> 
> Hi,
> I've added some features to tagging module as hierarchical amd list
> views, and rename command (merged in 2.7).
> I've let the former suggestion window but it doesn't give more than
> the tags list ordered by usage.
> The improvements I can think about are :
> - suggestion view based on the tags already attached on selected
> images. Then, when you attach a tag, the view suggests the most
> commonly used in association with it.
> - add synonyms to tags (with the corresponding import / export)
> - mark a tag as private (not exported with images)
> - category or helper to classify the tags  mainly at the first level
> (hierarchical tags)
> 
> What are your thoughts ? Suggestions ?
> 
> If somebody could tell me I would like to know why the tags table is
> not in the library.db but alone in data.db.
> Then in tags table there are some unused fields. Is there any plan
> to make use of them ?
> 
> Thanks
> Philippe
> 
> ___
> 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] [BUG?] Fuji RAF Files are not cropped to nominal (EXIF) size

2019-04-14 Thread Sturm Flut
Hi,

Am 12.04.19 um 10:26 schrieb Christian:
> Understand. But there may be users who prefer a consistend size
> between ooc and processed images or when using several raw converters in
> parallel.
> 
> So I suggest an option in the export-pane :
> 
> [x] crop to original/nominal size


I guess the correct point in the pipeline would be the "crop" module,
which is what I'm using to solve this. I've simply created a default
preset which sets the aspect ratio to 3:2.

Using a style with an activated 3:2 crop as the output style would also
achieve the same.

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



Re: [darktable-dev] [BUG?] Fuji RAF Files are not cropped to nominal (EXIF) size

2019-04-14 Thread Sturm Flut
Hi,

probably because the image then no longer has the exact aspect ratio it
is supposed to have.

For example both the Nikon D750 and D7100 in-camera engines output
6000x4000 pixel JPEG files, which is exactly 3:2. But the additional
pixels at the edges bump the RAW data to 6032x4032 (D750) or 6036x4020
(D7100) pixels, which is not exactly 3:2 anymore - it would have to be
about 6033x4022 (D750) or 6036x4024 (D7100) pixels to be 3:2 again.

cheers,
Simon


Am 12.04.19 um 19:56 schrieb David Vincent-Jones:
> I would think that Fujifilm's rational is that the original raw edge
> pixels are really not to be valued and only are used for the 'final
> edge' calculation.
> 
> On 2019-04-12 1:26 a.m., Christian wrote:
>> Hi,
>> Understand. But there may be users who prefer a consistend size
>> between ooc and processed images or when using several raw converters in
>> parallel.
>>
>> So I suggest an option in the export-pane :
>>
>> [x] crop to original/nominal size
>>
>> logic: if image is larger than original size and not
>> has been cropped manually then crop to original size.
>>
>> Chris
>>
>>
>>
>>
>> Am 11.04.2019 um 20:28 schrieb Sturm Flut:
>>> Hi,
>>>
>>> many higher-end camera sensors have more pixels than advertised. These
>>> pixels are used to improve image processing around the edges of the
>>> image, but they can also be recovered and presented to the user. Which
>>> not all RAW converters and in-camera JPEG engines do.
>>>
>>> So these additional pixels actually exist, and darktable lets you use
>>> them.
>>>
>>> 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
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



Re: [darktable-dev] [BUG?] Fuji RAF Files are not cropped to nominal (EXIF) size

2019-04-11 Thread Sturm Flut
Hi,

many higher-end camera sensors have more pixels than advertised. These
pixels are used to improve image processing around the edges of the
image, but they can also be recovered and presented to the user. Which
not all RAW converters and in-camera JPEG engines do.

So these additional pixels actually exist, and darktable lets you use them.

cheers,
Simon


Am 11.04.19 um 19:48 schrieb Christian:
> Hi.
> Fuji X-Trans II Files do have a nominal size of 4896 x 3264 px.
> The ooc-JPGs do have exactly this size.
> 
> But after export from darktable the JPGs are a bit larger
> (eg. 4932 x 3296).
> 
> I tried also another converter (RFC EX 2.0). This generates JPGs with
> the original size.
> 
> So: Is this behaviour intended?
> 
> As workaround I created a preset for the crop module.
> 
> Chris
> 
> ___
> 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] OpenCL memory usage on integrated graphics

2019-03-08 Thread Sturm Flut
 1.2
>   printf() buffer size    4194304 (4MiB)
>   Built-in kernels   
> block_motion_estimate_intel;block_advanced_motion_estimate_check_intel;block_advanced_motion_estimate_bidirectional_check_intel;
>   Motion Estimation accelerator version (Intel)   2
>     Device-side AVC Motion Estimation version 1
>   Supports texture sampler use    Yes
>   Supports preemption No
>   Device Extensions   cl_khr_3d_image_writes
> cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_depth_images
> cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics
> cl_khr_icd cl_khr_image2d_from_buffer cl_khr_local_int32_base_atomics
> cl_khr_local_int32_extended_atomics cl_intel_subgroups
> cl_intel_required_subgroup_size cl_intel_subgroups_short cl_khr_spir
> cl_intel_accelerator cl_intel_media_block_io cl_intel_driver_diagnostics
> cl_intel_device_side_avc_motion_estimation cl_khr_priority_hints
> cl_khr_throttle_hints cl_khr_create_command_queue cl_khr_fp64
> cl_khr_subgroups cl_khr_il_program
> cl_intel_spirv_device_side_avc_motion_estimation
> cl_intel_spirv_media_block_io cl_intel_spirv_subgroups
> cl_khr_mipmap_image cl_khr_mipmap_image_writes cl_intel_planar_yuv
> cl_intel_packed_yuv cl_intel_motion_estimation
> cl_intel_advanced_motion_estimation cl_intel_va_api_media_sharing
> 
> NULL platform behavior
>   clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  Intel(R) OpenCL HD
> Graphics
>   clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   Success [INTEL]
>   clCreateContext(NULL, ...) [default]    Success [INTEL]
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT)  Success (1)
>     Platform Name Intel(R) OpenCL HD
> Graphics
>     Device Name   Intel(R) Gen9 HD
> Graphics NEO
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU)  No devices found in
> platform
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU)  Success (1)
>     Platform Name Intel(R) OpenCL HD
> Graphics
>     Device Name   Intel(R) Gen9 HD
> Graphics NEO
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR)  No devices
> found in platform
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM)  No devices found
> in platform
>   clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL)  Success (1)
>     Platform Name Intel(R) OpenCL HD
> Graphics
>     Device Name   Intel(R) Gen9 HD
> Graphics NEO
> 
> ICD loader properties
>   ICD loader Name OpenCL ICD Loader
>   ICD loader Vendor   OCL Icd free software
>   ICD loader Version  2.2.12
>   ICD loader Profile  OpenCL 2.2
> """
> 
> Best,
> Bjoern
> 
> Am Fr., 8. März 2019 um 13:12 Uhr schrieb Sturm Flut
> mailto:sturmf...@lieberbiber.de>>:
> 
> Hi,
> 
> Am 08.03.19 um 09:47 schrieb Björn Sozumschein:
> > However, as far as I undestand, although 512 MB VRAM is reported, the
> > integrated graphics may allocate more shared memory
> 
> Yes and No. On one hand it depends on the chip generation, operating
> system, driver and system configuration. Most of the current generation
> Intel GPUs have a hard limit at either 32 GB or half the amount of RAM
> installed in the system, whichever is lower (see [1]). On the other hand
> the operating system must have free RAM left when the GPU driver wants
> to allocate some more.
> 
> Could you maybe post the output of the clinfo command (Linux
> distributions have it in their repositories, Windows version here [2] at
> the bottom)? On my ASUS notebook with an Intel Graphics 620 and 16 GB of
> RAM it reports ~6 GB for "Global memory size" and 2 GB for "Max memory
> allocation" when the system is idle.
> 
> I see that most ThinkPad X1 Carbon with the Intel Graphics 520 seem to
> have shipped with 8 or 16 GB of RAM. Since the Intel OpenCL driver
> really seems to report slightly less than 512 MB in your case, there is
> probably a reason for that.
> 
> kind regards,
> Simon
> 
> 
> [1]
> 
> https://www.intel.com/content/www/us/en/support/articles/20962/graphics-drivers.html
> 
> [2] https://github.com/Oblomov/clinfo
> 
> ___
> 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] OpenCL memory usage on integrated graphics

2019-03-08 Thread Sturm Flut
Hi,

Am 08.03.19 um 09:47 schrieb Björn Sozumschein:
> However, as far as I undestand, although 512 MB VRAM is reported, the
> integrated graphics may allocate more shared memory

Yes and No. On one hand it depends on the chip generation, operating
system, driver and system configuration. Most of the current generation
Intel GPUs have a hard limit at either 32 GB or half the amount of RAM
installed in the system, whichever is lower (see [1]). On the other hand
the operating system must have free RAM left when the GPU driver wants
to allocate some more.

Could you maybe post the output of the clinfo command (Linux
distributions have it in their repositories, Windows version here [2] at
the bottom)? On my ASUS notebook with an Intel Graphics 620 and 16 GB of
RAM it reports ~6 GB for "Global memory size" and 2 GB for "Max memory
allocation" when the system is idle.

I see that most ThinkPad X1 Carbon with the Intel Graphics 520 seem to
have shipped with 8 or 16 GB of RAM. Since the Intel OpenCL driver
really seems to report slightly less than 512 MB in your case, there is
probably a reason for that.

kind regards,
Simon


[1]
https://www.intel.com/content/www/us/en/support/articles/20962/graphics-drivers.html

[2] https://github.com/Oblomov/clinfo
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



Re: [darktable-dev] OpenCL question

2019-03-08 Thread Sturm Flut
Hi,

are you sure your GPU has enough resources to handle a dual-monitor
setup plus the Darktable GUI plus OpenCL? It's a six years old device
which was usually shipped with just 2 GB of dedicated video RAM.

I used to run a dual-monitor setup with a GeForce GTX950 2GB and had
exactly the same problems. Running OpenCL or CUDA on NVIDIA cards comes
with a lot of overhead, some desktop environments (looking at KDE and
GNOME) also need a lot of graphics memory, and in the end 2 GB were
usually not enough.

regards,
Simon



Am 07.03.19 um 20:09 schrieb David Vincent-Jones:
> Sorry for the lack of appropriate material ... I hope this added info is
> what you are looking for:
> 
> Card is Nvidia GK107GLM (Quadro K1000M)
> 
> driver=nvidia ver:415.27
> 
> Operating system x86_64 Manjaro rolling release using Arch repos.
> 
> I am not sure if the intel driver is blacklisted  does it
> specifically need blacklisting?
> 
> David
___
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

2019-02-23 Thread Sturm Flut
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



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

2019-02-23 Thread Sturm Flut
Hi,

it does, as long as lensfun can find the lens in its database. I've been
using full-frame-only lenses on both my Nikon D750 (full-frame) and
D7100 (APS-C) for years.

(It's not the best idea, though, so I'm about to replace the D7100 with
a second full-frame body).

cheers,
Simon



Am 23.02.19 um 14:42 schrieb Florian W:
> Hi,
> I happen to use on my Canon 750D (APC-C) 2 lenses designed for full
> frame (Canon EF 50mm f/1.8 STM and Canon EF 28mm f/2.8 IS USM)
> I wondered if the lens correction module takes into account that the
> camera is full frame or APS-C to apply the proper correction ?
> 
> Can someone tell me ?
> Thanks
> 
> ___
> 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] Crop tool is awkward for my use case

2019-02-18 Thread Sturm Flut

Dear Robert,

Am 18.02.19 um 17:54 schrieb Robert Krawitz:


the comment holds some validity in this particular case since darktable
can't losslessly crop a JPEG file, but other tools can. If the original
poster ended up just cropping (and not rotating) most files, something
like cropgui[1] would actually yield better image quality.


Well, that's interesting to know.  Unfortunately, cropgui isn't quite
right either; it doesn't do rotation.



Yeah, lossless rotation is only possible in 90 degree steps with JPEGs. 
jpegtran (the tool working in the background of cropgui) exploits a 
special property of the JPEG compression scheme. This property makes it 
possible to discard parts of the image data without having to re-encode 
the rest. There are certain limitations to this trick (you can't cut at 
every pixel coordinate, but only at the bounds of slightly larger blocks).


But if all you have is a JPEG, you only want to cut it, and image 
quality is a concern, then jpegtran/cropgui would be a better option 
than most generic image editing tools.


cheers,
Simon

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



Re: [darktable-dev] WebP export → Couple issues

2018-12-16 Thread Sturm Flut
Hi,

Am 15.12.18 um 17:51 schrieb Timur Irikovich Davletshin:
> 1. Default settings (95%, lossy) provides rather mediocre results and
> IMO is unusable. Probably something higher should be used.

it looks like that module doesn't actually take care to set that default
internally and in the configuration file. If you select the WebP output
module for the first time, the slider is set to 95%, but the encoder
obviously uses a much lower value. If you change the quality setting
once, the correct value will be set from then on.

I think it's probably the same mistake as I made in the PNG module, see
https://redmine.darktable.org/projects/darktable/repository/revisions/860def4eab3b1fc5b838d27bcc2f43ab81e2f295/diff/data/darktableconfig.xml.in
.


> 2. Lossless settings should hide quality slider because it makes zero
> difference for the end image.

That sounds like a good point.

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



Re: [darktable-dev] Studying darktable source code, suggestions

2018-11-23 Thread Sturm Flut
Hi,

I usually come up with something I want to change (my first patch for
darktable added a "Compression Level" slider to the PNG output module)
and then work through the source code until I know everything I need to
get it done. This has been my general strategy for the last ~20 years,
and it has worked quite well for me.

cheers,
Simon



Am 19.11.2018 um 13:51 schrieb Germano Massullo:
> I am going to study darktable source code, in order to geto used to
> GLib/Gtk stack.
> Do you have any suggestion for me, of any kind? For example "start
> with this, then go through that, etc."
> I have read the book (not yet completed by its author) "The GLib/Gtk+
> development Platform" by Sébastien Wilmet, and then I have read some
> of GNOME development documentation, that I found to be too
> "reference", and "sterile".
> 
> Thank you
> ___
> 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] local contrast -> laplacian filter seems to be broken

2018-11-19 Thread Sturm Flut
Hi,

Am 17.11.18 um 11:51 schrieb Andreas Schneider:

> This happende in darkroom and in the export and if I turned off OpenCL it 
> works in darkroom.
> 
> It could also be a bug in the ROCm OpenCL implementation.

I think this might have happened with my Radeon RX570 on Linux too, so
it could actually be some AMD-OpenCL-specific bug. But I'm out of the
country at the moment and can't check it.

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



Re: [darktable-dev] Bug? TCA correction (lens module)

2018-11-14 Thread Sturm Flut
Hi,

I just had a look at the code and at least to me it looks like the two
TCA sliders are not updated after the lens model is set/changed. They
will always stay on 1.0, until the user changes them manually.

cheers,
Simon


Am 14.11.18 um 10:30 schrieb Christian:
> Hi,
> The TCA correction in the lens-correction module does not
> seem to work in all cases.
> 
> Often the correction from the lens-database is not applied,
> means I see no difference between switching the module on or off.
> 
> For testing I created a lens with extreme settings for
> TCA.
> 
> settings in lens module:
> 
> - Correct TCA only
> - TCA-red slider and TCA-green slider on 1..
> 
> Workaround:
> 
> When clicking the module "reset" button and re-choosing
> the camera and lens then the TCA was applied in my tests.
> 
> See also (de):
> https://www.fuji-x-forum.de/topic/36912-darktable-win-tca-korrektur/
> 
> Versions tested:
> Windows7 64-Bit, darktable 2.4.4,
> Ubuntu 64 bit, darktable 2.0.3.
> 
> Chris
> 
> 
> ___
> 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 recognition of Tamron 24-70 mm lens in lens correction module of darktable version 2.4.4

2018-11-05 Thread Sturm Flut
Hi,

libexiv2 is shipped as a part of Linux Mint and not part of darktable.
Debian still only ships version 0.26 in the "experimental" branch,
Ubuntu depends on Debian, and Linux Mint depends on Ubuntu. So you would
have to build and install exiv2 manually.

kind regards,
Simon



Am 05.11.2018 um 17:39 schrieb J. Kilchert:
> Hi,
> 
> I'm using darktable 2.4.4 in a Linux Mint distro.
> 
> achim@achim-N56VZ ~ $ dpkg-query -W darktable
> darktable    1:2.4.4-0pmjdebruijn1~xenial
> 
> Distributor ID:    LinuxMint
> Description:    Linux Mint 18.3 Sylvia
> Release:    18.3
> Codename:    sylvia
> 
> (In the lens correction module (EOS 6D Mk II is not listed as one of the
> camera models refer to my other post
> concerning camera model recognition) and
> 
> *darktable is not able to recognise the ~/.exiv2 file*, which would fix
> the problem of duplicate lens IDs
> and enable reading out the proper lens data from the exif section of the
> image.
> 
> *This would require darktable to use **Exiv2 v0.26*
> 
> /*How can I get *//Exiv2 v0.26 into my * *//*darktable 2.4.4
> installation?*/
> 
> 
> Best regards
> 
> Joachim Kilchert
> 
> 
> 
> Joachim Kilchert
> 
> Spitalstr. 9
> 88677 Markdorf
> 
> 
> ___
> 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] noise

2018-11-05 Thread Sturm Flut
Hi,

ignoring that this is one of the cases where not setting the camera to
"Auto" would have resulted in a much better picture and avoided most of
the issue to begin with:

Profiled Denoise in Wavelet mode with strength 0.2 already looks pretty
identical to what DPP does, at least to me. XMP is attached.

The output from RawTherapee looks oversharpened. Maybe that's your
issues with Dartktable as well? If there's noise in the picture it is
usually better to fine-tune using the Equalizer instead, and/or use
masks to sharpen areas selectively.

kind regards,
Simon

Am 03.11.18 um 17:58 schrieb Andrey L:
> Hello, guys. Canon DPP makes me crazy, but DT is unable to compete with
> neither Canon DPP, nor RawTherapee :(
> Could you please pay some attention to DarkTable's noise removal
> opportunities? 
> I have to spend senconds with Canon DPP to suppress noise on high-iso
> image, 
> I need minutes to get a good result in RawThrerapee, but nobody can
> spend hours
> to make bad result with tons of noise reduction tools. Please, break the
> last barrier to DT :`|
> Here my example:
> original image:
> https://drive.google.com/open?id=0Bz9fwFLCJOjNMnJlTzgwcHZOdTA
> canon dpp:
> https://drive.google.com/open?id=0Bz9fwFLCJOjNc1RoWW9kN3d3V0k
> rawtherapee:
> https://drive.google.com/open?id=0Bz9fwFLCJOjNNnZWNjVSYXhaX28
> 
> The best efforts In general lead to green noise on barbells. It's too
> complex problem for regular photographer.
> 
> ___
> 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

 http://www.w3.org/1999/02/22-rdf-syntax-ns#";>
  http://ns.adobe.com/xap/1.0/";
xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/";
xmlns:darktable="http://darktable.sf.net/";
   xmp:Rating="1"
   xmpMM:DerivedFrom="IMG_1084.CR2"
   darktable:xmp_version="2"
   darktable:raw_params="0"
   darktable:auto_presets_applied="1"
   darktable:history_end="32">
   

   
   

   
   

   
   

   
   

   
   

   
   

   
   

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

   
  
 



Re: [darktable-dev] Darktable lag on a 4K monitor.

2018-11-02 Thread Sturm Flut
Hi Andreas,

Am 02.11.18 um 13:23 schrieb Andreas Schneider:
> On Friday, 2 November 2018 12:58:52 CET Sturm Flut wrote:
>> Dear list,
>>
>> I guess this can also depend a lot on the hardware and the specific
>> X.Org/Mesa/GTK/driver version combinations. I've been using darktable on
>> a 4K display with Arch Linux running on a Ryzen 1600X for one and a half
>> years and there haven't been any noticeable lags, neither with the old
>> NVIDIA GTX950 nor the new AMD RX570 GPU.
> 
> There definitely is, I'm running on openSUSE Tumbleweed, which is likely the 
> same as you're running. And yes there is an event storm going on if you move 
> the mouse.

I don't doubt that you experience lags and that there is an event storm
going on :)

I just wanted to add the data point that at least on my specific setup I
never really felt impaired by UI lags, at least not to the point where I
suspected that something might be wrong. Would be nice to know why.

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



Re: [darktable-dev] Compile error: rawspeed/src/librawspeed/common/Common.h:87:1: error: body of ‘constexpr’ function

2018-11-02 Thread Sturm Flut
Hi,

Am 31.10.18 um 16:50 schrieb Postmaster:

> Its not so easy to make this work. cmake seems to be an issue.

>From what I've been seeing in a couple of mails now, it feels like you
might be running into issues which seem to be more specific to RHEL and
Fedora than to darktable and the general GNU/Linux ecosystem. CMake is a
build system, the error message in your last e-mail is a compiler error
in librawspeed and has little to do with CMake or even darktable at first.

Especially Fedora 28 has a lot of bleeding-edge stuff and seems to do
some things differently than everyone else, which has already caused
compilation failures for multiple projects in the past (see e.g.
https://www.mail-archive.com/darktable-dev@lists.darktable.org/msg03229.html).
There don't seem to be too many developers and users around who use
Fedora on a regular basis, so someone might know how to build the
packages, but darktable's own documentation might lack behind.

It might be easier to try to build darktable on one of the "more common"
and "better supported" distributions, especially if you've never done it
before.

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



Re: [darktable-dev] Darktable lag on a 4K monitor.

2018-11-02 Thread Sturm Flut
Dear list,

I guess this can also depend a lot on the hardware and the specific
X.Org/Mesa/GTK/driver version combinations. I've been using darktable on
a 4K display with Arch Linux running on a Ryzen 1600X for one and a half
years and there haven't been any noticeable lags, neither with the old
NVIDIA GTX950 nor the new AMD RX570 GPU.

kind regards,
Simon




Am 02.11.18 um 05:05 schrieb August Schwerdfeger:
> Darktable 2.4.3 and .4, MacOS and Fedora.
> 
> When using Darktable on a 4K monitor, I am experiencing a UI lag that
> seems dependent on the size of the application window.
> 
> For example, when I size the window with dimensions that are half those
> of the screen, the image highlight in the light table follows my mouse
> pointer with no noticeable lag. Resizing to three-quarters of the screen
> dimensions introduces a delay of about half a second between the time
> the pointer moves and the time the highlight changes. Resizing to full
> screen increases this lag to about a second.
> 
> Does anyone know what is causing this?
> 
> --
> August Schwerdfeger
> aug...@schwerdfeger.name 
> 
> ___
> 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