Image Processing – Recommended Reading

Following this post with strong interest as I would also like to understand what I am doing and why. Thank you.

1 Like

@elstoc I would say play to your strengths. Start there and branch out.

Each discipline has its blindsides. The interdisciplinary approach was big when I attended school and I enrolled in one of the most cross-disciplinary program that I could find, and I still attended classes that weren’t a part of my curricula to broaden it out even more.

Of course, there are opinions and assertions that are plain wrong but more often than not it is just another perspective of a very complex subject. A good analogy that I think people here would get is colour constancy. Just as colour looks different depending on the lighting situation, the problems of image processing look different depending on your background.

The reason that “most” papers suck is that people just want to get their Masters degree done. Yes, it is the fault of the supervisors and journals for encouraging and publishing misinformation. But my point is that many people approach their subject as a means to an end, which doesn’t help the discipline or contribute to our collective knowledge base coming from research.

1 Like

The scholarly work can be a bit tedious to plow through. I’ve come at all this a bit sideways; disclosure: while I have three university degrees, latest is a doctorate in computer science, I have only had four math courses in the whole thing. Long story, sums up to the ‘there are more ways than one to skin a cat’ adage… So, anything that smacks of signal processing is literally Greek to me; as a computer programmer I essentially look for the summations and think “for-loop”…

There are some fundamental mechanics to understand that help. Numeric representation of image data is foundational, and can trip one up if not considered in the overall mechanism. A lot of the papers I’ve read devolve to the 0-255 8-bit range between black and white for their examples, but that really doesn’t help to understand the dynamics of 11-, 12-, and 14-bit resolutions of current sensors delivered in 16-bit containers and often converted to a floating point representation for the precision. G’MIC’s floating point representation 0.0-255.0 had me tearing my hair out a few years ago, as I’d been condition to the 0.0 - 1.0 convention used by a lot of other software.

There’s nothing like studying implementing code. Nothing that can help better. And, nothing that can vex you more. Most of what I’ve come to understand about raw processing came from studying David Coffin’s dcraw.c, but his C code is bewilderingly “Elegant”. @Elle Stone has a really great web page on it, dcraw annotated & outlined, the entire source annotated from the perspective of a non-programmer. Hat’s off to here from bear-of-little-brain here… :smile: Another reference that ties into dcraw.c, from the perspective of the Canon CR2 format: Inside the Canon RAW format version 2, understanding .CR2 file format and files produced by Canon EOS Digital Camera

Hope all this is helping…

1 Like

Yep, code is the practical implementation of what is written. I believe that @Elle isn’t a programmer by training so her code is very hack-y but as such she knows how to communicate well to the rest of us what is going on. Keep in mind her articles are out-of-date but we can still glean a lot from her.

guillermoluijk.com is awesome too. He inspired lots of people and code.

What is it that you want to understand ? A sensible way to push pixels for photographers ? The theoretical background of algos used in darktable ? All of it ?

I learned everything the hard way… My original trade is solving heat-transfer PDE by finite elements. So, using my maths and some epistemology background, I binge-watched Google Scholar and tried to reproduce the results (lot of papers come with Matlab code) until things started to make sense. After a while, just looking at the equations (good maths are elegant) and the results (halos mean bad algorithms in bad colour spaces), with years of practical photo editing experience, you can recognize good ideas from geeky BS.

Then, all you have is your judgement. Whenever people squeeze in perceptual frameworks to solve 100% signal processing issues (interpolation, denoising, reconstruction), you know it stinks. There is a lot of BS in academia these days, people pushed to publish whatever, low-rank universities going to image processing because it doesn’t cost much (you don’t need to build a super hadron collider to do research in image processing, that’s for sure), so at the end your judgment is key anyway. It really falls-back to straight epistemology.

1 Like

