Granted, exported VCs result in “_n” being added to the exported JPEG filenames, but as long as I’m aware of that convention it’s easy for me to know that filename_n.JPG belongs with filename.NEF etc.
It does, but compared to the thin contacts and it’s also thin metal shield around, the socket of the CFE/XQD card is multiple times more rigid (rugged?) and you have guiding elements when you insert the card which prevent canting the contacts. I’d say it’s very easy to imagine a mechanical failure of the plug (like tripping over the cable, normal wear out, dirt in the exposed contacts and so on) than to bend the (more stable and wider) contacts of an XQD/CFE card. SD is a different story.
With your D850 you’ve got a plastic adapter to make the USB 3.0 plug a but more stable - Nikon had some reasons to do so. With USB-C it’s more compact and at the same time more stable mechanically.
I don’t think it’s a wise idea to rely on the path\filename combination.
That’s mine idea.
George
1 Like
I know but did not want to write it…
Moreover, I think that DPL will need to come up with an import feature (catalog files only if the user asks for it) in order to get away from WOM-operations, collecting all the scraps that come along…or at least with a possibility to remove files from DPL without sending them to the trash.
1 Like
As they say, whatever floats your boat 
Since the camera is usually on the table next to the computer and the cable is carefully inserted before and removed after transfer, that is unlikely.
But my point remains that, if PL were to allow. for “importing”, it would have to cater for direct camera connection in order to not disappoint.
You don’t think it would be possible to tap Image Capture’s capabilities for that? I simply don’t know, but as Picktorial is using Apple’s RAW converter…
I think the length and detail of this thread demonstrate why putting in file/folder naming/copying/moving operations is difficult if you want to be comprehensive and cover all possibilities. I might mention GPS encoding if not there already and reverse geotagging (finding place names for GPS coordinates) as something else people are interested in. I can see that some people are already using place names in their folder structures. Professionals also make heavy use of “job” names as well.
I spent a lot of time looking for tools in the Window’s domain to accomplish what little I do and it was very hard. I have some software that can only read file systems and not talk to cameras. I agree with Joanna that sometimes importing direct from camera, especially over high speed USB C is more convenient than popping cards out into a reader. Now that I am adding Apple HEIC files to my collection, that task has gotten harder. I have found that extracting metadata on a HEIC file while it is available in the explorer doesn’t work with my copy/renaming software. But when I copy those files locally, the software works fine. This forced me to start looking for a different “importing” tool, and I found one of my previous tools works well with Apple, so now I need to keep it updated after I stopped using it for a few years…
I made 2 series of files.
D850, 120 RAW files, 47 MP lossless compressed, XQD card
USB-3.0 of camera connected to MacBook internal SSD, using Image Capture: 40 seconds
DLock card reader, using finder: 25 seconds
Z7, 170 RAW files, 47 MP lossless compressed, CFE card
connected with USB-C to iMac/internal SSD: 1’30"
using a TB3 XQD/CFE card reader: 0’17"
To me, the card readers are the better choice every time. Also, when using finder I can rename the RAWs already on the card. Using L-brackets, the flaps of the USB connectors are sometimes fiddly to open. That was my main reason to prefer “cards into readers”.
That was interesting, I didn’t expect this big differences. Speed is not everything and a few seconds more or less don’t matter, the better mechanical stability of card slot cs. USB socket do matter to me.
Interesting also how many different naming concepts are in use. Let’s not forget that we usually don’t start with the “perfect” concept right from the beginning of our digital photo careers. When I remember my first attempts with scans 15 years ago, I was happy in the short period I used an app taking care of all file naming and organisation (Aperture produces even more folders than Joanna). And these days the organisation part is expendable work for me.
Another experiment Joanna gave me the inspiration for: I was curious to see how long it takes to import folders into Apple Photos, which I set up to use referenced files (instead of importing the RAWs into a library). Less than one hour to import 11.200 pictures.
After that import finder showed me a library size of 12.14 GB. 5 hrs later that increased to 50 GB as Photos is scanning for faces when it’s not in active use. PL’s database is tiny 430 MB but with Apple Photos I can use folders, albums and intelligent albums. Of course, editing is not as flexible as in PL, BUT: “Apple lens correction” corrects the lenses PL doesn’t today. If I could get Photos to use RAW Power as editor (instead of the also not too bad Photos editor) I would still miss local adjustments. But the organisation is better than PL ever will be, I’m afraid.
Not just that - it’s also creating preview jpegs for the masters. Unlike PL, which generates the previews dynamically, which is why you get so many spinning arrows.
In some ways, it could be seen as a good idea to generate processed previews but the question would be, where to put them and, with the increasing size of modern RAW files, that’s really going to fill up disks fast. One of the reasons I like PL so much is because it only creates “copies” as and when required.
I know some like to be able to browse processed versions outside of PL, but that can, in itself, create problems if metadata is exported with the copies, thus forcing a search to return both the original and however many copies instead of only the one original.
But, on the subject of file renaming on import, I still remain to be convinced and feel that a decent flattened hierarchy browser would remove the fear of deeply nested folders.
There’s another tiny risk with the previews: back in the day I created some photobooks printed by Fujifilm. Fujifilm had an app in which I could access Aperture lib directly. But before I followed the suggestion of an Aperture trainer who said reducing preview size = smaller file size means smaller and quicker database (true, but…). And Fujifilm’s programmers did not make a proper export, they just took the preview jpgs. You can imagine the result? I got a new book after we found out what happened.
So, previews help for faster browsing (the speed of displaying all included RAWs in one main folder with 30 or more subfolders was very impressive) and they also help with quicker display of library structures like folders, albums, intelligent albums. Last time I tried Photos it was horrible in all ways, over the years it became at least usable. Unfortunately I can’t send a RAW to PL - but to RAWPower, Affinity Photo, Pixelmator, OnOne, Picktorial… and even RAW Power became better. Instead of waiting for DxO’s probably never really happening DAM, this could be my way to go if I find out how to speed up my workflow. Keywords, places, faces is more Apple like easy.
Now that I understand your app a bit better I can see where you’re coming from, I still think I’m not a big fan of dealing with folder structures at all. I want put that responsibility for consistent folder structures to a well made DAM and care only for my collections / projects / intelligent albums. Deeply nested folders are nothing I relate to quick workflow, I see them day-in, day-out in Windows and I constantly need new tyres on the scrollwheel.
Copy from sd card is definitely a feature that is lacking if you want to use exclusively PhotoLab for photo management.
I think Zoner has a nice implementation of photo import.
You can customise folder naming and select dates or photos that you want to import.
On Mac, just copying the full content over via the Finder is one of the fastest and most failsafe procedures (does require glancing over file numbers and file sizes and previewing a photo or two first). There’s also native/free Image Capture for cameras which don’t give up their photos via the Finder.
I’m not sure that maintaining an elaborate photo import tool is the best use of DxO programmer time. I foresee endless fights about how photo import should work best, turning into an interface with so many options that an astronaut or 747 pilot would feel disoriented looking at it.
There’s so many dedicated import tools on both Windows and Mac, two or three for every taste.
2 Likes
The last thing I need is an over complicated feature rich import tool like Lightroom’s. The requirement to import new images in Lightroom was one of many reasons I ditched it for PhotoLab. I just use Windows built in file manager, Windows Explorer. It is easy to use but it doesn’t have a lot of import features that seem to be important to some people. Prior to copying files from my camera’s SD card I always create a folder for the current shoot. Here is an example of the naming convention I use “yyyy-mm-dd Descriptive text”. Example, “2022-04-03 Zimmerli Museum” If I want to rename the files in that folder I then use PhotoLab’s “Rename selected images” feature.
One of the great things about PhotoLab is that the design of the interface is lean. There is not a lot of bloat like many other raw processing titles. But it also means you aren’t getting the same kind of hand holding for various features that other software provides. Users need to take the time to learn the interface. It isn’t that difficult, but those who expect support for the novice along the way may be disappointed.
Mark
3 Likes
That’s the reason that I never used Lightroom. I strongly dislike having to import photos into a catalog. I want to put my pictures right where I want them and to be able to move them around without my PP programs losing track of them and then complaining that they can’t find them.
3 Likes
Earlier posts have explained reasons why DXO should not devote resources to this feature, though it would be nice to be able to use just PL and stop using LR or other “external” program just for copying files to my HD.
But I think there is slight a confusion here. Few people will want to keep their photos on SD cards and will want to copy them to somewhere on their hard drive/cloud drive. LR an C1 both give the option to decide where to copy them; you can choose to put them inside the catalog, but that is optional. I think the difference between PL and the LR/C1 is less than this comment suggests because PL does something with files when you open a folder for the first time.
Sorry if i have misunderstood something here.
Lightroom does not import image files. It simply catalogs them, as does PhotoLab. The only difference is, that PhotoLab does it automatically when it’s pointed at a folder, while I have to tell LrC to actually do it. In Lightroom, I do have control over what is catalogued or not, while DPL simply stuffs everything into its database, whether I want it or not.
2 Likes
If I can interject…
This request is all about copying files from an SD card, which is just as easy to do using Finder.
But, if folks insist on requesting this, then I feel I should be able to jump on the bandwagon and extend that request.
I never copy files from my SD card - I just connect my camera to my Mac with a USB cable and use Image Capture (which comes with macOS) to transfer them directly.
And I know, from research, that would mean DxO having to integrate direct USB connection APIs from every single camera manufacturer.
No. As others have said, this involves far too much distracting effort at a time when DxO still hasn’t yet found the time to “normalise” the Windows and Mac UI.
3 Likes
Canon Cameras don’t show up as external drives…anyway, I understand this request not as specific to SD cards, but as a request for a general import feature…
Roger, I’ll be brief. I suggest you learn your OS. I’ve explained how transfer from SD/QXD/CF is handled extremely well in macOS’s built-in Finder. Import from cameras is handled by Image Capture. @mwsilvers has explained how well Windows Explorer handles image transfer.
Both Apple and Microsoft are hundred billion dollar multinationals whose core functionality relies on being able to manage files reliably and interface directly with the vagaries individual camera manufacturer’s protocols. That DxO leverages that core expertise and doesn’t try to reinvent the wheel is to their credit.
If you get your way, I look forward to the threads about how PhotoLab damaged or lost photographers’ invaluable/unique/irreplaceable photo sets on import. I’ve read those threads exist for most RAW development tools who handle image transfer. Heck, Apple and Microsoft lose and damage files but when these bugs exist they are found fast and crushed or limited. DxO can only build on top of what is in the OS but they can create new bugs/incompatibilities which will result in failed transfers and/or lost data.
These threads always remind me of the guy who wants a sports car to travel with a stove, a bad, a fridge and a coffee maker in it. What else can we stuff into PhotoLab to make it a clunky, over-coded, fragile and unmaintainable multi-headed application. iTunes and Lightroom have gone down that path. Adobe had to throw out Lightroom Classic and start again. Apple had to kill iTunes and start again.
DxO is not a trillion-dollar multinational and could ill afford such a mistake, killing their crown jewel to extend it.
5 Likes
This may be the case but I move my files around frequently before and during processing before they reach their final resting place. I do not “import” them to a permanent location and then work on them from there. The version of Lightroom that I trialed years ago, version 4 I think, always complained that the the files had been moved from where it thought they should be and would have to search for them. I knew where they were because I had moved them. I found this quite bothersome and irritating. Perhaps Adobe has made some progress in correcting this situation in the intervening years since I trialed it, but this made me uninstall the trial quickly and decide not to buy Lightroom. Also, I do not use PL’s database and delete it frequently so it doesn’t matter to me what is stored there.
I use PL for only one thing: Developing RAW files, period. I do not use it for managing my files, keywords, IPTC or anything else other than processing RAW files.
I realize that my workflow would not work for most and I’m not recommending it, I’m just saying that I appreciate the simplicity that PL employs in it’s uncomplicated approach with allowing me to point it to a file where I know my files are and begin work. In fact this was the main reason that I chose PL(OP back then), it was only a little bit later that I realized how good PL is at doing it’s basic function: Developing RAW files. It is simply the best and I do not want it bloated and over-complicated with a lot of extra(IMO unnecessary) added features.
I, for one, really like the fact that I can use PL without having to first “import” my files into a catalog so that it knows where they are. I do fine with my card reader and Windows Explorer to put my files where I want them to go.
1 Like