trop

If only it worked on Linux. It's Windows-only: http://bitboost.com/pawsense/.

This software is the only winner so far of an Ig Noble prize in the category of Computer Science: https://www.improbable.com/ig-about/winners/#ig2000. See https://priceonomics.com/the-software-that-detects-when-a-ca... for a write-up.

Apparently this is still maintained, as it is described as compatible with Windows 2000, XP, Vista, 7, 8, and 10 (excepting "Metro/Modern" mode). Written by this charming coder: http://chrisniswander.com/.

[edited for grammar -- and should note that, of course Linux and ilk OS do offer a "cat" command]

Two more, by authors coincidentally with the same initials:

Thinking in an Emergency (2012) by Elaine Scarry -- She argues for the importance of planning and procedure. Examples include the Swiss shelter system (civil defense), CPR training, and compacts in rural Canada to deal with grain silo fires. She suggests that careful thought before the emergency is vital for "civilization", or at lest for democratic governance. As a converse, the country is destabilized when an opportunist leader comes along, cowboy-style, and says, "This is a crisis, and I'm going to shoot from the hip and fix it". Hence it's both a pragmatic study and a lucid work of political philosophy.

Command and Control (2014) by Eric Schlosser -- This is more of an anti-study: not what to do in an emergency, but the inevitable flaws in complex systems, the limited efficacy of administration, and the inherent failings of human effort. Sort of the mirror-book to Scarry's, but also utterly fascinating. It's a history of disasters of the U.S. nuclear weapons program, and in an effort as huge as that, the disasters certainly exist at scale. (Interestingly, Scarry's book centers on the importance of governance in a nuclear state, or perhaps that democratic governance is not compatible with being a nuclear power.)

In the arts there are people working with Metafont. Check out Dexter Sinister's Letter & Spirit (2012), see http://servinglibrary.org/journal/3/letter-and-spirit then click on the PDF link.

Letter & Spirit opens by describing a dialog between Knuth and Douglas Hofstadter ("Metafont, Mathematics, and Metaphysics"). For Hofstadter's essay, see https://core.ac.uk/display/15352994 or chapter 13 (p.260 & fwd.) of Metamagical Themas (https://archive.org/details/metamagicalthema0000hofs/page/n9...).

There is also Dexter Sinister's "A Note on Type" (https://www.sternberg-press.com/product/notes-on-the-type-ti...).

All this suggests that Knuth's Metafont work has ended up being a successful provocation regarding how it is possible to encode creative design and visual language.

Not at all making light of it, but with the cats and the bats, my mind wanders to David Bowie's apocalyptic "Future Legend": "Fleas the size of rats sucked on rats the size of cats..." The lyrics actually speak to the sort of fear this elicits: "And in the death,/As the last few corpses lay rotting on the slimy/Thoroughfare ... And red, mutant, eyes gaze down on Hunger City."

The students didn't have any coding background. Which, in a way, was good -- they didn't know how absurd this was to start programming with Lisp, use ASCII art as a visual vocabulary, and use Emacs and its REPL as an IDE.

I wanted the students to gain confidence in this weird situation by working off of clear examples. Hence I made these extensive online notes.

The students were generally great at typing in these examples and getting them to run, and some were creative with rearranging them, copying in extra code, and changing variables/strings to produce interesting effects. I didn't see "coding" in the sense of having a vision/plan, finding/inventing an algorithm to realize it, and then refining the result. But I saw "hacking" in the classic sense: gaining facility with an unlikely tool, and working through variations until something intriguing occurred.

Given that it was an art class, I was actually pretty happy with this. This felt in line with what allows for a lot of good art school work: students starting out with a technique and working/reworking until it results in something satisfying or maybe even resonant. I liked how it broke the paradigm of "useful" coding. The Emacs environment became simply something fundamental and even somewhat neutral to work at.

It's quite pleasing to see this here. As noted on the page, these were notes which accompanied a class. I wanted art students to be able to write code to create something visual, and wanted them to be able to do this in an open source cross-platform environment. Emacs was a perversely appealing means.

Keeping these examples working led to discovering an obscure regression in Emacs (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22490). I turns out that, excepting animators, very few Elisp programmers need to generate zero newlines.

There are screenshots (though not animations!) in the announcement for darktable 3.0 at https://discuss.pixls.us/t/darktable-3-0/15384. The images do really help to get a sense of the new features. It's a good point that it would be great to have such images accompanying the release announcement on the main darktable site.

Culling mode, new in v3.0, allows comparing two (or more) photos side-by-side. The new version also allows for zooming in on images in lighttable mode (control-shift-scroll) when in culling mode or when images are "previewed" (full screen via the "w" key).

Indeed! The annual Christmas release. I do think it matters to note darktable yet again. This is a major release, of what has become a key piece of photographic software. It's also a wonderful example of some people deep into imaging math getting together to put some current thinking into nicely put together open source code, and a community of committed users showing up to try to understand and use the thing. One could think of it as the Dwarf Fortress of open source imaging software...

Like Lightroom, darktable handles collections of images and allows applying a recipe of alterations to tune up each image. But it is like Photoshop in that it allows a great deal of volition in what happens to the image. This is especially true in darkatable v3, which allows re-ordering of of the various algorithms (also known as the pixel pipe) which work on an image.

Unlike Photoshop, which is primarily a pixel-based editor, both Lightroom and darktable tend to work on the image in aggregate, with tools which are particularly useful to images created via a lens and digital sensor. Lightroom has a lot of its choice/sequence of tools "pre-baked", and there's a lot of wisdom in its choices.

The tools in darktable are more esoteric. They're based on a variety of traditional and recent mathematical work in image processing. It takes a bit more knowledge and taste to choose the best tools, and set their parameters well for a particular image.

Depending on hardware, you may find that the Adobe tools are a bit faster.

As a sibling poster mentions, of course darktable is open source, and not subscription-based. It has an active development community. As Pascal Obry, who managed the current release, writes in an email to the darktable list: "It is also an important release as new developers have shined in and proposed some amazing features." There's also active community of darktable users who help each other to understand how to use it to work on a variety of images. I find these discussions enlightening in order to gain a more general sense of ways to think about image processing. One home of this community is https://discuss.pixls.us/c/software/darktable.

A fair question. An easy answer is that I thought Lisp was pretty cool, and that the students were capable of it. And, pragmatically, I was experienced with it, unlike MaxMSP or Processing.

But there was something philosophical: I liked the idea of introducing them to the feel of fundamental computer science, rather than a nice layer over computers for artists. (And what artists actually use those nice layers?) I wanted them to experience an open source ecosystem (unlike Max), and I felt that the Java-base of Procesing was off aesthetically -- too many layers over the machine.

Thinking about the OP, I do wonder what it would have been like to teach coding-for-artists with Hypercard. One thing I love about Emacs Lisp is that it is only grudgingly visual. That it returns computers to something which sends output to a TTY. It gives people who have grown up with a GUI a vision of what computers were like before. I like that Emacs (and Lisp) are things with a history and touch on earlier eras of computer culture.

As an example, a decade ago I taught art students how to code. They had Macintoshes. I had them download Emacs then taught them Emacs Lisp. As insane as that sounds, it was interactive, easy to install, and interesting. They were able to write programs in the REPL after the first class. I wouldn't have dared to have put them in front of XCode or some equivalent IDE.

Google Maps would be the classic example of client-side refresh working so well that it's now the universal choice. At the time, it was a revelation, as the Mapquest-ish predecessors (if I recall) required a click and server-side refresh to scroll or zoom the map.

Of course the revelation here was that <a> tags weren't what we needed to move a map, but rather a click-and-drag plus scroll-wheel behavior to explore a huge image at various levels of detail. If the server-side page-by-page navigation paradigm is a lousy fit for information delivered over the internet, then it may make sense to re-invent the page load.

To use the language of a sibling comment, this brought things to a much more app-ish behavior. And eventually Internet maps have become, especially on mobile devices, an app. Hence the need to break server-side navigation may have foreshadowed the need to break out of the browser.

In 1991 I drove down the Natchez Trace Parkway and as the morning passed, saw car after car pull over onto the grass to the side of the road for a picnic. As a northeasterner, this was not something I had ever seen before. I'm curious if this tradition continues.

Indeed! I remember using one to print zooms of the Mandelbrot set in grayscale (highly dithered) from an Apple ][+. For speed I coded in 6502 and called directly into the BASIC floating point routines for the math. The printer would take a day or so to print a sheet worth of image. But it was a great graphic output device, far less ephemeral than the screen. It was somewhat satisfying for it to print a new row of dots every now and then, once the computer had completed some math...

Question/idea: Could a notebook-model supplant bespoke photographing processing software such as the "darkroom" mode of Lightroom (or darktable). The extant programs essentially take a lot of data (camera's raw output) and apply a configurable recipe to produce intelligible output (an image). Each recipe (stored as an XMP sidecar) is essentially a list of math operations (increase brightness, wavelet decompose, change color model, etc.) and their parameters.

Obviously a great part of why we use Lightroom/darktable is because of the speed with which the recipe-processing occurs. Plus a smooth UI, a catalog-viewing feature, and a well vetted choice of image operations. The appeal of moving this work to a notebook would be that an actively maintained Jupyter ecosystem could supplant lock-in to a specific software, and open up the underlying math magic.

At the very least, this could be an interesting platform for experimenting with image processing methods. And the reordering of cells could become a virtue, to run an image processing pipeline out of the standard order.

I'm curious if anyone has already worked along these lines. I find through a quick web search that people are doing some image processing, but more in the face detection or ML for medical imaging aspects. I see as a basic toolkit that http://scikit-image.org/docs/dev/auto_examples/ is something, though this isn't the whole range of operations needed for, say, fine art image tuning.

I received a master's degree from an art program in which the (male) professors had a great deal of license to performatively take down students, from the initial admissions interview through two years of group critiques. It wasn't unusual for a professor to reduce students to tears. Graduates of the program brought this culture to their own teaching.

Recently I worked at a school whose critiques were set up explicitly not to replicate this harshness. I discussed this with a few friends from grad school, and we were mystified: "How can anyone produce good quality work unless they are constantly being torn apart?" "Is there another way to learn besides being humiliated?" Which led us to look at each other and think, well, we certainly don't choose to live that way otherwise.

And that is the question -- and maybe we'll discover on lkml: is there a better way to create something remarkable. And to replicate that behavior in whatever projects we take on.

There's some remarkable apocalyptic imagery out and about from even earlier in the 19th century. Check out Samuel Colman's "The Edge of Doom" (a decent reproduction at https://artblart.files.wordpress.com/2012/11/colman_edgedoom...) for a striking example. From the Brooklyn Museum's write-up:

"In The Edge of Doom, Samuel Colman paints the ultimate disaster: the destruction of the world. Lightning was particularly suited for evoking the emotions of awe and terror associated with the Sublime notion of nature. Here, it strikes erratically, blasting classical buildings, carriages, paintings, and even Time (a figure with an hourglass and scythe) to create a central glowing void. All that survives is the memorial sculpture of William Shakespeare, then and now on view in London’s Westminster Abbey."

- https://www.brooklynmuseum.org/opencollection/objects/4811

On one hand, this has to have been a British communication of contemporaneous Caspar David Friedrich sublime, but there also must have been something brewing in industrial London to create fear of impending absolute destruction, and this doesn't read as Biblical wrath to me.

> their location on the water

Which I misread as "the location of their water". Which is actually quite serious. See

https://www.wbez.org/shows/wbez-news/in-dayton-ohio-an-econo...

> As states like California face major water shortages, city officials in Dayton sense a business opportunity. ... the self-filtering, self-recharging freshwater supply, along with the rivers, once made Dayton attractive to water-intensive industries in the 19th century.

> Mills, factories, and countless little breweries lined the river before Prohibition, and Dayton was a hub of innovation and wealth.

> ...

> “We’re running into limits,” says Peter Gleick, the head of the Pacific Institute, a nonprofit research organization in Oakland, California. “...In the past we’ve sort of assumed enough water would always be available, and I think we can no longer assume that’s going to be the case.”

> ...

> “Back to the midwest” — that phrase is music to Karen Thomas’s ears. Thomas is the head of water marketing for Dayton (yes, that’s actually a job).

> “We have an abundant water source,” she says. “We don’t believe that we would have to worry about water.”

> ...

> “Water is a public good, but it’s also a commodity,” she says.

> An economic development team in Dayton has conducted talks with several food processors, manufacturers, and beverage makers that could use an inexpensive and abundant supply of water. Companies that choose Dayton would face little of the regulation placed on water diversions in the Great Lakes basin; here, if you can drill a well, you can drain it.

The article continues on to pollution issues in the Midwest, so more twists ahead.

The man who self-immolated in Brooklyn on Saturday cited this among many other concerns:

> In retrospect, Mr. Morales said he knew Mr. Buckel had been upset as recently as February when he began discussing articles about the environment, for instance one about how 96 percent of human beings breathe polluted air and another about the Arctic Circle experiencing record breaking temperatures.

https://www.nytimes.com/2018/04/15/nyregion/david-buckel-bro...

> I tried a lot of variations on it and then had to concede that the person who wrote the recipe got it just right.

Part of this phenomena comes from 20th century cooking (especially for sweets): the ingredients are mass produced to high standards of consistency, and hence there may be one just right recipe (especially if you're backing in a climate controlled kitchen at sea level). Consider, instead, artisanal bread baking in 2018. Your flour comes from a food coop which used to get it stone ground by an Amish cooperative, but now switched suppliers to a local farmer -- and the recipe needs to change. Your sourdough starter turned acidic because you went away on vacation and it sat in the fridge -- change the recipe again! It's an unusually damp and chilly day, and the loaf is sitting out during its second rise -- you'll need to change the recipe!

Of course this is part of the thrill of this sort of baking -- that you have to understand the underlying processes, not just the well-made building blocks, to end up with good results. Sort of like switching from running OS X or Windows to, say, Linux from Scratch...

> “It’s an asset class like any other” says a lot about how market economics affect people’s conception of value.

Indeed. There is a strong argument (does this go back to Kant?) that art only "works" when it is not pragmatic. That a tool is not art, no matter how elegant and functional. Hence, if art nowadays works primarily as a financial instrument, it is not actually free to do the work of being art. If an art fair is visited with an eye to current and potential economic value, and the art at the fair is represented and even made with that eye, then it ceases to have the "that image saved my life on a sad day" or "I see in that painting the terror and fragility of existence" or such energy that we actually seek in the arts.

(Of course, you could argue about whether anything pragmatic is not art, e.g. that industrial design is art. And things get really slippery with ceramics. As the article suggests, much great art has been made within very strict economies, often via commission. But a well made bowl or a portrait of a bishop are still not asset classes...)

> the gallery usually does a LOT for their 50%. Basically they take over the "business development" work -- all the schmoozing, the selling, the legitimizing.

This, of course, varies. An interesting/tricky part is that the gallery acts simultaneously as a manager, agent, and distributor of the artist's work. Imagine if Brad Pitt worked with the same company to handle his day-to-day affairs, negotiate his fees, and then sell the resulting movies. Not saying it's a conflict of interest, but it is an oddity of the art market.

In addition, darktable has a newer perspective correction module which does a nice job of automatic fitting. See the write-up at https://www.darktable.org/2016/03/a-new-module-for-automatic....

I can't speak too much to the question of speed, except to say that my nice laptop from 2012 is sluggish with darktable. My decent desktop from 2017 is fairly fluid. Neither has a graphics card, but a decent graphics card with OpenCL support makes things much more fluid. Waiting a minute for a simple operation is not something I've experienced, and suggests, as they say, that something, somewhere, is wrong.

As another commenter writes, the problem is that darktable must do a crazy lot of math to display the image -- every step of the image editing process. There is a good bit of caching along the way, but at some point, the math must be done.

Hence the first lazy evaluation example becomes something like

  import itertools
  list(itertools.islice(itertools.count(),10))

Though perhaps there is a more elegant (if not more efficient) way to do this?

Then there is Ze Frank's classic trilogy:

http://www.zefrank.com/christian/ http://www.zefrank.com/buddhist/ http://www.zefrank.com/atheist/

Much less good experience here on Z3C return. First failure (randomly lost network, etc.) they repaired it, but it came back with more things broken. Returned that one and got a new one with a badly glued screen. Used until screen cracked, then returned it. They held onto it for a few months while they moved their warranty service from El Paso to the Midwest. Then returned it unrepaired with a won't fix note...

Back in the day (we're talking 80s) I wrote similar postscript (I remember also some sort of Douglas Hofstadter-esque strange attractor?). The argument for doing this was entirely practical: The Apple LaserWriter in the computer lab had a 68000 processor, which was a darn lot faster than anything else in the room, plus the only way to do high-dpi raster output.

It uses lensfun. See http://www.darktable.org/2015/02/on-lens-detection-and-corre... and http://www.darktable.org/usermanual/ch03s04s04.html.php#lens....

Here is which seems to be idiomatic in digital photo processing (e.g. darktable):

  for (int r = 0; r < GRID_SIZE; r++) {
    for (int c = 0; c < GRID_SIZE; c++) {
      if (i == 1 && j >= 1 && j < GRID_SIZE - 1)
	i = GRID_SIZE - 1;
      grid[i][j] = 0;
    }
  }

Of course, this one has a conditional, and many would frown on mucking with the loop counter outside of the for statement.

A source for this style may be dcraw, e.g. see from border_interpolate():

  for (row=0; row < height; row++)
    for (col=0; col < width; col++) {
      if (col==border && row >= border && row < height-border)
	col = width-border;
  // etc.

The dcraw code is so tightly written that I assume Dave Coffin has good reason for this choice, but I've never tested variants for performance.