I found exporting to JPG is a slow process. My computer is running on i7, 8G RAM, Windows 10, SSD. Raw (NEF) file with not many adjustment (some with local adjustment, some without) needs 25 - 40 seconds to export to JPG (744 pixels in long side @300 ppi). I’m not sure whether it is normal performace or my computer is not powerful enough or some configuration I don’t tune up.
I just tested it on my older I7 Windows 10 machine with 24 gigs of ram. Exporting a fairly heavily edited Canon raw file of around 25mb to jpeg, with PRIME noise reduction added, @ 300 ppi and 100% quality took around 29 seconds. Exporting that same image resampled at 744 pixels, with PRIME noise reduction added, took 23 seconds. Exported the same image without PRIME noise reduction took 9 seconds for the original image and 7 seconds for a version resampled to 744 pixels. While my processing is performed on an SSD drive, the images themselves reside on a normal HDD. Even though you have only 8 gigs of ram, I think your response time is not typical.
I don’t think the RAM is your main issue. While it would probably improve things, I suspect something else may be slowing you down. Could you update the RAM in your current machine to 16mb? Are you running other things at the same time as Photolab? Have you analyzed memory and disk usage and performance? Plenty of people are running with 8 gigs and getting better performance than you are.
I just did some benchmarking on my Mac Mini (Late 2012, 2,6 GHz Core-i7 3720QM, 8 Threads, 16 GB RAM, MacOS 10.14.3) and on my MacBook 12" (2015, 1,1 GHz Core-m3 5Y31, 4 Threads, 8 GB RAM, MacOS 10.14.3). I converted a 24 MP RAW-File from my SONY Alpha-7 to a JPEG with 80% quality.
with HQ noise reduction: 10 seconds
with Prime noise reduction: 48 seconds
Memory consumption of PhotoLab2 binary: 1,55 GB
with HQ noise reduction: 24 seconds
with Prime noise reduction: 2:10 minutes
Memory consumption of PhotoLab2 binary: 1,31 GB
You can also check if OpenCL is on or off and compare the processing time. And one more thing can affect the time of processing - the size of the virtual memory ( - you can find it in PL logs - OS swap size: XXXX MB - it’s good when you have it > 2GB).
Well, what do you mean with “clean up”? What’s on the disk is completely irrelevant for processes running in memory.
Regarding memory it’s important how many processes are running at the same time. So you should avoid to run Outlook, MS Office in general, your favorite Internetbrowser etc. at the same time.
Ahh, what comes into my mind: You talked about your Ultrabook…
One major problem that some of these devices have is HEAT! Does your Ultrabook have a fan for cooling?
E.g. my above mentioned MacBook 12" has NO fan and an only mediocre heat management. That has the consequence, that all available optional faster CPUs, especially the ‘i7’-CoreM processor, are not faster at all if the load lasts longer than a few seconds because of heat-throttling of the CPU. That’s a protection mechanism such CPUs have to avoid overheating. In case of too much heat the CPU reduces the frequency (or “speed”) of operation until the temperature falls below a specific value of the processor type.
You can see it on my measurements above: The Mac Mini takes 4.8 times the seconds of the HQ noise reduction to create a PRIME noise reduction whereas the MacBook 12" takes 5.4 times. Probably there’s already a slight thermal throttling on the MacBook. (Keep in mind that my MacBook has the slowest and coolest CPU available).
Probably that’s the reason of your performance problems. Perhaps you search for some system tools that show the CPUs operating frequency and other performance parameters (disk I/O, memory consumption, swapping, etc) to gain more insight what’s going on in your machine.
What I mean “clean up” my computer is cleaning garbage files (esp. temp files), reorganizing file system by utility tools. Since Windows and other applications generate temp files as well as other files which may not be useful anymore but left in harddisk. The purpose is free more empty space for application to execute.
For converting NEF to JPG, in the past days I was using CNX2, I use FastStone Image Viewer to do batch conversion. It can convert 100 edited NEF files in around 90 seconds on the same Ultrabook I’m talking about. You can see the huge difference from the performance by DxO. However, since DxO (also NX-D) adopts sidecar file, FastStone can no longer read edited NEF file. So I have to use the bulid-in export feature from DxO. But the speed on my machine actually slow down the whole process very much. I’m still try to figure out the core reason of my case, esp. the reason of difference from other user.
Does CNX and FastStone actually do debayer processing of the nef and then rescale it and save it?
Or so they simply extract one of the embedded jpegs?
Extracting a jpeg instead of processing the nef would be a smart way to do it for cnx as the Nikon’s write fully corrected and processed jpegs into the nef at the time of photo.
An extracted jpeg and exported nef should look exactly the same when created by the camera and cnx.
You can try this:
Export an unedited, without any changes jpeg from a NEF with FastStone.
Extract the embedded jpeg from the NEF with exiftool, with this command:
exiftool -b -jpgfromraw /path/to/_image.NEF -w _extraherad.jpg
Compare those two.
Same exif data?
Yes, the size differences you see come from lack my exif data.
So now we know that FastStone simply extract the embedded jpeg and the exif data from the NEF and then writes the exif into the jpeg.
Thanks you very much for the tests!
I guess PL always uses the non debayered RAWs and on top of that add their adjustment layers - which explains the great quality they produce - where some other developers are exporting post-debayered and pixel based images like TIFFs which will be much faster.
And on the Mac it’s a bit worse even because PL does not use my GPUs at all. It punishes my 8 CPU cores to the max although that’s efficient it feels a bit old school not utilizing both my GPUs as well as the CPUs to process the NEFs.