I think I remember something similar being reported a while ago. I thought we fixed it. Could you please take a screenshot and upload it here?
It’s strange that you can’t reproduce. I got the bug as I had a French default windows setting AND DT language : French
If you loose one of these two conditions either Windows, either DT language, the bug disappears.
To be able to test both the french DT and the english one, I tried to install DT twice, one in French and one in English in two separate folders at the root of my C harddisk. And also two separate folders for the pictures… This did no work. Went back with one installation with the two folders. I got mixed results, as soon as I open the picture with Dt in French, I do also have the bug as I open the other folder with DT set to English… So the parameters of the picture are not only written to the xmp sidecar file but also within DT
I am finally left to DT in English.
No I don’t have a compile environment. I am not an IT guy only a non professional photographer…
What happens when you import the image in an English darktable (so everything is correct), close darktable and open it in French? Where does the map put your image? The right place?
At the right place.
So it seems to be indeed the reading of the file and not the subsequent display on the map.
I’ll try to make a debug build tomorrow, maybe that will tell us what’s going on.
Please install this new snapshot installer. Ontop of the sources in git I also added some debug prints when importing images with GPS coordinates.
PGP signature: https://pixls.us/files/darktable-2.3.0%2B1049~g909d17612-dirty-win64.exe.asc
Changes since the last build:
- Put libtiff errors to stderr, not popups
- Show images in subfolders in collect’s folder mode
- Properly sort folders for tree view in collect
- Fix #11809: Restore mask channel in haze removal
- opencl: fix bug #11802
- A few issues with print mode
If I remember it correctly, Windows has f-i-v-e different major FR settings (Belgium, Canada, France, Luxembourg, Switzerland) plus e-i-g-h-t minor ones (Cameroon, Congo, Côte d’Ivoire, Mali, Monaco, Morocco, Senegal, West Indies), i.e. 13 different settings for one parameter or more.
Would DT recognize them all or could this be the reason for the non-correct interpretation?
@csierra02: exactly which FR setting do you use?
Claes in Lund, Sweden
@Claes I suppose there will always be regional differences. We just need to be aware of language conventions that actually interfere with the programming efforts of our dear (grumpy) devs.
Yes - but some of those 13 FR varieties do differ in the way they expect dates to be formatted and what decimal separator to expect…
I learnt it the hard way when writing bespoke software for an International group of companies
That is why I used the vague term conventions. Look no further than conventions within a country. Even then, people can’t decide how to format their date and time.
ok. this evening
-------- Message d’origine --------
hi houz… quite busy today and the two coming days. Will handle on saturday
Cool, mask working now with haze removal
Steps to reproduce the error:
- Create a SVG watermark using inkscape, using an image (trace bitmap) and then added text
- Save the SVG file into the darktable watermark folder
- Use the SVG file as the watermark in Darktable 2.3.0+941~g3fe3c2749 (watermark doesn’t render properly, the text comes out as a solid rectangle)
- Export the image using Darktable (solid rectangle is carried over onto the exported image)
Select text box in Inkscape and convert to path, menu Path → Object to Path
This solution worked! I believe your suggestion is a more straightforward way of doing things as opposed to the work-around I used which was to insert the text as an image; group both images; then flatten transparencies. Thank you, Sergei.
Conclusion: it was not Darktable’s fault, but a step I didn’t know about (and obviously missed) when using Inkscape. Now… going back to my next batch of exports!
If I run an program from an Lua script it opens a terminal window and the program itself. I don’t think that is intended. Here is an example script:
local dt = require "darktable"
local df = require "lib/dtutils.file"
local function show_status(storage, image, format, filename,
number, total, high_quality, extra_data)
dt.print(string.format("Export Image %i/%i", number, total))
local function notepad(storage, image_table, extra_data) --finalize
dt.register_storage("module_notepad", "Open Notepad", show_status, notepad)
I’m very happy to hear!
I installed several times Linux but always had some issues and actually I’m quiet happy with Win10… So I looked for a lot alternatives to darktable, but to me it’s the best software (maybe besides the Adobe… but never tested).
Overall it works pretty fine and stable, but I found some issues:
When I have edit a picture I can’t see high quality previews (by pressing z or lighttable with only 1 picture, not edited pictures look great) I already found the configuration (plugins/lighttable/low_quality_thumbnails=TRUE) but when I change it to FALSE, the file will change back immediately to TRUE after opening darktable…
I can’t find the print module, I only have lighttable, darktable, diashow, map and tethering…
Is there any way to scroll by mouse through the lighttable? (PageUp/Down I know…)
With the previous version I had sometimes pictures with artefacts on int the lighttable preview and also on exported pictures (part of the image is repeated several times in the top of the picture…), but I can’t reproduce this now… (probably solved?!)
And is there any way to slow down the export? Since I have a small Convertible, which gets pretty hot on exporting several pictures… I have tried with and without open CL, but can’t notice any difference, neither in speed nor in temperature…
My system: Win10@64 bit, i5-7200, Intel HD Graphics 620, 8GB RAM, SSD
It’s not intended, but I don’t see a way to fix it. It seems that Lua itself is quite broken on Windows. So unless we want to fork it we have to deal with all the bugs it has.