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.
That really shouldn’t happen. In German we use
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:
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.
- variables: More recursion and -escaping
- Add option to ask before removing empty dirs
- Add taskbar progressbar
- local laplacian: make roi aware in darkroom mode
- 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
- 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 profile: Add Fujifilm X-PRO1, fixes #11769
- noise profile: Add Olympus Pen E-P5, fixes #11748
- noise profile: Add Panasonic DMC-FZ200, fixes #11755
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!
First of all, huge thank you to developers. I use both Linux and Windows and I am really pleased to see Darktable running so well on Windows as well. It is fast and stable.
At the moment, I noticed only one problem with Windows version. TIFF 16 bit uncompressed export takes forever. For example, exporting processed Fuji X-T2 image (parametric masks, equalizer, local contrast etc.) to JPEG takes about 19 sec., however, exporting same image to TIFF takes about 3 minutes and 45 seconds . On Linux it takes about 6 seconds…
Similar situation is with other RAW files as well. Exporting processed 12 Mpix NEF image to JPEG takes about 3 seconds, but to TIFF about a minute.
It is not critical issue, since most of the time I export to JPEG, but I was curious, if anyone else has encountered the same problem.
My hardware: Ryzen 1700 @3,7 GHz, 32 GB RAM, GeForce 1070.
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.
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.
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
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°
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
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.
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:
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