Computational Photography, an AI-powered Slopendium

▸Part 42 SYSTEMS⧉

▸42.1 Programmable and modular cameras⧉

42.1.1 What a closed camera hides⧉

42.1.2 The Frankencamera: a camera as a pipeline of requests⧉

42.1.3 From FCam to camera2⧉

42.1.4 Opening cameras that were not meant to be opened⧉

42.1.5 Modular cameras⧉

▸42.2 Image processing libraries⧉

42.2.1 What a library provides⧉

42.2.2 Eager whole-image libraries⧉

42.2.3 Demand-driven, streaming libraries⧉

42.2.4 Separating the algorithm from its schedule⧉

42.2.5 GPU and tensor libraries⧉

42.2.6 Choosing⧉

▸42.3 Lightroom-style raw developers⧉

42.3.1 The recipe and the catalog⧉

42.3.2 The pipeline and its order⧉

42.3.3 Case study: CompPhotoRoom⧉

42.3.4 One graph, three drivers⧉

42.3.5 Boundaries at algorithms, not operators⧉

42.3.6 Two implementations of every stage⧉

42.3.7 Merging is most of the performance⧉

42.3.8 What a raw developer knows about cameras⧉

▸42.4 Photoshop-style editors⧉

42.4.1 The layer stack⧉

42.4.2 Tiles⧉

42.4.3 Case study: gamut⧉

42.4.4 The document is a graph, shown as a stack⧉

42.4.5 Copy-on-write tiles make undo and duplication free⧉

42.4.6 Destructive edits as a log⧉

42.4.7 Selections are sparse, and skipping saves the operation⧉

42.4.8 Scheduling: pull, cache, fuse⧉

42.4.9 What it buys⧉

42.4.10 Editors in the browser⧉

▸42.5 Networking and image transport⧉

42.5.1 Delivering the right image⧉

42.5.2 Tiles and pyramids over the network⧉

42.5.3 Where to compute⧉

42.5.4 Sending a recipe instead of the image⧉

▸42.6 Photography programming on phones⧉

42.6.1 Android: camera2 and CameraX⧉

42.6.2 iOS: AVFoundation, Core Image, and the photo library⧉

42.6.3 The closed middle⧉

42.6.4 Running the computation on the device⧉