Serious Mask Editing Bugs
The mask editing features in COP 20 for Mac still have several major bugs from previous versions. I did a clean install of 13.0.0 per Phase One instructions and then updated to 13.0.1.
1) The Draw Mask and Erase Mask tools ignore many clicks that occur in rapid succession. This bug started with COP 11.2 and has not improved since. In May 2019, Phase One confirmed that they had reproduced this issue on both a Mac Pro 5,1 and a 2018 MacBook Pro (15,?). I have reproduced it on a Mac Pro 5,1, MacBook Pro 7,1 (COP 12), and MacBook Pro 12,1 (COP 20), with several clean installations. OpenCL has no significant effect. My first impression is that it is worse with 20 than with 12.
This seriously hampers my editing due to the need to slow down when drawing a mask. Freehand drawing works fine, once I can get it to start, but is not suitable when masking architectural elements (my primary work). This image shows the results:
https://mattvarney.com/miscimages/cop-missedclicks-20-01-01-sm.jpg
Top line results from Shift-clicking slowly. Bottom line results from Shift-clicking at a reasonable pace.
2) The Draw Mask and Erase Mask tools randomly copy settings from one another, even though "Link Brush and Eraser Settings" is turned off.
This started with 12.1. This has always been hard to reproduce in a video. This video is from version 12 and shows the behavior (it took several tries on different days to get this, even though it happens quite a few times every day):
https://www.youtube.com/watch?v=tqzpk_ATKjQ
In build 13.0.1, this happened several times within a few minutes. It still seems completely random. This is a different system from the one where I initially discovered the issue. So far, it is happening on two Mac Pro 5,1's and a MacBook Pro 12,1. Note that I almost always use the Shift key to constrain my drawing. I don't know if this is relevant, but consider it if you decide to test this issue. Phase One hasn't reproduced it yet, which is strange since it usually happens to me within a few minutes on all three of my systems. It happens less often while doing a screen capture.
So, has anyone else seen these? If you've seen #2, have you figured out what seems to trigger it?
Thanks,
Matt
1) The Draw Mask and Erase Mask tools ignore many clicks that occur in rapid succession. This bug started with COP 11.2 and has not improved since. In May 2019, Phase One confirmed that they had reproduced this issue on both a Mac Pro 5,1 and a 2018 MacBook Pro (15,?). I have reproduced it on a Mac Pro 5,1, MacBook Pro 7,1 (COP 12), and MacBook Pro 12,1 (COP 20), with several clean installations. OpenCL has no significant effect. My first impression is that it is worse with 20 than with 12.
This seriously hampers my editing due to the need to slow down when drawing a mask. Freehand drawing works fine, once I can get it to start, but is not suitable when masking architectural elements (my primary work). This image shows the results:
https://mattvarney.com/miscimages/cop-missedclicks-20-01-01-sm.jpg
Top line results from Shift-clicking slowly. Bottom line results from Shift-clicking at a reasonable pace.
2) The Draw Mask and Erase Mask tools randomly copy settings from one another, even though "Link Brush and Eraser Settings" is turned off.
This started with 12.1. This has always been hard to reproduce in a video. This video is from version 12 and shows the behavior (it took several tries on different days to get this, even though it happens quite a few times every day):
https://www.youtube.com/watch?v=tqzpk_ATKjQ
In build 13.0.1, this happened several times within a few minutes. It still seems completely random. This is a different system from the one where I initially discovered the issue. So far, it is happening on two Mac Pro 5,1's and a MacBook Pro 12,1. Note that I almost always use the Shift key to constrain my drawing. I don't know if this is relevant, but consider it if you decide to test this issue. Phase One hasn't reproduced it yet, which is strange since it usually happens to me within a few minutes on all three of my systems. It happens less often while doing a screen capture.
So, has anyone else seen these? If you've seen #2, have you figured out what seems to trigger it?
Thanks,
Matt
0
-
this sounds like a stupid question - but where is you Mac Pro placed ? under a desk, close to a wall ? because I did experience blue tooth issues with apple hardware which had had been related to a weak BT signal in the past and maybe you have done this already but can you reproduce the problem with different mouse BT/ USB too ? 0 -
This bug has been around since v9. I notice it when I click quickly to enable/disable exposure warnings. Support did verify the bug in version 9, but has yet to do anything about it. It appears as if C1 is dropping events from the event queue if things happen in quick succession, but that's just a guess. Since the bug has been verified and not been fixed for several years, the only solution seems to be to just slow down and not stress the software.
- Ken0 -
Out of curiosity, I went back and reviewed the problem report I submitted (discovered in v10 and submitted in v11). The response from support (extracted) is as follows:
Not really a bug, as 90% of the time when I tested, it works just fine. I will report to R&D anyway for further eval.
Hard to believe, but that response does provide a clue as to why so many issues still exist. It also makes me wonder what the failure rate has to be before it's considered a bug.
- Ken0 -
macbates wrote:
Out of curiosity, I went back and reviewed the problem report I submitted (discovered in v10 and submitted in v11). The response from support (extracted) is as follows:
Not really a bug, as 90% of the time when I tested, it works just fine. I will report to R&D anyway for further eval.
Hard to believe, but that response does provide a clue as to why so many issues still exist. It also makes me wonder what the failure rate has to be before it's considered a bug.
- Ken
A bug, in theory, is ideally something that never works and so can be more readily identified (hopefully) and any attempted rectification can be tested consistently and confirmed fixed.
Anything that is inconsistent - even at 10% perhaps - is likely to be difficult to pin down or, perhaps especially in cases like this, more a matter of hardware and software interaction and subject to the huge number of variables that might involve.
FWIW I have never noticed either of the problems reported by the OP - but then my usual usage is not the same and so may not be subject to the same challenges.
And, of course, I may simply not notice any changes related to item 2 as I rarely set anything specifically different enough for it to become a readily obvious problem.
In addition I am running C1 on a PC with Win 7 and about 7 years old now so things may be very different under the hood.
I'm also using the touchpad rather than a mouse or graphics tablet. Might that also have any significance?
Grant0 -
SFA wrote:
A bug, in theory, is ideally something that never works and so can be more readily identified (hopefully) and any attempted rectification can be tested consistently and confirmed fixed.
Anything that is inconsistent - even at 10% perhaps - is likely to be difficult to pin down or, perhaps especially in cases like this, more a matter of hardware and software interaction and subject to the huge number of variables that might involve.
Luckily, we all get to have our own definition of what a software bug is and isn't. To me, difficulties often involved with reproducing the unwanted behavior are actually orthogonal to the bug/not bug. In my book, a bug is always caused by a programmer not coding functionality according to the software specification. That is all.
Software specifications are hard to get right, and I see all to often software designers using words like "simple", intuitive", "fast" and other wishful adjectives in specifications. The programmer is of course then free to code functionality to be "intuitive" (or "simple", "fast", "good" and what not) in the programmer's own mind. That may differ from the designer's mind and intentions. Design flaws can be quite a headache to fix later. In my experience, bugs, where program code violates specified functionality typically involve less side effects and are more easily fixed.
The word "bug" is somewhat misused to describe software that does not function the way a user expects it to, as opposed to not function as specified. Who can tell a bug from a design flaw without knowing the written design specification?
Alas, both bugs and design errors may show up intermittently and inconsistently and be difficult to pin down. But more or less difficult does not spell "bug" or "not bug" to me.0 -
Horseoncowboy said: this sounds like a stupid question - but where is you Mac Pro placed ? under a desk, close to a wall ? because I did experience blue tooth issues with apple hardware which had had been related to a weak BT signal in the past and maybe you have done this already but can you reproduce the problem with different mouse BT/ USB too ?
Not a stupid question. 😊 However, the missed-clicks bug has been extensively tested with several very different mice and a Wacom tablet, all of them wired, with essentially the same results. It also happens on three different MacBook Pro models (2010, 2015, 2018); at least two of those were using the built-in trackpad. The other one belongs to Phase One.
macbates:
While there were similar problems in v9 and perhaps before, this specific behavior started in v11.2. I think it was macOS Sierra that first allowed mouse report rates above 60 Hz (?). Capture One apparently didn't filter the queue, so the higher the mouse Hz, the longer the delay in mask editing (I verified this with a gaming mouse that had adjustable report rate). I reported the problem to Phase One, and shortly thereafter the new behavior appeared, which responds quickly but misses some clicks. They acknowledged the bug and said that a team is working on mask editing, which "could take some time". That was in the middle of 2019.
The Windows version was already fine with high report rates, and still doesn't miss any clicks, as near as I can tell. Unfortunately, it has other annoying bugs, which were confirmed about 11 months ago and not yet fixed. And those are in the 100% reproducible category. : )
My impression is that they don't often fix something unless it seems to affect lots of people. So if you see these issues, you might consider dropping Support a line. 😉0
Post is closed for comments.
Comments
6 comments