marcedwards

>I don’t know how effective adding noise in 8 bits is. It’s better to work in a higher bit-rate colorspace, and only dither at the last second when converting the final to 8 bits.

Yes, I completely agree. Injecting white noise is a pretty terrible way to avoid banding, given there’s better dithering options available. The blur should be a shader, and the dithering could be done within the shader as long as it’s not error diffusion dithering. I don’t really see why there would be a big perf difference. I think even pattern dithering with a small kernel would give better results than white noise.

I hope this article series helps. My goal was to cover colour management in a way that everyone can understand. If it doesn’t, please feel free to ask questions (I’d love to know where the article fails).

https://bjango.com/articles/colourmanagementgamut/

Yep, for shadows and in other places, single percentage changes can definitely be visible.

You’re right, and I have no idea. I hope that gets fixed for you!

My main issue is a bug that was introduced a few versions ago — if “Grids in Back” is turned on, the entire app crawls and is completely unusable. Like, multi-second delays between clicks. Having grids on and in the background is entirely how I used to work. Now I can’t.

>professionals are going to want to see the rounded “actual” values

Ideally, a generalised design tool should cater for rounding to 8bit and other meaningful precisions, or keeping source data intact.

All we’re talking about is _allowing_ for a user to type in a fractional number, and for it to be kept. It’s not a difficult request, and it doesn’t negatively affect normal use for people who don’t even know the feature exists. They can continue typing in integers.

If we’re talking about software design, it’s likely that in many situations the buffer being rendered into will be deeper than 8bit per channel, so even covering 0-255 is not enough.

That’s a great example. I wish I used it in the article.

I use those shortcuts as well, and often change things in 5% or 10% jumps. This is a really deep topic though, and some of the issues are from cumulative rounding errors, which can happen if you stack lots of layers or stack layer effects. It’ll also depend if you’re just moving sliders around until things look good (which is great!), or if you’re doing something that require exact values (building LUTs to process map tiles etc).

My main concern is that information is being thrown out at the input UI. As far as I can tell, Illustrator stores opacity as 8bit values internally. This can be tested by using the blend tool on objects with similar opacities.

I just want our tools to be better.

Sure is!

Interestingly, Acorn can show the full 0-255 range.

There can also be cumulative rounding issues if you’d stacking lots of layers on top of each other. It’s a subtle issue, but a strange one. There’s no deep technical reason for it — the inputs are just losing data.

>Because the author assumed 8-bit color channels at the start

The tools tested predominately use 8bit per channel. Photoshop and Affinity Designer can use 16bit int or 32bit float, but those modes are typically more for photo editing.

>Having 10k steps to control the opacity of an 8-bit overlay is wasting a minimum of 5 bits.

The article does allude to why more may be important: “There’s no real reason to not support the full range of possible 8bit opacities, or even more steps to cover wide gamut colour spaces and higher bit depths.”

CSS, iOS, and Android dev all typically just use floats with a normalised range for opacity. The future is likely using normalised floats for all colour values, like many platforms already do. This also allows for extended ranges beyond 1.0 for wide gamut support while still using sRGB.

Wide gamut displays are prevalent, as is sending 10bit per channel to the display (often with a 16bit float per channel window manager). It just seems weird for our tooling to clip this stuff at the input. That’s such an easy thing to fix.

>It would be nice to have more examples where single bit precision is necessary, and a demonstration of a visible problem that crops up if the precision is too coarse.

I think there’s lots of examples, but some are going to sound contrived.

Here’s one that didn’t make the cut: Illustrator’s blend tool creates intermediate objects by morphing the paths and properties. This is a common way to make gradient-like effects. Object opacities are also interpolated. What’s interesting is that Illustrator has 0-255 precision when doing the blend, but if you edit the objects, you’re the values display as 0-100 and edits will snap to 0-100. I didn’t include it, because it got messy explaining the finer details.

Yep, that’s my understanding as well.

Yep, that’s an option as well, and some tools do it. Figma’s only layer opacity slider is via holding a modifier and dragging the text input field.

I personally like having opacity sliders as well. They provide a nice visual representation of the state that’s easier to parse than reading a number, and you can also do things like set 100% with a single click. Layer opacity is important enough that it should have a text field, a draggable value with a modifier, and a slider.

The other main point of the article is that these tools don’t seem to even realise their precision sucks.

Which search would you lose? Their iOS app has search, and on macOS your can use Finder’s search. I assume there’d be ways on Android, Windows and Linux as well.

Actually, I just checked and their Mac and web apps also have search.

I moved to Tresorit, and so far it’s been great. It’s end-to-end encrypted/zero-knowledge. The service is a little bit enterprise-y, but really solid. I’ve done all I can to test and and haven’t been able to flaw it. Merge conflicts end up as duped files, just like Dropbox, which is great.

Their Mac app is good. It’s native and doesn’t use a ton of resources (I haven’t used it on other desktop platforms). AFAIK, it doesn’t support APFS extended attributes, so Finder tags won’t get synced. It does use the Finder sync extension API though.

It works slightly differently to Dropbox — rather than just being a single folder that syncs, it’s more like selective sync, where you have multiple folders that are optionally synced. This confused me a little during setup, but I think I prefer it now.

I tried pretty much all the other alternatives and didn’t like them. I’m already paying for iCloud Drive, so I’d love that to work, but it’s chewed up files or taken hours to sync on too many occasions, so I don’t trust it any more.

If there's bugs you care about, then you patch them. WebKit is open source, so anyone can fork it and build their own version with any fixes or changes they like. I don't see anything but positive news from this.

I guess acknowledging the issue is the first step to solving it. “Build a business” seems like a good message to repeat every now and then, just to make sure it sticks. I don't like the VC culture of planning for exit, rather than aiming for success.

I liked the article.

You've deliberately recreated someone's work with the intention of offering a competing product. Legalities aside, it's pretty damn rude. Yes, it's a rip-off. (I don't use that phrase lightly and I'm usually all for remixing, which this isn't.)