This is the key question isn’t it? I’m not sure I have a good answer, but I can give you a brief flow of consciousness to try and give you an idea… My initial motivation is to understand complex darktable modules on a deeper level than ‘push the sliders until the image looks good’. So that when, for example, I look at the new (darktable 3, non-local-means-) version of profiled denoise, I can understand what’s happening when I move each of the 7 sliders and to choose which one to adjust when and why (the auto mode seems a bit like cheating to me!). The manual is a good starting point but, being written by people who know the subject inside-out, can often assume knowledge that the average photographer doesn’t have, and at some point I usually start to get a bit lost and revert back to ‘play with the sliders and see what happens’. Transferring the information in the manual to a reasonable workflow is sometimes hard to do. Some of the theoretical background would probably help me to do this in a less ‘random’ way and allow to adapt my workflow based on the image and my intent.

Ultimately I would love to contribute back to the project (to coding/testing or to the user manual) but to have a workflow that I’m fully in control of (because I understand it) is my initial goal.

However, I’m basically interested in everything, so I’m happy to get pulled down some academic rabbit-holes on the way.

Here is the chance for you to help solve what you’ve railed against for some time, photographers who don’t know the difference between the tip of their lenses and the holes in their ass :wink:

2 Likes

Agreed, and this discussion is partly motivated by the discussion on @anon41087856’s pull request regarding the use of the term ‘expert’ to describe darktable on the website (make the intent of the soft clearer by aurelienpierre · Pull Request #59 · darktable-org/dtorg · GitHub) - I almost pasted some of the comments from that discussion into my initial post . There’s a danger that the tool ends up being geared towards experts and there being no agreed way to turn someone into an expert (or even what constitutes an expert), so it becomes a tool that only the developers can use properly.

Anything I can do to become such an expert (and to make sure there are more of them) can only be a positive for myself and for the project.

@elstoc There are plenty of threads that discuss dt’s denoising in detail (alliteration!). You could start there for that particular topic.

For me personally, the part I aim to change is

For now, learning darktable is a lot of lonely effort, crossing sources between the documentation, courses, tutorials, blogs, forums and lots of personal tests until it all converges toward a usable workflow based on some understanding of what’s going on at a relatively low level.

We are not alone, we are here to better our own, and then others, understanding of application use, image processing, and perhaps some general nerditry.

Indeed!

Couldn’t agree more @paperdigits. It absolutely needs to be made clear that there’s a big learning curve to darktable (and that the learning will be rewarded). But then we need to be clear how to go about it, and to put all of that disparate information in one place.

There are plenty of threads about denoising. That’s part of the problem! It’s also, it must be said, part of the solution: The information is out there it’s just really hard to get at.

2 Likes

@paperdigits has been writing a book for some time to summarize the wild and wacky world of photo processing and management. I wonder where you are at? :point_right: :wink: :stuck_out_tongue:

As an example, I use ArchLinux at home. It’s designed to be a linux distribution for ‘experts’ (people that aren’t afraid of the command line and don’t mind learning how to set up configuration files). It gives you a command line and a package manager and expects you to create your own system basically from scratch.

It can only do this because it also provides a massive wiki site that gives you all the information you need to become an expert.

This is what darktable needs.

2 Likes

Still very much in the thinking stage of it. I’d like to get a skeleton published so people can start writing in it though… that’d be a good project for the new year, perhaps.

I don’t really see this as a problem… but it comes down to how you expect to consume information. This is a forum, not a book, and as such information is scattered about and fairly unorganized. I’ve been looking at alternate firmware for smart plugs lately, and if you think this forum is scattered, boy, do I have something for you to look at :laughing:

2 Likes

I’d love to help.

Ok, that’s easy. I can come with a list of background papers for each big chunk in dt (might take some time though).

4 Likes

Thanks @anon41087856. I think there are a lot of people would find that very useful.

2 Likes

I am one who will find that very useful indeed. First I need to reinstall my Manjaro system (arch Linux for dummies!) And start going through the tutorials on dt 3.0

About white balance and colour adaptation:

About contrast equalizer in darktable:

(By the very @hanatos, you sir need to write more of these :slight_smile: )

About the local laplacian:

About non-local means to denoise:

About display-agnostic workflows:

I will come back if I find more. Some of these ressources sometimes disappear, so I suggest you download them somewhere safe.

11 Likes

Thanks @anon41087856. Much appreciated.