I got asked by Dantesoft if I could share my photo processing workflow. Of course I can! It used to be quite elaborate, but these days it is quite simple.

Asset Management

The first thing to consider is where your photos will end up. After many different configurations I have ended up putting everything into Apple Photos. There are three reasons I ended up here:

1. It lets me carry my entire library with me, on one or more devices
2. Basic versioning, letting me store the original photo while still only seeing the edited version
3. Live Photos and good video support

In addition, I also appreciate the “Moments” feature, where it creates contextual albums from metadata. It is not all roses though. The biggest downside is that the ecosystem lock-in is strong. If I want to switch to another digital asset manager I might end up with duplicates and odd formats. I trust that Apple will keep making a photo app for the foreseeable future, as it currently is a crucial part of their ecosystem package.

Update: After I wrote this, Adobe published an update to Lightroom CC with migration support from Apple Photos.

Importing

Not all images will be processed, and not all images will be processed equally. Non-RAW photos (live photos, iPhone portrait shots) will lightly be edited in the Photos app. This typically means cropping, sometimes adjusting white balance and exposure compensation.

With RAW images things are a little more elaborate. I copy them to my computer through Adobe DNG converter, making lossy DNGs without fast load data or previews. This is done to reduce file size.

A word on Lossy compression

Photo enthusiasts seem to hate lossy compression. The word “lossy” make their hairs stand up. I don’t suffer from this condition. Files from my Fujifilm X-100F will be reduced from near 50MB to less than 10MB using lossy compression. Many think of JPEG, but lossy DNGs are very different.

The key advantage is that DNGs are scene-referenced. This means the white balance is not locked, as more color information is stored. The value of changing white balance in post production cannot be overstated. The extra color data stored also increase editing latitude, compared to JPEG files.

There are other aspects to lossy DNG, like how it deals with being 8-bit and noise shaping, but that is not important. The takeaway is that if you are fine with 99% of the quality and editing latitude, lossy DNG is fine. If you lose sleep over not being able to change the demosaicing algorithm later—it is probably not for you.

So the conversion is step one.

Then I import them into Apple Photos. After importing I use the External Editor for Photos extension to open the RAW in Photoshop. This triggers the Adobe Camera RAW (ACR) interface, which is where I will post-process the image.

Processing

I shoot a lot of indoor shots in “interesting” lighting, so white balance is usually a little off. My preferred way to white balance is to aim for optically correct skin tones. If possible I will use the eyedropper on a grey or white piece of cloth near the face. Should there not be anything useful near their face I will sample the white from their eye. Afterwards I adjust to taste.

Most of my shots are cropped to a 3:2 grid. Occasionally I give 1:1 or 2:3 a shot, but to me, nothing feels like a photo like 3:2. When cropping I align points of interest to the 3×3 grid.

Noise reduction and sharpening depend on gear. I will typically apply color noise reduction until there are no more bayer/x-trans filter artifacts. Luminance noise is in most cases pleasant, but sometimes it distracts from the subject and has to be toned down.

If the sky is too bright compared to the rest of the image, I might apply some masks sky (I am way too lazy to carry a polarizing filter anymore). For portraits with noisy surroundings a vignette I sometimes add a vignette, but most cameras will suffer a bit of vignette from the lens. I in many cases it is preferable to not correct that. I correct lens distortions when it is unflattering or there are obviously straight lines that suffer.

As a bonus step, I will usually apply a Fujifilm film simulation from VSCO. Once satisfied with my edits, I will export a full-resolution JPEG in sRGB and drag that into the External Editors extension.

And that’s it!

For every page you visit in Vivaldi a color is selected. Currently, the engine takes two types of input—a favicon and meta theme-color.

The ten most frequently used colors are extracted from the favicon, resulting in a list of up to 11 (including theme-colour). They are then rated by the following criteria:

• Is the contrast good enough?
• Is the color a midtone?
• Is the color saturated?

A perfect score here is not very hard to get and will give a color 150 points. Additionally, the top three colors are given a bonus multiplier. After all, it means they occur more frequently in the favicon, so they are more likely to be relevant. If present, the theme-color is given an additional bonus.

The winner is the color with the highest score. Changing the Vivaldi theme or contrast requirements can impact which color will be chosen. In practice, the theme-color will win, unless it is a bad match.

Here is an example of how this works in practice. Note there is no theme-color, so the most frequently occurring color receives a 2x multiplier. Still, it manages to lose to the second most frequently occurring color, as that one receives additional points for saturation. This is a good example of why saturated colors are rated higher.

 

Here is an example of what happens when the page author has specified a theme-color. It receives a 3x multiplier and wins over favicon colors—by a wide margin.

The latest Vivaldi snapshot improves scrollbars in our UI. We draw them ourselves instead of using the system ones, as we want to support theme colors.

Styling scrollbars is a little tricky since they hide in the shadow DOM. On Mac, the scrollbar would be painted on top of the border surrounding text areas. When their corners were sufficiently round, they would clip it.

Due to the limited styling options for scrollbars, it is not possible to set the width of the drag handle (called thumb in CSS). We worked around this limitation by letting the border be the same color as the background. We can set the border to be transparent, but that will defeat the purpose, as the background will be extended and painted in place of the border.

The solution we ended up with is using the CSS property background-clip, which lets us clip the background to where the border starts. We use this in a couple of places to achieve complex designs without additional elements. The result is properly rounded scrollbars on mac.

On Windows and Linux, the scrollbar buttons (up, down, left and right) are now rounded as necessary—to not clip the text area borders. This snapshot also added in missing buttons for horizontal scrollbars. We try to prevent horizontal scrolling, but when we have to scroll there should now be proper buttons.

PS: This is my first blog post here. The plan is to try writing a little about bugs or features I have worked on.