Users on Apple Silicon Macs, have reported seeing black rectangular areas covering their output image. This usually occurs when using PixelSugar as a Photoshop plugin, or via Lightroom, but also has been reported when using PixelSugar as a standalone app. We have no reports of this issue affecting Intel Macs. The location of the black bars is random, but looks something like this:
Is there a solution?
No (and I'm genuinely sorry about that). We have spent a LOT of time trying to fix this problem. As of now, we have no solution, and we aren't actively looking for one. We are, quite frankly, out of ideas. Several users have generously spent a great deal of time trying to help us reproduce the issue. We've run through every reasonable lead and idea we have, and reached a dead end with each one.
Because this only happens on some computers, I'm inclined to think this is an issue with Apple's hardware. Yes, this does happen, expensive and reliable as the computers tend to be. But software issues tend to be reproducible on two different computers with the exact same configuration. This issue doesn't behave that way. We've tried reproducing it on the same model of Mac, with the same software and OS as affected users, to no avail.
What can I do if this issue affects me?
The best we can do at this point is offer a refund (open a ticket if this is you, and attach some examples).
You can also try contacting Apple for support, and having them test your hardware. Most machines affected are probably still under warranty.
(I would say reset NVRAM, but apparently that's not a thing on Apple Silicon. You can also try booting in safe mode)
Are you sure you've tried everything? What about (insert idea here)?
Yes. Pretty sure.
Warning - it's about to get nerdy in here. Unless you're morbidly curious, love software development, or think I'm just BSing you, feel free to check out here, because this is where I'm is going to get long-winded and technical and just dump all I know about the problem. Maybe it will help someone in the future. Idk. But we're about to transition from a help article to a confessional / blog kind of thing.
First of all, we have done everything we can think of, short of rewriting large chunks of the app (which, honestly, would just be throwing pasta at the wall to see what sticks. I have no reason to believe this would help either). Second, similar issues have occurred with other apps, including Apple's own Preview app (links: 1, 2, 3).
What do I think is happening? My hunch is that chunks of the output image are ending up with a value of 0 in the alpha channel. Some users are seeing this issue within the PxS interface itself, and in those cases, the blank areas are white, not black. This makes sense, as PixelSugar renders directly to a MetalKit view, which MacOS (presumably) just shoves into a CALayer backing store, and when it's composited into the view, the 0 alpha value causes the white pixels of the PxS background to show through. When exporting back to Photoshop, we use a TIFF container with RGB format (no alpha channel), so the output image ends up with a solid black. So the "0 alpha" theory explains the behavior I'm seeing.
How are we getting 0 alpha in giant chunks of the image? That's the question. There's no reason for this to happen intermittently and at random unless the GPU is misbehaving. We aren't messing with alpha values. It could also be a bug with Metal, Core Image, or some other low-level Apple code. But for it to happen only sometimes, on some machines, and in random image locations would suggest this is an Apple problem that we really can't solve.
The squares look like (potentially) the size of a single tile that would be processed by the GPU in one pass, though it's hard to gauge this. We had a similar issue with PicTapGo years back, which has similar render code. In that case, a divide-by-zero in the GPU shader was causing the GPU to just panic and give up for the whole tile it was rendering, returning a black square for the whole tile. The results looked like this bug. I tried testing this by forcing a divide-by-zero in our shader code, but apparently that just creates black output on individual pixels, rather than whole tiles. I assume this is just a difference between iPhone and Mac hardware. Also, this problem is random, and occurs before we even apply any processing. Also, I've scoured the shader code looking for places where we potentially divide by zero, to no avail. Also (also also), if that was the issue, I would expect it to occur more consistently, and to have been a problem years ago (though I suppose it could be some new unique facet of Apple Silicon GPUs that I somehow can't reproduce).
I also thought maybe the Metal texture we're rendering wasn't being properly configured in some cases. I double-checked all the things we could configure, given our Core Image via Metal rendering, and came up with nothing. This is speculating a LOT about what Core Image does to render via Metal, but assuming texture memory is initialized to all zeros (memory for render targets might not be initialized at all - we may just write to it), and assuming we don't touch the alpha values, it's possible we end up with RGB data in the output texture, but an alpha of 0 anyway. This would require memory to be treated differently in some cases than others, but assuming 1) Core Image maintains a pool of textures for rendering, 2) they aren't initialized before writing to them, and 3) some of those were recycled from other operations that did have a 1 value in the alpha channel, then it's possible we'd end up with a texture pool where some textures had 0s, and others had 1s, and we were just reusing the alpha value in the texture. I even wrote a shader to explicitly set the value of the alpha channel to 1 as a final step. The problem persisted.
Given that the issue has been reported in the PxS preview itself, my next best theory is out, but I investigated it anyway - which is that there's a data race causing the output image to be pulled from its GPU texture before the render completes. I still think this maybe explains the problem, but again, we haven't changed the behavior of anything here in many years, the code looks correct, and it only occurs on some machines. Even if this is the problem, we're doing the right stuff, and can't fix problems inside the black box of Apple's code.
Again, the fact it occurs in the PxS interface itself also rules out problems transferring the image to / from Photoshop, but I double-checked all that code as well (old and crusty as it is - Photoshop FilterRecord is barebones C, written against an API that's existed since like Photoshop 4).
I've checked whether the internal grid rendering PxS does is to blame, but we only use that for the PxS preview image, not output exports, so that can't be it.
I've checked issues with colorspace conversions causing pixel values to be funny in a way that our original shader code didn't anticipate (again, something-something maybe it's a div-by-zero or whatever). No problems there.
Long story short, everything we reasonably have control over, I've spent a LOT of time investigating.
I can think of basically two avenues that might fix this problem. Both are more work than we are going to do (like, a LOT of work). Neither is guaranteed to solve the problem. And they could make things worse.
The first is to enable a software rendering path. Core Image supports this. It would be painfully slow. Mostly, however, the entire app was written with Metal in mind. There's no easy way to just move PxS code of the GPU, short of rewriting about 1/3 of the app (and again, it would make it unusably slow).
The only other avenue I can think of is that maybe there are some bugs lurking in Apple's implementation of GLSL for Apple Silicon. PixelSugar was written before Metal Shader Language would do what we want (if I recall it didn't have enough backward compatibility at the time, for our target devices and OSes). So all the shader code in PixelSugar is still OpenGL shader code. This is deprecated now, and it's possible that there's some quirk or bug lurking there, which we're only hitting because we're using a deprecated init method for CIKernels (and again, this would have to be a really subtle thing that only creates the issue on some Apple Silicon machines). Even investigating a fix here would be rewriting a LOT of code, and we just aren't going to do that, given where we are in the product lifecycle.
So that's it. Hopefully the problem magically solves itself someday. If it's an Apple issue, maybe some graybeard engineer will be poking around deep in the Metal GPU driver code and find some line that looks out of place, and viola, things work. But I suspect this is just a matter of "some particular Apple Silicon devices have a very specific hardware problem, which PixelSugar is just prone to tripping." Life is full of mysteries, and too short to solve them all.