Posted: 13 Jan 2019 04:30 AM PST
In the first article in this pair, I proposed the hypothesis that all representational paintings appear chaotic, even abstract if you must, if you zoom into them closely enough. But as you zoom out you reach a point where their marks organise into an image which our brains see as representing the tangible or imagined. If you’re looking from afar at the whole painting and this fails to happen, then you can be confident that it is truly abstract art.
Here, I present a series of images for paintings from five masters who worked in very different styles and periods, which should help illustrate my point. The five are:
I start with Rembrandt. Late in his career, after about 1650 in particular, his method and style of painting changed quite markedly. His paintings came to create visual effects as much by surface textures, as by form or colour.
Some modern painters have argued that the marks made by Rembrandt, as they appear to be abstract in character, foresaw and gave precedent to abstract painting. Nothing could be further from the truth, of course: the driving force behind this making of marks is to create the overall, thoroughly realistic, illusion, but by means other than mimesis in detail.
The width of this close-up view of fabric is about 30 cm (12 inches). There is a wide range of different types of mark, and degrees of organisation in different parts of the paint layer.
A similar-sized area from another fabric shows very different structure and texture.
When viewed overall, seemingly chaotic and disorganised marks assemble into rich fabric textures, jewellery, and more. Seen in real life, this painting has a unique reality as a result of this fine structure.
Here is another example of his approach to detail in clothing, this time from his earlier Bathsheba with King David’s Letter from 1654.
Here’s a similar series looking at the facture in Léon Bonnat’s Arabian Sheikhs in the Mountains from 1872. Although known as an academic painter, Bonnat’s brushwork, in this work in particular, is remarkably rough when viewed close up.
This is an area of about 10 cm (4 inches) across, which appears as rugged as the landscape which he was painting.
Zooming out gives a better idea of the very wide range of marks he has employed, from strokes with dilute paint to dry scrubbing and textures.
High chroma clothing is rendered very loosely, and the whole starts to resolve into the more intelligible at last.
By way of complete contrast, here is one of Gérôme’s exquisitely detailed realist paintings showing a trading scene in Cairo: The Carpet Merchant from 1887, just over two centuries after the death of Rembrandt.
This fine detail view shows an area which is about 15 cm (6 inches) across, into which Gérôme has packed amazing detail. The complex pattern is clearly that of a woven tapestry or carpet, and there is no suggestion that this image was created in paint, nor of the tools used to form the paint layer.
The whole painting is almost photographic in its detail, and in his later career Gérôme was an active photographer, who encouraged the adoption of photography as a new art form.
In his portraits and finished paintings, John Singer Sargent was also a realist, but when sketching, particularly in watercolours, he could be exceedingly gestural. Here is one of his minimalist watercolour sketches, painted in 1905-06, in which he assembles watercolourist’s marks of apparently ‘abstract’ form into a highly representational painting.
This close-up view is about 12 cm (5 inches) across, and shows Sargent’s rich watercolour technique, founded on marks made using a brush loaded with pigment suspended in water. There are reserved areas of unmarked paper, strokes painted onto wet paper, those applied when the paper was essentially dry, superimposed strokes, varying density of pigment and loading of the brush. In this example, Sargent hasn’t used wax resist, which was one of his favourite techniques.
The end result, at this level, appears quite random and with very little structure.
Once our brain has the whole image, it suddently ‘pops’ into a convincing and quite three-dimensional object, and its reserved space and brushstrokes form a white chador.
My final series of images comes from one of Paul Cézanne’s late landscapes, Forest Scene (Path from Mas Jolie to Château noir), which was actually painted slightly earlier that Sargent’s watercolour sketch, in 1900-02. By this stage, Cézanne had developed his characteristic ‘constructive strokes’, blocks of several parallel brushstrokes from which he built much of his paintings, particularly passages representing foliage.
In the twentieth century, it was claimed that Cézanne’s constructive strokes were a direct precedent to Cubism and abstract art. This painting, at least, appears to be representational when it is examined at multiple levels across this series of images.
In this close-up view, the width is about 25 cm (10 inches).
This is not a painting which can be read well when close, even looking at the whole. However, Cézanne’s distinctive constructive strokes form convincing vegetation and foliage without overwhelming the eye with detail. There is no doubt that this is intended to represent a path receding into a forest. It is not abstract.
Although many artists stand back to assess the overall look of their work in progress, most work well within arm’s length of their paint surface. One notable exception to this was Joaquín Sorolla, who had special brushes made for him with handles a metre or more in length so that could paint very large canvases at a distance; Whistler is also known to have used very long brush-handles.
The great skill of each of these masters is that when they painted they could only see their marks; it was not until they stepped well back that they could see what they were accomplishing. This requires the painter to have a very detailed mental image in which those marks are assembled into the whole. That may, in this respect, be the very mark of genius.
Posted: 13 Jan 2019 12:00 AM PST
Which do you prefer: a vivacious sketch of a landscape dashed off in an hour, or the painstakingly polished painting with the finest detail captured to perfection? What you’re getting in macOS is increasingly like that sketch, and not so finished in its detail.
Last week this hit home when I stumbled across a family of buglets in handling Finder Aliases. The biggie is serious, and will freeze the Finder in circumstances which are by no means uncommon. But alongside it there are two other bugs which you’re less likely to bump into. Chances are that those two will never be fixed, except by eventual replacement.
The serious bug means that the Finder can’t properly handle Aliases to folders which have become broken. Select such an alias in a window which doesn’t try to list the linked folder’s contents, and nothing seems wrong. If you use Column view instead, when trying to list that folder’s contents, after a few seconds grace, the Finder becomes unresponsive. You then have to press Command-Option-Escape and force the Finder to relaunch.
Next to appear, and apparently going back before Mojave, was a tendency for Finder windows to close abruptly when handling the dialog to delete or fix a broken alias. This isn’t as consistent, but trying to open a broken Alias produces a dialog offering you a choice of three buttons, to delete the broken alias, to fix it by finding a new target for that alias, or to dismiss the dialog. Choosing the latter is likely to close the window, which isn’t intended.
The third is more arcane, very unlikely to occur in normal use, and highlights a shortcoming in design. It’s possible, if you’re very careful, to ‘spoof’ a Finder Alias to point to an identically-named file which is different from the original. But when you select that Alias in the Finder, because it normally caches both thumbnails and previews of files, QuickLook may not recognise that the target document has changed, and display the original instead.
What is important about these three bugs is that none affects the core feature which resolves an Alias. Anyone claiming that this phenomenon is ‘core rot’ should reconsider that term, as the great majority of bugs in Mojave don’t affect its core functions. The end result is not deterioration in macOS itself: after more than three months working in Mojave’s release versions, overall it is the best version of macOS that I have used since before El Capitan.
Your mileage will, of course, vary. But my newish iMac couldn’t run El Capitan for longer than a few days without freezing completely in a kernel panic, it had to be restarted every week or two in Sierra because it stopped making Time Machine backups, and its Fusion Drive couldn’t run High Sierra’s APFS at all. For all its surface blemishes, Mojave has been a walk in the park.
Given the sheer size and complexity of macOS with all its supporting components and libraries, is it realistic to expect it to ever become free of noticeable bugs? We don’t have figures for macOS, but when Linux kernel 1.2.0 was released in 1995, its source was a little more than 300,000 lines. Last September, the source code of version 4.14.14 was estimated to contain over twenty million lines, and would have cost more than $14 billion to rewrite.
Our expectations of software haven’t changed, though. We judge by comparison with far simpler products, such as apps, consumer goods, and cars. Although these might seem complex, a better parallel would be a sizeable city. At any given moment, there will be buildings in disrepair, potholes in the roads, and dysfunctional zones. Some we even view as quaint or atmospheric because of those flaws, much as in the aesthetics of the painterly sketch.
I’m not advocating acceptance. Where apps are severely dysfunctional, as the App Store is in Mojave, we need to tell Apple that they need substantial further investment. When Photos was first released, it was shockingly underpowered and unreliable, but has steadily evolved into an app which many of us trust with tens of thousands of our images. It’s still far from perfect, and I regularly recommend those who are pushing it to its limits to consider alternatives, but Photos has gone from weed to staple.
A large part of the problem is the annual development cycle for macOS and iOS, but that is also their salvation. When Apple gets it right, troubled apps and components within macOS will be re-engineering in the next cycle, and most of those old problems should disappear – some to be replaced by new bugs, inevitably.
The biggest difference between macOS and a city is our insight into what’s going on with the latter. Before an area is redeveloped, plans are put before the public and debated. When work starts, we can see what is going on, and follow it through to the finish. At present, all those using Time Machine know that it needs to be revised to make its backups on APFS volumes, in what I have dubbed Time Machine 2.0. We have no idea whether Apple’s engineers are tackling that yet, or when it’s likely to appear in macOS.
Some changes coming in the future, such as loss of 32-bit support, have been announced, but we’re not told of when they will happen, nor whether macOS will offer any option to be able to run 32-bit apps in the future. Any city planner doing the same would face public outrage.
The closest that we get is the annual WWDC at the start of June, although it places greatest emphasis on introductions rather than redevelopment. Wouldn’t it be good if Apple spent more time and effort showcasing more of the efforts of its engineers in revising and improving existing areas within its operating systems? We know, for example, that many components have been ported to use Apple’s new lingua franca Swift, an investment which Apple should be as proud of as it is of new features.
In the nineteenth century, the Impressionists and others convinced the public to pay for sketches which in previous eras wouldn’t have left their studio. It was a major change in aesthetics, something which Apple could achieve with macOS too.
|You are subscribed to email updates from The Eclectic Light Company. |
To stop receiving these emails, you may unsubscribe now.
|Email delivery powered by Google|
|Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States|