Re: [darktable-dev] Re: enable DMARC to avoid messages being classified as spam
On 2024-04-03 15:39, Jørn Villesen Christensen wrote: Hi there, Looking at the header of the mail I receive from this list, I *think* there is something that could be done to help gmail. The header states: Authentication-Results: mx3.***.dk; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=web.de (policy=quarantine); spf=pass (mx3.***.dk: domain ofSRS0=nkjO=LI=lists.darktable.org=darktable-...@ml.darktable.org designates 195.201.91.78 as permitted sender)smtp.mailfrom=SRS0=nkjO=LI=lists.darktable.org=darktable-...@ml.darktable.org So while it seems that there is a valid spf record, somehow it is also marked not aligned. The whole DMARC etc. business does not seem to be a good match for mailing list traffic. Unfortunately Gmail (unlike some other services) doesn't seem to mind this… -- Šarūnas Burdulis math.dartmouth.edu/~sarunas · https://useplaintext.email · OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] OpenCL failure on AMD kernel 6.6,x
On 1/8/24 14:21, Germano Massullo wrote: Il 21/12/23 21:01, Šarūnas ha scritto: Debian unstable, kernel 6.6 from experimental, Which kernel version are you using? 6.6 is a too broad definition I don't have that setup anymore, but the kernel must have been $ uname -a Linux molly 6.6.9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.9-1 (2024-01-01) x86_64 GNU/Linux except it was 6.6.8. -- Šarūnas Burdulis math.dartmouth.edu/~sarunas · https://useplaintext.email · OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] OpenCL failure on AMD kernel 6.6,x
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). -- Šarūnas Burdulis math.dartmouth.edu/~sarunas · https://useplaintext.email · OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] Plan for darktable 4.4
On 16/05/2023 14.41, Mica Semrick wrote: Thanks Pascal! As per ususal, we could really use help with the docs. If you've ever said "I can't code, how can I help the project?" This your chance! Is there perhaps a wishlist of what needs to be (better) documented? -- Šarūnas Burdulis math.dartmouth.edu/~sarunas · https://useplaintext.email · OpenPGP_signature Description: OpenPGP digital signature
Re: [darktable-dev] News about darktable 3.6
Such a waste of time and effort. Make `darktable` a symlink to `darktable-cli`. Done. -- Šarūnas Burdulis math.dartmouth.edu/~sarunas · https://useplaintext.email · OpenPGP_signature Description: OpenPGP digital signature
Re: [darktable-dev] idea to consider
On 8/30/20 7:08 PM, Aurélien Pierre wrote: > 1. that still doesn't give you the jpeg cooking recipe, which is more > complicated than building an ad-hoc LUT or a tonecurve if local filters > are applied (and there are), > > 2. what is it with people editing jpegs ? That's nonsensical ! Not the > same workflow, not the same maths, not the same filters, not the same > pipeline, not the same software. A raw is an output-agnostic linearly > encoded master picture that you can still salvage from the beginning, a > jpeg is already non-linearly cooked for display assuming dim viewing > conditions (as per sRGB standard) and firmware blackboxes. > > People need to stop dealing with image processing as if everyone was > right and correctness didn't matter. It's not a silly magic game of > pixels values, there are assumptions to assert underneath the hood. > Sometimes I wish image processing could kill people, as civil > engineering or medicine do, so people would start taking it seriously > and check the theory behind before doing shit carelessly. That kind of > silly workflow will blow up in your face 50 % of times because there is > zero reliability in handling pre-baked jpegs with all the firmwares > discrepancies in a software designed to unroll image operations on raw > files. Then I will let you deal with users who don't understand why the > workflow is so unpredictable. > > Indulging bad habits of users is not a solution, especially since we > don't sell anything/whore ourselves out. Let's be rigorous about pixels > operations and do things properly. Want to edit jpegs ? Use bloody > Photoshop and the likes. They are good at doing shit, don't care about > color consistency, don't care about light emissions, don't even do > associated alpha occlusion properly. Yet people love them because > marketing expenses make up for dev mediocrity and overall stupidity. Amen. -- Šarūnas Burdulis math.dartmouth.edu/~sarunas · https://useplaintext.email · signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] Local Contrast Module broken using OpenCL
On 8/15/20 7:21 AM, Dusenberg wrote: > Thanks for your time Šarūnas and Germano. > > This has got me worried because my workstation has the OpenCL from the > AMDGPU-PRO version installed (but nothing else from it) and I'm using > the open source amdgpu driver package. My reading of the bug analyses > done by the devs > (https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/issues/103), > is that 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? Is it possible I'm somehow using the open source > OpenCL instead of the PRO? The output from darktable and inxi are below > - do the experts know ifthis proves what I'm running? > > darktable -d opencl: > [opencl_init] device 0: gfx1012 > GLOBAL_MEM_SIZE: 8176MB > MAX_WORK_GROUP_SIZE: 256 > MAX_WORK_ITEM_DIMENSIONS: 3 > MAX_WORK_ITEM_SIZES: [ 1024 1024 1024 ] > DRIVER_VERSION: 3075.10 (PAL,LC) > DEVICE_VERSION: OpenCL 2.0 AMD-APP (3075.10) This looks like OpenCL from AMDGPU-PRO. -- Šarūnas Burdulis math.dartmouth.edu/~sarunas · https://useplaintext.email · signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] Local Contrast Module broken using OpenCL
On 8/14/20 2:37 PM, Dusenberg wrote: > Thanks for the prompt reply Andreas. > What a pain, I use local laplacian a lot. The github threads say the > AMDGPU-PRO drivers don't have this problem, so I'm wondering if I should > replace the open source amdgpu driver with the PRO version as a > workaround for the time being. Do you know if this is a realistic option > for a non-dev user? If this is a problem with the open source ROCm OpenCL library, you can run open source amdgpu (present in Linux kernel) with OpenCL from AMDGPU-PRO. Here is for Ubuntu, but might be adaptable to others: https://math.dartmouth.edu/~sarunas/amdgpu.html -- Šarūnas Burdulis math.dartmouth.edu/~sarunas · https://useplaintext.email · signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] Submit darktable 3.01 for Ubuntu 20.04 (ASAP)
On 4/14/20 4:36 AM, layingback wrote: > Just to follow up, one Timo Aaltonen of Debian volunteered to do the heavy > lifting, and as of 13 hours ago, darktable 3.0.1 was queued for inclusion in > Ubuntu 20.04 Focal Fossa. And this morning it is installing as an automatic > update to my 20.04 daily beta test system! > > Details from my bug report closing below - note that this version now built > into > the upcoming Ubuntu LTS release is from github 2 weeks after the 3.0.1 > release: That's great news. Thanks! Does 3.0.1-0ubuntu1 include iop_order patch allowing to keep legacy module order for images processed in 2.6.x? Šarūnas math.dartmouth.edu/~sarunas ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] DT bad on skin tones?
On 5/25/19 3:11 PM, Christian wrote: > Hi, I re-did the test with the Fuji X-E2 version of the test-chart > shoot and the skin colors are much better. This interest me to, however it is not obvious, what you [re-]did to get better colors. Care to elaborate? Thanks! Šarūnas math.dartmouth.edu/~sarunas ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Testing darktable isolated from production
On 5/2/19 7:00 AM, dt-l...@stefan-klinger.de wrote: > Hi, > > for testing I'd like to run DT without installing it, and without > interfering with my setup and foto collection. Installing to an > alternative destination would be ok, but I'd rather just recompile and > run it. Host's X11 and GPU (AMD and Nvidia) can be used from docker container. I don't have pointers at the moment. -- Šarūnas Burdulis math.dartmouth.edu/~sarunas signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] where to discuss big changes
On 4/16/19 11:46 PM, Moritz Moeller wrote: > There is this thing called 'a news server' which has all of below > but has infinite history (for free) and you can actually see who > replied to whom before even opening/deciding to read a message. > > That feature alone makes a news server with a decent client (e.g. > Thunderbird) a thousand times superior to something like e.g. Slack. > > And this stuff has been available since the 70's. For free. Maybe I'm > just getting old. Just my two c. +2¢ for NNTP. Good old clean tech. -- Šarūnas Burdulis math.dartmouth.edu/~sarunas signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] Crop tool is awkward for my use case
On 2/18/19 8:19 PM, Robert Krawitz wrote: > Thanks -- and you see why I harp on this; I need to squeeze everything > I can out of the workflow. Over the past few years, I've put a lot of > work into performance tuning KPhotoAlbum to squeeze time out of image > loading and that, and anything that adds a few seconds per image is a > real problem for me. Hmm... what's all the rush? :) Šarūnas ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Showing exposure bias
Hi, developers, I have always missed seeing exposure bias value in darktable. Does anyone else think it would be good to have that shown in 'image information' on the left? Perhaps there is also a nifty way of indicating exp. bias somehow in histogram? By mimicking source code for exposure, I was able to get exp. bias from exif and then output among other metadata in 'image information': https://gist.github.com/sarunasb/f5eb4644dbf3e07174069c46f668e89b Of course this only lasts until images are loaded for the second time, as there is no exp. bias in database, if I'm correct. At the moment I'm not too familiar with darktable's code for database operations. It looks like common/database.c has schema upgrades, but then there are multiple instances in the code, where schema has to known in order to be used explicitly for inserts, for example. I have the code for displaying exposure bias in a fork on Github (https://github.com/sarunasb/darktable) and can make a pull request, if there is any interest for it. If this is seen as a feature worth adding, would someone familiar with database ops be willing to pick up? I can try looking at it myself too, but at the moment I don't even know what I don't know, so to say... -- Šarūnas Burdulis math.dartmouth.edu/~sarunas signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] Sony a7iii
On 04/30/2018 09:19 PM, Bob Tregilus wrote: > On Mon, 2018-04-30 at 08:47 -0700, Barton Hewett wrote: > > Hi, just got a new Sony a7iii and get this message when trying to > > develop picture shot on camera. I'm guessing this is because camera > > is > > so new and not in database yet? > > Yes, it appears there are no samples in the database, hence it would not > be supported in DT, yet. > > I recommend that you contribute ILCE-7M3 RAW samples per the > instructions at this link <https://raw.pixls.us/>. > > Hope that helps! Congratulations with a good camera. In addition to pixls.us, you may want to do some of this, in particular — “Black and White levels” and “White balance presets”: darktable.org/2012/10/whats-involved-with-adding-support-for-new-cameras -- Šarūnas Burdulis math.dartmouth.edu/~sarunas signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] Panasonic GX80/85
On 12/09/2016 07:08 AM, PD Dr. Stefan Schmidt wrote: > Hi, > > although the panasonic GX80/85 was included in 2.0.7 I cannot find a > noise profile. Also the camera is not on the list in the lens correction > module. Have just made a pull request on lensfun GitHub to add DMC-GX80 and DMC-GX85. -- Šarūnas Burdulis http://math.dartmouth.edu/~sarunas signature.asc Description: OpenPGP digital signature
Re: [darktable-dev] Feature request: camera model in export module
On 11/20/2015 04:33 PM, Pedro Côrte-Real wrote: > On Fri, Nov 20, 2015 at 8:54 PM, Šarūnas Burdulis > <saru...@mail.saabnet.com> wrote: >> would someone care to take a look at the attached patch? It ads >> $(EXIF_MODEL) to recognized variables in the export to files on disk >> file naming field. I used darktable-org/darktable master branch to start >> with. > > Is exif_model actually what you want? Here's what's in the img struct: > > exif_make: the camera make exactly as reported in EXIF (cameras from > the same manufacturer will have slightly different values) > exif_model: the model exactly as reported in EXIF (often the maker is > also in the model) > camera_make: the camera make cleaned up (no needlessly long names, all > cameras will report the same) > camera_model: the camera model cleaned up (no needlessly long names, > if there are aliases the base name is used so "EOS REBEL SL1" becomes > "EOS 100D") > camera_alias: same as before but the alias is used (so "EOS REBEL SL1" > stays that way) > [...] I just made a pull request on GitHub to add MAKER and MODEL using img->camera_maker and img->camera_model. It's a minor patch. Thanks for considering it. -- Šarūnas Burdulis http://math.dartmouth.edu/~sarunas ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Feature request: camera model in export module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2015 05:29 PM, Šarūnas Burdulis wrote: > On 11/20/2015 04:33 PM, Pedro Côrte-Real wrote: >> On Fri, Nov 20, 2015 at 8:54 PM, Šarūnas Burdulis >> <saru...@mail.saabnet.com> wrote: >>> would someone care to take a look at the attached patch? It ads >>> $(EXIF_MODEL) to recognized variables in the export to files on disk >>> file naming field. I used darktable-org/darktable master branch to start >>> with. > >> Is exif_model actually what you want? Here's what's in the img struct: > >> exif_make: the camera make exactly as reported in EXIF (cameras from >> the same manufacturer will have slightly different values) >> exif_model: the model exactly as reported in EXIF (often the maker is >> also in the model) >> camera_make: the camera make cleaned up (no needlessly long names, all >> cameras will report the same) >> camera_model: the camera model cleaned up (no needlessly long names, >> if there are aliases the base name is used so "EOS REBEL SL1" becomes >> "EOS 100D") >> camera_alias: same as before but the alias is used (so "EOS REBEL SL1" >> stays that way) > >> Depending on what you want to do some are better than others. I >> suspect camera_make and camera_alias are actually better for most >> purposes and is what we show in the interface. > > Pedro, thanks for a quick reply. > > Frankly, I didn't even think about what else might be available in img > struct. So yes, let's use whichever element looks best for showing the > camera model in most of the cases (I only tested with files from Olympus > E-M5 and Moto X cameraphone). > > Is the patch itself OK, i.e. is it the way this option should be added? > Do you want me to resend a patch with 'camera_make'? Sorry, I meant 'camera_model'. Šarūnas -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlZPnzMACgkQVVkpJ1MUn+b/uQCdGNRbFw58yZPyj/K5ORMZ2g3G K4UAnjJp1O7iA2ITrkMJCFGKi7HoPkS7 =KkxM -END PGP SIGNATURE- ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
