I think in your case it could be the smartscreen Filter (same for me) which blocks applications that do not have any reputation because they are new. Sure it is defender? If it’s the smartscreenfilter the problem should disappear in the next couple of days (and reappear with the next RC)
1 Like
Thanks for all contributing to the great project and giving the opportunity to get early access to the release.
Not sure if it is the right place to post a crash report. (Win10 RC)
The crash happens while using the drawn¶metric mask with the contrast-brightness-saturation module.
The masking works out but going further the crash happens. The crash report ist attached
regards SF
darktable_bt_Q5Y7A0.txt (10.7 KB)
Just downloaded 3.0.0rc0 and compiled it on my openSuSE Leap 15.1 system. Worked like a charm and runs like a charm. Great work. Congratulations and big thanks to all developers. Darktable is the most powerful RAW software available in the linux universe.
Only noticed a little bug I will report on github.
I think a description of the changes to how the history stack is displayed should also be included and circulated …when users have 8 to 10 modules still hanging around after compressing and then the order of them can change depending on which one you select in that group before you hit compress…in that first group of 8-10…I think there will be a million questions from users esp given this behaviour is now combined with the ability to change processing order of the modules…
I don’t think that any of the released version has been signed. So they would be the same way blocked by Defender, and you should enable the explicit install.
Export to Google Photo just opens the browser and ask for verification code, is this module working? if Yes how to proceed further?
This functionality is very important to me so please help.
I am on OSX Catalina.
Thanks
You need the verification code from your google account. Find it and enter it when the browser pops up.
I know I sound like a broken record, but wow Darktable 3.0! It is truly fast and responsive like never before. The reason for posting basically the same message as I did in this thread once (or twice) already, is that I have recently replaced my Nikon D600 with a second-hand D810 and I must admit I was a bit worried about processing the 36 Mp files from the new Nikon.
But in reality, this is now so fast that I don’t see any difference at all working with these files compared to the Fuji 24 Mp files which makes for the bulk of my recent photographs (in fact, it seems to me even faster).
What an incredible plus is to be happy with my current hardware; I have to admit that in the last few months of increased DT usage, I did occasionally think of upgrading and moving to a desktop pc to improve performances etc. Not anymore! And that’s liberating because I can concentrate on actually using the computer to take care of my photographs, and not fucking around with it just to “keep up with the software”.
I will also add that the occasional flashing glitch when in darkroom mode is still present in the latest git from master…
@Pepe I believe so…I think this is why the previous modules that were always applied but left out of the history stack are now included so that when the xmp gets saved you will have things behave as you mention…one thing in my limited testing though you need to know what modules belong between the input and output color profiles …during one dev version a while back my old edits came in with some module being arranged outside of that and the images looked crazy…dragging the module back in fixed it…I stress this was a while back when there was almost daily efforts to wrestle with the effects of introducing the new modules and pixel pipeline changes…again from what I understand…not an authority by any means…there are a few discussions on git about it that I could direct you to??
I agree this may turn out to be a source of a lot of questions and bug reports due to a lack of understanding about the consequences of moving things…esp for newer users foreign to the notion…
I have the problem with a mounted usb device in darktable. (latest git compilation)
- usb device is mounted correctly and visible and data are accessible at terminal level
- df shows all related information and one can access data
Once DT is loaded the mounted device does not show up.
What could be the reason for that?
Manjaro Linux
How are you mounting the external device?
Where does it not show up?
I am using Manjaro/KDE, I have just mounted a USB stick, and opened it with the file browser. Then I started darktable (3.0.0rc0+130) → import → image, selected the USB stick and picked an image to import. Works just fine.
Are you performing other steps?
Have fun!
Claes in Lund, Sweden
I have mounted a 1TB Drive with sudo mount as /mnt/hdDrive
With DT I tried to import folder from that drive but it ist not listed in the dialog.
With lsblk the drive ist listed as sdc1
And you’re navigating to /mnt/drive in the dialog?
OK… now I see two scenarios
Some days ago I imported a folder from import dialog /run/media/drivex
The drive was listed at the legt side nearby Other location tab.
Today only skulls are shown as the drive mapping is invalid.
Now I can find the device as proposed unser /mnt/drivex.
I can remember that the first device was listed as sdd1 whereas the current one was sdc1.
Maybe some drive information is still not cleaned up. I did a umount every time.
Thks for the time to clarify my troubles
S.F