C-M-B wrote:okay, let's just take Adobe Bridge as an example. When I go to a folder on my NAS that I have never opened before with AB it instantly displays ALL images and then takes only a few seconds to render the thumbnails.
And if i click on one it instantly displays a preview.
So obviously my NAS is fast enough and it is possible to work on a NAS. Heck even with Photoshop I can open multiple large files (1GB-3GB), edit them and save them via NAS rather quickly.
I just don't think there's an excuse for a program to take that long just to display files, especially when programs that have never even accessed the same files are able to display and render them in just a fraction of the same time.
I like Capture One but I'm not blind.
I've never used AB so I can't comment on that but I do recall working with early LR V1 and comparing it to the editor I favoured back then wondering why LR seemed to relatively fast and the other editor so relatively slow on screen at the time.
The answer appeared to be the way the process was presented.
LR would apparently show instant results but if one looked carefully after the initial screen update there were still changes rippling through the screen and, on the machine I was using back then probably mostly for jpg editing at the time, about 3 seconds elapsed before the change and save process completed. That was using the local C: drive.
Using what came to be my preferred editor and applying as close as I could get to the same adjustments the screen showed no changes until all of the adjustments were written at the end of processing in one update - which took about 3 seconds. So far as I could measure and for all practical purposes there was no difference in processing time to the point where my next instruction was accepted but LR
looked faster in that iteration. I assume that AB, PS and other members of the family are likely to use the same design philosophy - possibly even the same code.
For both of those application one had to be sure to save the file of course. With C1 almost all edits are automatically saved as part of the process, the exception being things like Keystone correction where the probable processing overhead and the nature of the change makes it logical to work with a preview file (although 4k and 5k size previews probably negate the benefit) to make the visible overview adjustment and then apply the change when happy with it rather than make a lot of micro changes automatically while achieving the desired alignment.
The challenge, of course, is that external USB drive and even NAS boxes and whatever the chosen spec of drives in them, tend to deliver much better data transfer rate for large files than small ones but the trade off is the balance between how much data one needs to move between disk and memory and back to disk to record the changes.
Writing to the Temp files on the local disk is likely to be equally fast (for practical purpose of human perception) in both cases. Updating the edits on an external drive in near real time rather than when instructed may give a different perception and is, perhaps, a process with broader considerations than simply perceived elapsed time.
And, of course, there are many other factors that might or might not be in play when using an external drive - especially a NAS which is likely to have a lot of internal file management going on to compete with external date delivery requests.
Grant