TFA only mentions Gaussian blur, but a Gaussian blur is just a moving average, with "closer" pixels being valued higher, plus a smooth falloff. When you replace each value with an average of its neighborhood, you "soften" the transitions.
The rectangular pillbox filter also has the separable property. So does the parallelogram pillbox filter (albeit also rotated), which, by extension, allows us to do blurring by a hexagon (sum of three parallelograms) which can be used to simulate cool-looking bokeh .
 McIntosh, L., Bernhard E. Riecke, and Steve DiPaola. "Efficiently Simulating the Bokeh of Polygonal Apertures in a Post‐Process Depth of Field Shader." Computer Graphics Forum. Vol. 31. No. 6. Blackwell Publishing Ltd, 2012. http://ivizlab.sfu.ca/media/DiPaolaMcIntoshRiecke2012.pdf
The reason why I'm asking instead of searching on Coursera is that Coursera has become increasingly hard to search, at least in my view, so it's easier to ask directly.
Something like this: https://questionsomething.wordpress.com/2012/07/26/databendi...
Like open this image in your browser or in your favorite image viewer and scale it down to 50%:
The person behind is has some nice blog posts on color generation too:
The only issue that I see is that the library is focused on translating data to colours. The problems with blurring and downscaling that you mentioned go the other way: the colours are the data.
Don't forget scikit-image and scipy.ndimage too.
"In imaging science, image processing is processing of images using mathematical operations by using any form of signal processing for which the input is an image, a series of images, or a video, such as a photograph or video frame; the output of image processing may be either an image or a set of characteristics or parameters related to the image."
 Rafael C. Gonzalez; Richard E. Woods (2008). Digital Image Processing. Prentice Hall. pp. 1–3. ISBN 978-0-13-168728-8.
I once worked on a UI where the users wanted to capture a screenshot of the current page.
Because color toner is more expensive they also wanted the option to print grey scale. I'm pretty terrible at working in 2D space but a quick Google search let me know that the conversion to grey scale involved averaging the RGB values for each pixel.
Unfortunately, the coloring of the UI was darker more than light so the resulting greyscale image was still black toner intensive. So we provided an additional option to invert black and white.
To make it work a second transform was applied to each pixel that reversed the pixel value from upper to lower bound (or vice versa depending on how you look at it).
The result was an output that trended toward white instead of black. The output looked surprisingly good and saved on toner so the users could print many screen captures without worrying about wasting resources.
For the business, it resulted in a cost and resource savings. For users, picking the resulting output provided better results that were easier to understand. From a development perspective, the implementation wasn't difficult at all to add. So, win-win-win.
What surprised me was how easy these transforms were to apply. It's a bit CPU intensive on high resolution images but it's not terribly difficult to come up with good results.
It would be awesome to see some more examples of algorithms used for image processing. So much material covers generic algorithms and data structures that come with the typical CS degree.
It would be much more interesting to see algorithms that can be used in practice. For example, how to scale images, implement blur, color correction, calculate HSL, etc...
Libraries are great but these concepts are simple enough that they don't require 'high science'.
The article mentions a curiosity related to how edge detection works. I'd assume that you select a color and exclude anything that falls outside a pre-determined or calculated threshold. For instance, take a color and do frequency analysis of colors above-below that value by a certain amount. Make multiple passes testing upper and lower bounds.
A full color image @ 24 bit (8R 8G 8B) will take a max of 24 passes and will likely have logarithmic runtime cost if implemented using a divide-conquer algorithm.
Things like blur and lossy compression sound a hell of a lot more interesting because they have to factor in adjacency.
This is not at all how edge detection works. See https://en.wikipedia.org/wiki/Sobel_operator for a key building block.
I wasn't aware of this approach. Looks like a reasonable single-pass solution.
Maybe the image is, say, 8-bit grayscale, so the values can range from 0 to 255 instead -- then it'd be floor(k/n times 256).
This is usually described in terms of a cumulative description function; I tried to say the same with less jargon.
If anyone's interested in the theory, I'd recommend Sonka
Well, of course one should learn both :) An interesting question to ask is: principles first or applications and techniques first? Maybe it depends on the individual. For me, certainly it has to be the application. Principles without application would not keep me engaged long enough... Ideally, it should be something like 30% high level principles with applications, and then the rest of the principles and fundamentals later on, which really elucidate how and why the technique works.
That's my two cents anyway. :)