Update to Capture One 20.1 loses existing masks
I've just updated to Capture One 20.1, excited for the new features.
However, my enthusiasm was quickly curbed when I noticed that the new version appears to lose any existing masks on images previously edited (regular and gradient masks, in any case). I can select the corresponding layers but no mask will show when toggling mask display; also, the layers will have no effect.
This is after upgrading from 20.0.4 to 20.1 (13.1) on Windows 10 64 bit. Also, this is with Olympus raw images ("*.orf"), but I'm pretty sure it's not image-type- or camera-specific.
-
I don't have this issue at all, smooth update and nothing is lost...
0 -
OK, thanks for the response. Looks like I'll have to open an issue with Phase One then as it appears to depend on circumstance.
0 -
One more thing, did you convert your preexisting session or create a new one after the update?
0 -
I updates the pre-existing session (18 edited images with 1-4 layers each)
0 -
I figured it out: it was a path length limitation issue in Windows, which however could be handled better/circumvented by C1P. Let's see what they reply to my ticket...
0 -
Maybe you add this information to the ticket, if you haven't done so yet, so they have to spend less time searching for the root cause, which gives them more time to deal with other issues.
regards
0 -
Already did, of course. No reply to the ticket yet, though.
0 -
Marco, you are not the only one. I have the same problem (Windows 10, 64 bit). I updated the pre-existing session.
0 -
OK, so to expand upon what causes my issue: My directory structure resulted in paths that, when considering C1P's further sub-paths of “...\CaptureOne\Session131\IMAGE_FILE_NAME.comask” etc., would exceed a legacy maximum path length in Windows (MAX_PATH) of 255 characters, having the effect that C1P would fail to write its mask file (“*.comask”), merely creating an empty file in its place, and consequently, to read it. Curiously, non-empty mask files in a too-long path will be read successfully (if they have, for example, been created elsewhere and then moved such within the file system that the new path becomes too long).
In fact, this appears to always have been an issue because I figured out that empty mask files for the images in question had been created by C1P v12.x without me having noticed it at the time. Thus it was a mere coincidence that I noticed this after the update and not something caused by the update.
There appears to be a way of accessing files with paths in excess of MAX_PATH that Phase One could implement. On the other hand, there's a way of increasing the limit system-wide, with potential side effects for legacy applications. However, this still requires Phase One to modify Capture One (specifically, to add an attribute to the application manifest).
At the very least, C1P should communicate the error writing the mask file to the user to alert them of the issue. As it is now, the write silently fails and everything appears to be in order as long as C1P keeps running, but as soon as you restart the application, it fails to load the mask from the (empty) file, resulting in the mask not being there any more.
0 -
Another observation which is weird and disturbing at the same time. I noticed that after updating pre-existing sessions, images in that session have an additional layer that was obviously copied from one of the images in that session e.g. the layer for a sky highlights correction was in all images in that session. In another session the layer of a masked elephant was copied to other images of a completely different content.
0
Post ist für Kommentare geschlossen.
Kommentare
10 Kommentare