The Canon R5 has an IBIS High Resolution setting which produces 400mp JPG files. I would like to apply PhotoLab’s image corrections based on the camera&lens-database to optimize the image. I know it’s not a RAW image, but Photolab can handle JPG images too. However, this 400mp image will not load. My first try out resulted in an endless message: '‘Full review in progress…’ I had to force Photolab to quit. My second try out resulted in: ‘External component has thrown an exception’. Is it me doing something wrong? I am using Photolab v8.6.0 build 589. (I can upload the image, but it is HUGE, so I will wait until you ask me to do so. It is 124.075 KB)
Well, I created a 604 Mpx TIFF file using Topaz Gigapixel and that takes about 10 secs to load, but it does load without problem. PL 8.6.0b45
Hmmm. My file is 3.6GB. I wonder if yours is in a compressed format that PL can’t cope with?
Try converting it to uncompressed TIFF.
Try to disable all photolab corrections first. Maybe all r5/lens data only handle the normal size of r5 pictures and in your case the look-up tables are exceeded with the great values.
You asked me to convert the JPG file to uncompressed TIFF. I just did and tried to load this 1.2GB file in Photolab. Alas, after 6 minutes the Photolab splash screen was still on my screen with the rolling (hourglass) cursor. Nothing happened. So I killed the process. There is a reason why Canon choose to create a 400mp JPG file and not a RAW or TIFF file. However… It takes Irfanview 17 seconds to load this TIFF file. It takes GIMP 3.0 appr. 35 seconds to start up and open this TIFF file. I will try some other big files…
Just enlarged a JPG file from the Canon R7 to size 24680 x 16455 (just 24.599KB). Tried to open in PhotoLab. It opened. Then it said: Full review in progress…
Then… Blue Screen of Death !!!
The PC restarted.
It seems to me that this is not behaviour that is Photolab worthy.
Again Irfanview and GIMP just opened the file without any problems.
BSOD is generated by Windows in kernel mode only, e.g. due to a bug in some kernel driver (in your case most probably graphics), or unrecoverable exception generated by hardware (e.g. faulty CPU cache, RAM module, etc), or a bug in Windows kernel. Your crash may or may not be related to the original problem. Check Windows EventLog for OS crash reason and PhotoLab logs for possible hints about the original problem (e.g. search for ‘exception’). Your problems look a bit unique…
Which GPU and CPU do you use?
Do you have enough RAM (8GB could be too little in your use case)?
Massive pageouts due to lack of RAM may slow down the system, and in some specific cases cause kernel spinlock timeouts resulting in BSOD. Graphic driver bug is another probable candidate. Just speculating…
Processor: 11th Gen Intel(R) Core™ i7-11370H @ 3.30GHz 3.30 GHz
Installed RAM: 16 GB
Graphics Card: 4 GB on NVIDIA GeForce RTX 3050 Laptop GPU
I will check the log files lateron. Now busy editing pictures for a customer.
@Erik I hope this doesn’t disturb your editing session.
So far I have found a 207MB R5 IBIS image online at “A Field Test Of The Canon R5 400 Megapixels Update - Art Shoot” on my i7-4790K (32GB, RTX2060 but only PL7 installed) and downloaded it and then accessed it (across a LAN) with PL8.5 running on my 5900X (32GB, RTX 3060) and it worked fine.
PS:- It loaded successfully into PL7.13 on the i7. This machine is suffering a memory leak problem so that memory, with PL7 and the image loaded, is currently showing 23.9GB usage.
The image is on E:\ (SATA SSD), the PL7 cache is on a slow NVME (on a PCie card) and the database is on the C:\ drive (SATA SSD).
PPS:- The edit used shows a difference but doesn’t improve the image in this case!
Config looks OK, it should work fine…
Tested the file which @BHAYT used (13,466x18321 jpeg) – just selecting the file in PL8.6.0 causes a jump of ‘In Use’ memory by 6GB (7GB with PL loaded → 13GB after opening the 200mpx jpeg), circa 30 bytes per pixel. I would expect 6 or 12 bytes per pixel, so maybe the problem is in PL?
Time to call DxO, I think.
It works OK in my case, but I have 32GB RAM/i7-14700KF (+RTX 4070, but that doesn’t seem to be important in this case).
I used a 25384x16924 jpeg to test. For i7-14700KF/32GB it takes 2-3 sec to prepare the preview, ‘Full preview in progress’ is briefly displayed. When image is first opened, extra 16GB of memory is consumed, about 36 bytes/pixel. Selecting the file next time consumes 12.6GB, about 30 bytes/pixel. Probably the first time file is selected, PL uses more memory while generating preview and thumbnail cache entries. Anyway, it seems you have not enough memory to open the big jpeg and perhaps DxO should take a second look at PL memory usage.
Test description:
In a new directory create 430mpx jpeg (canvas of red pixels) using free ImageMagick:
magick -size 25384x16924 xc:red 25384x16924_red.jpg
and create a 1mpx jpeg:
magick -size 1000x1000 xc:red 1mpx_red.jpg
Note that PL will select the 1mpx file when it opens this directory.
Run PL8, change the directory, select Customize tab.
The ‘In Use’ memory reported by Task Manager was 7.2GB in my case.
Select the 430mpx jpeg. Memory usage jumped by 16GB to reach 23.2GB, more than 30 bytes/pixel.
Select back the 1mpx jpeg. Memory usage went down to 8.2GB
Select the big file once more => memory jumps by 11.6GB (19.8GB)
Switching between the files stabilizes with ‘In Use’ memory switching between 7.2GB and 19.8GB.
Interestingly, test with similar 16-bit TIFF file required about 8GB, so much less than JPEG (about 18 bytes/pixel).
I did some more PL restarts in the test directory and at one time PL crashed during startup, asking me if I wanted to send the report to DxO (which I did). PhotoLab log contained the following:
DxO.PhotoLab.CrashHandler.Service.UnhandledExceptionReporter - Error | Unhandled exception reported by ‘DxO.PhotoLab.CrashHandler.ExceptionListeners.DispatcherExceptionListener’
Exception: System.ArgumentException Source array was not long enough. Check srcIndex and length, and the array’s lower bounds. at System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable)
Looks like I hit some PL8.6 bug, perhaps race condition (previous PL starts with the same directory had no problem), might be unrelated (?).
I just removed the files and PL works normally now.
I think it’s reasonable to assume that a user should have more than 16GB of RAM/4GB of VRAM to open a 400mp image. That’s a completely ridiculous resolution for the type of person who can’t afford a computer with 32GB of RAM. OP has an R5, he can probably afford $100 for a 32GB kit.
@Lindon_Slaght Your comment adds nothing to our potential understanding of the issue and follows the classic trope of “user error”, in this case the “error” of even trying to handle the image with an “inadequate” machine.
The 4GB of VRAM has been more than adequate for some time but the introduction of DP XD 2s has started to put that under pressure, which could have been avoided if DxPL had left DP XD intact and introduced DP XD2s alongside it.
My RTX 3060 in the 5900X has 12GB but my RTX 2060s (in my i7 and 5600G) are both 6GB devices and because my machines are desktop systems upgrading the GPU is an (expensive) option but not as expensive, nor anywhere near as disruptive as buying and then commissioning a new laptop (migrating software etc.).
My earlier posts indicated no problem on my 16GB “baby” computer but that was with PL7(.4) and the problems are now being experienced with PL8.6, perhaps there is a clue there, i.e. an “inadequacy” in the software rather than in the hardware that it is being run on perhaps.
@Wlodek running some tests with PL8.6.0 I discovered this with respect to memory usage
Incidentally my PageFile on this system (5900X) is on my N:\ drive, a reasonably fast PCIe4 NVME and is 16GB in size (of the 1TB of the NVME).
The diagram (of the 5900X with 32GB etc.) is made from four snapshots taken at roughly the same time but using the cursor to obtain the statistics at certain points on the graph both before attempting to access the image and then after.
While there is a big jump in main memory usage (just under 9GB) the jump in ‘System commit’ (just under 30GB) is really alarming!?
This is PL7.14.0 on the same machine with the same image after the PL8.6.0 test something of a difference!!
The graph shows the PL8.6 test, followed by a close of PL8.6 and then the start of PL7.14.0 followed by the discovery of the Test image with a “huge” jump in main memory use from 5.6GB to 6.9GB to 10.3GB and the ‘System Commit’ also looks as if it is under control.
The reason for the comparison chart starting from 0 was because I restarted the machine after experiencing an “alleged” corrupted database (I thought I had deleted database completely?) and an offer from PL8.6 to make a new one and restart, except it didn’t restart automatically.
After a manual restart I got the following when attempting to access my test image
Thanks for all the testing and helping to find the causes of the exception. I checked the log files today. There is no log of the BSOD of course. PhotoLab did not get the chance to write it’s logfile. There is a log file of the day that I started handling these ‘ridiculously big’ files (May 15th). I extracted some parts of this logfile. It is clear that memory allocation is the issue. I think it has to do with creating thumbnails/tiles. However, I also see too big integers while calculating white balance values. Of course I can buy a laptop with 32 GB memory, but the issue will re-appear after some years as files tend to get bigger and bigger. Several camera’s can produce huge high resolution images nowadays, so this issue might appear more often. I think the PL developers should indeed reconsider memory usage. I am very curious if PhotoShop and Lightroom can load these big images without problems. I do not use these Adobe programs any more, so I cannot test this. Should I rise a PR for PL or should I just buy a new laptop soon?
DxO.PhotoLab3 - parts.txt (10.3 KB)
@Erik The first thing to do is make a support request to DxO because I don’t believe that it should be happening!
The difference between PL7.14.0’s memory usage and PL8.6.0’s memory usage are so different that whatever DxO have done with the product is either misguided or positively wrong (a coding error?).
Longer term you may need to consider an upgrade because the new Noise Reduction algorithms that DxO are introducing are taking more and more GPU memory (VRAM), which is not relevant for JPGs.
The fact that PL7.14.0 can cope with the image with essentially no problem at all is what we should expect from PL8.6.0!
I will also make a support request later today and point to my findings as I have written them up in my posts above.
To help you decide, don’t rely on testing with a single large file, as this might be an exception (for now). Try other examples, such as those from dpreview.
( in general, performance of laptops is usually weaker than that of desktop devices )
@Wolfgang: Thanks for your reaction. I already tested with several files. It could be interesting to test with ultra high resolution files from other camera manufacturers. At the moment I do not have the time to do this, alas.
(I know that desktop devices have a better performance in general. However, I choose to use laptops and store everything on my NAS. This is more flexible for me. The laptop I own now was ‘top-of-the-line’ 3 years ago. Now it starts to get ‘old’. In general I buy a new laptop after 4 years, so it has to last one year…)
@BHAYT: Thanks! I will make a support request.
1 Like
400 MP Jpeg? New laptop? Sorry, but if I were you, I would start by getting myself a good photography textbook…
1 Like
@Fotoguido On what do you base your “guidance” that @Erik needs or should get a good photography textbook?
What have you discerned about @Erik’s skill as a photographer from the little information on offer in this post to warrant such a suggestion?
I gleaned that he has a camera capable of taking high resolution (JPG) images and chose to try it out, then used his “favourite” photo editing package to review and enhance it.!
No more and no less.
However, the reason for this topic is because there appears to be a problem with PL8.6 (Win) which does not appear to be present in PL7. i.e. it was a reasonable thing to expect it to “just work” and thanks to some DxO coding it doesn’t, at least some of the time.
With respect to the desire or need to update to a new laptop, particularly if the user is using DxPL to edit RAWs, is that it is the only (realistic) way of of upgrading the GPU as technology and the demands of DxPL NR increase and what business is it of yours (or mine) anyway.