For some reasons I always put scratch disk value to 0. No scratch disk at all.
The station I use to run photolab has 64Go ram, no scratch disk and 12288 Mo + 25464 Mo Gpu Ram (2 graphic cards).
I use photolab 6.3.1 and I don’t have this problem. And don’t have it neither with only the smaller graphic card (12288 Mo ram).
Could be a bug in the DXO or drivers than. Not sure.
Oh … I only have VP3 ! My mistake.
Maybe you should check memory as MSmithy told.
I don’t use scratch disk and I don’t remember very well, but it’s possible that I’ve already had a problem of this type (same error message) with only 32GB ram. But without using VP.
Vous avez un zoom de 360%, en diminuant sans dépasser 100% est-ce que vous avez le même problème?
@JoPoV & @MSmithy I will respond yo your comments tomorrow but @comandante yes it appears to happen at 100% but although the screen refresh gets “stuck” momentarily continuing to move around the image does clear the “fault” and it does not occur all the time.
I must be very lucky when it comes to software. I use a 3 year old ConceptD 5 Creator Pro laptop with pedestrian nVidia Quadro T1000 graphics (with the latest studio driver), and I see none of these issues, Photolab 6.7 is running great, along with another app that seems to be troubling folks lately, Corel Painter 2023, which is also glitch free for me. And I have 4 monitors attached, including the laptop monitor and my Wacom Cintiq 16 (via a Startech external Trigger6 USB to HDMI graphics card (latest driver on that one too)). I wish I knew what I was doing right, in case things do go south, because I have so many points of potential failure with my setup.
I took the train running, so you’ve maybe already responded to the following, but first questions should be :
- since when this happened ? is it the same as the OP (since V6.7 installation ?).
- more globally, what did you change to your workstation between when it worked and when it didn’t (install/desinstall/update software/drivers, system (auto)update, preference/setting change on “critical” software (antivirus, etc… - probably not relevant to your problem, but better know it - ), hardware change) ?
In Windows, scratch disk == page file
@jopov, @MSmithy, @comandante, @danielfrimley The problem occurs only with the use of ‘Reshape’ from Viewpoint 4. A feature I have not used and am unlikely to use either ever or possibly very rarely.
My original response to this post was to state that I had experienced none of the problems originally encountered but then came the post about ‘Reshape’ which set me down the “rabbit hole”!
The image I used comes from my original 11,000 BULK test images but from a group of 1,000 Bulk test images, many of which are simply renamed copies from an original shoot of 800 images (I had left the “burst” mode on)!!
So I copied the next image from the test set (which is identical to the original image only the name has been changed) into my test directory, copied and pasted the settings from the ‘Reshaped’ image to the “new” image, unset ‘Reshape’ and
- The ‘F11’ issue is no longer an issue with the new image, i.e. it just does not happen
- I have been all over the “new” test image @350% and all moves are rendered successfully, albeit slightly slowly on the i7 machine.
So I believe that the issue is with PL6.7 and VP4 and ‘Reshape’ BUT I have no machine on which I can test VP4 on an earlier version of PL6 and do not have the time or inclination to try to go back and what would that tell us anyway!?
I guessed as much and it is 24GB in size and located on the C: drive, a 480GB SATA SSD.
I was originally going to state that my choice of a 5600G processor rather than a 5600 or 5600X was deliberate and to gain the onboard graphics so that I am not reliant on the graphics card for a working machine! It has not been an issue in the past and I don’t think it is an issue in this case but I might be wrong but …
Interesting. I imagine that “Reshape” feature, being fairly new addition to the features, probably could use some optimization to iron out performance and stability.
I remember that when it was first released Reshape tool was something I tested on ViewPoint standalone and it worked just fine with complex images and changes, but same image in PhotoLab, I can’t remember what exact version was it, but when it was first released, felt a lot more sluggish in performance. Luckly it did not crash and it worked, but it was quite slow to work with compared to ViewPoint standalone application. I assume it could use some more optimization from the development team.
But as you said, its not a commonly used feature so its not one of the critical ones, although when you need it, its nice to have it work as it should.
@MSmithy Absolutely, arguably both appear to “self rectify” albeit the ‘F11’ problem returns to the normal editing screen.
I tested ‘F11’ again and noticed that zooming in and back quickly caused the ‘Internal error’ every time at some point so I z o o m e d very cautiously (slowly allowing PL6 to keep up) and managed to zoom all the way in and back without the error occurring!?
Actually now that you mention this, I remeber back in PhotoLab version 4 I think I had to do that as well. It is as if “F11” goes full screen, forces DXO to redraw, refresh and purge memory cache and basically serves as if one has restarted the app. This goes in favor of my theory that its a problem of memory leak or mismanagement somewhere in DXO.
This to me indicates that if you zoom in slowly for PL to keep up, it probably means that its trying to render everything, all the adjustments each zoom level but probably of the entire screen, and not just what is in the viewfinder. Zooming in very quickly probably again means it has to draw everything very quickly and it starts to lag. I guess DXO should look into it and optimize the code and GPU rendering so it can keep up and be more stable.
Thanks for the “rabbit hole” tests.
@MSmithy I would like to say you are welcome but I have mostly stopped testing.
Testing before PL5 was released, but mostly after it was released, certainly got my old brain cells working again but with DxO “it is like banging your head against a brick wall”, only any good when you stop!
I’ve reinstalled PL v6.7 and updated to the latest nvidia Studio drivers - so far no significant change. Nevertheless I worked on quite some pictures and can conclude that the issues are starting after “ReShape” was used. As long there’s no use of it, it seems to be stable. Thanks in advance for any feedback.
Erhard
Sounds like “reshape” or basically a kind of Photoshop liquify tool is a bit memory intensive for RAW files + all the corrections in PhotoLab, and I hope DXO team optimizes it for speed and stability in future releases. I have been playing around with it some more since this threat and I found similar situation where in PhotoLab “reshape” tool tends to run out of memory it seems while in ViewPoint standalone app or used as plug in from Photoshop, it works with no problems. So I don’t think its the tool that is bad, but implementation in Photolab needs so more polish.
Yes, it seems to be the case
Hey,
I’ve had too some PL 6.7 hangs after having installed it.
So, I’ve updated my NVidia drivers, restart my PC, and then, doens’t have any other issue for the
moment.
Thanks.
Did the same than you. Until I use ReShape all is fine.
Once ReShape is used all the issues I’ve described earlier on are back,