That really shouldn’t happen. In German we use , as the decimal separator, too. I’d like to get this fixed properly but I don’t know how to reproduce the error. 
So, after a long time there is a new snapshot installer!
-
The installer:(please use the link from the 1st post instead) - The gpg signature: https://pixls.us/files/darktable-2.3.0%2B1021~ga917e5ecc-win64.exe.asc
- sha256sum of the installer:
b9115180ba26a275489e402639990116d97d092b98b31e69bfd08119a86b8009
As we are in feature freeze rigth now for the upcoming 2.4.0 release we are interested to learn about as many bugs as possible! So please, update and test.
Changes
New features
- variables: More recursion and -escaping
- Add option to ask before removing empty dirs
- Add taskbar progressbar
- local laplacian: make roi aware in darkroom mode
Bugfixes
- bauhaus: Don’t grab focus when hovering with mouse
- print: properly restore export intent
- Update style lists when importing a style
- Fix multi instance in styles applied during export
- masks: fix undo for clone masks
- Faster startup with really big libraries
- borders: fix frame size for the larger borders.
- Checking for empty mask list before trying to write out to db. Fixes #11758
- Fix a crash from spot’s legacy_params
- fix linear equations solver for color checker module
- Add GPSVersionID to Xmp
Updated translations
- Dutch
- French
- Hebrew
- Italian
- Spanish
Camera support
- Olympus E-M10 Mark III: color matrix + rawspeed support.
- Panasonic DC-TZ90: add basic camera support, fixes #11747
- Add WB presets for Fujifilm X100F (#1541)
Noise profiles
- noise profile: Add Fujifilm X-PRO1, fixes #11769
- noise profile: Add Olympus Pen E-P5, fixes #11748
- noise profile: Add Panasonic DMC-FZ200, fixes #11755
3 Likes
If your decimal separator right now is the comma and you don’t have the error, I am puzzled.
I am unable to export images after the update. The error message in german is “Konnte Verzeichnis C:UserMyNameDesktopBetreffenderOrdner nicht erstellen”. It seems that the program does not recognize the slashes in the file path anymore? The slashes are still there in the option menu.
The slashes are wrong, use other slash and will be work 
Damn didn’t even notice that. Thanks!
Hi Dainis, this is exactly the question I was going to ask, about length of time taken to save uncompressed TIFF. I am on a older HP Pavilion 23 with AMD A6 and 8GB of ram and it takes roughly 5 minutes 30 seconds to save a TIFF created from a Fuji X100S RAF raw file. I am going to install Linux for a dual boot and see what the difference is there.
Cheers
Jason
I do have problems with exporting a jpg file to a folder on the desktop with latest release 2.3.0+1021.
When exporting to a folder on the desktop darktable says can’t export,
when exporting to a folder on another drive (D) no problem.
The message: cannot export to CUsersGerDesktoptest,
you see, no slash between different folders (C://Users/Ger/Desktop/Test)
Edit now I see an earlier reply. I’ve to change slashes. Why doesn’t DT do this correct when selecting?
Disregard what I wrote, now It happens for me, too. I will investigate. Thanks for reporting.
Because it’s a bug I didn’t think of as I never use the file selector in the export dialog. I’ll fix it.
thx’s!!!
you are welcome 
And now I am no longer sure that anything is off at all. Let’s start over and make sure that we are on the same page. I tried with your XMP containing the location
exif:GPSLatitude="42,25.407257N"
exif:GPSLongitude="73,44.414062W"
That results in a place about 10km west of a town called Valatie in darktable. Looking at the place in Google maps i get the same:
So to me everything looks right. What is the place you expect to see on the map?
Maybe the confusion is caused by different formatting of the coordinates?
We can either express it in degrees and minutes as it’s the case in the XMP file:
N 42° 25.407257' W 73° 44.414062'
Or we use degrees, minutes and seconds:
N 42° 25' 24.43542" W 73° 44' 24.84372"
Or one can just use degrees:
N 42.423454283333° W 73.740234366667°Hi houz,
You still do have the problem… I got this location too before I changed my
windows separator to dot.
And at that point, the issue seemed to be a W / E issue… Cap Verde Islands
becoming South of Egypt…
and Lisbon south of Corsica… The change on the american picture is less
obvious a shift of 2° North and longitude
almost correct…
The location is did put in LR or the jpg picture and that I do have right
now in DT is
N 40° 44’ 5" (LR) and 40° 44;086’ (DT)
W 74° 10’ 21" (LR) and 40° 10.349’ (DT)
My LR uses DD° MM’ SS"" format while DT uses DD° MM.MMM ’ but the two
cordinates agree within 1 "
In Google Maps, this is the center of the city of Newark (US) about 16 km
west of the end of Manhattan.
We are now talking about two different test files. The XMP you linked and that I cited is definitely NOT wrong in dt, the place outside of Valatie is correct – a shift of less than 1" is irrelevant and due to rounding.
The JPG from Newark is put into the right place, too, both on Linux as well as on Windows. With , as the decimal separator. Could you please double check that the JPG is removed from darktable, close darktable, delete its accompanying XMP file and then open it in darktable again. Select the file, go to map view and double click the image in the filmstrip. Do you still see it in the wrong location?
Also please download the JPG from this thread and don’t use your local original.
Hi houz,
I do not quite understand your logic. There is only ONE correct place for this picture. It is Newark, the place where it was shot and the coordinates that were put by Lightroom. 40° N. Valatie makes no sense for the picture… and Valatie is 2° North of Newark… 42°N
So the goal is to have this picture be placed at 40°N by dt.
I understand your recommendations. to be complete I should also revert to the comma as decimal point separator right ?
So I would be in the same conditions as you.
And finally find Valatie as the “correct” place for the picture ? I would say that is just to reproduce the error.
Also the xmp file is not “mine”… the JPG file has no accompanying xmp file when shot and even when processed by Lightroom. LR writes the GPS coordinates in the JPG… This is unlike dt
The xmp file you indicate is created by dark table. I did not upload any xmp, only screenshots of the exif and dt maps and finally the jpg file itself. It is the xmp file your dt created as you opened the jpeg
That XMP was shared by you and it contains coordinates next to Valatie. The JPEG from the same post is read fine in dt for me with coordinates in Newark. So far I couldn’t reproduce any errors. All tests were with , as the decimal separator.
So if the XMP you shared there wasn’t written by Lr but is the auto generated file from dt let’s ignore it from now on and just discuss the JPG. What place does it get put on when running dt with an English GUI and the Windows settings left at the French defaults (,)? You can try it by adding this to your command line arguments:
--conf ui_last/gui_language=C
I’ll be afk for the rest of the week so it might take a while for me to answer.
Sorry, you are correct, I shared the xmp and it is the one generated by dt.
I went though the two changes you asked and yes, with an english langage of dt and comma separator for Windows, there is no mistake. So the mistake comes from the fench version of dt… and can somehow be “corrected” by changing the defaults number settings of Windows
I was so happy to have tried to recently do my first export using DT for Win! Unfortunately, I noticed that only a portion of the primary watermark I use was exported together with my photos. I use a SVG file that has both an image and text. The text portion doesn’t get fully included in the exported image. Has anyone experienced this, too?
So far I’ve tried re-inkscaping (no expert here) the SVG file and used different fonts for the text, but that only creates either a filled black box or have the text too spaced out on where the text is supposed to be 
Any helpful ideas (or theories) appreciated, thanks!
Win_10 Intel_i5 8GB_RAM