JavaScript is the most ubiquitous computing runtime in the world. Web browsers are, by far, the most common host environments for JavaScript, probably followed by server platforms (see Node.js). But JavaScript engines are embedded in many other tools; from microcontrollers, like Espruino, to graphical shells like GNOME Shell; from PDF documents to graphic editing programs, like Adobe Photoshop.

As I wrote in my first post on this blog, JavaScript has some design problems and, in my opinion, these problems make large application development really hard.

So, as it’s pointed at http://www.haskell.org/haskellwiki/The_JavaScript_Problem, JavaScript sucks but we need JavaScript. As a result various alternative languages compiling to JavaScript and compilers for old language that generate JavaScript have emerged.

To see a a good list of languages and compilers that target JavaScript, visit https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS. There are more than 200!

The process of running another language in a JavaScript interpreter is simplified if the developer tools for that platform support source maps, which maps the generated JavaScript to the original code. This way, you can debug, optimize, test… using the original code. This doesn’t mean you can forget or avoid learning JavaScript; in the end, JavaScript engines work with JavaScript.

New languages that target JavaScript

I put in this section three languages with different tastes that have been developed to generate JavaScript code, licensed under open-source licenses and that I would consider to use.

These new languages are pretty different, CoffeeScript might remind you Python and Ruby, TypeScript is really influenced by Java, while PureScript belongs to the Haskell school. All they produce small (ready for client-side development) and readable code, so, don’t be afraid and give them a try to see if they fit your needs; if you want to return to JavaScript, just use the generated JavaScript.

CoffeeScript

The most popular alternative to JavaScript is CoffeeScript, in fact, At Quobis, we use CoffeeScript instead of JavaScript. His creator, Jeremy Ashkenas (also the creator of Backbone.js and Underscore.js) says:

CoffeeScript is a little language that compiles into JavaScript. Underneath that awkward Java-esque patina, JavaScript has always had a gorgeous heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

CoffeeScript is just a syntactic sugar layer over JavaScript inspired, mostly, by Python and Ruby. Hence, it’s just another syntax for writting JavaScript code. It avoids some JavaScript pitfalls and adds some features like sort of object-oriented programming via classes, implicit returns, list comprehensions or postfix operators for loops and conditionals.

Its main advantage is, at the same time, its bigger drawback: it’s just a saner way to write JavaScript code, but it’s JavaScript. Actually, the golden rule of CoffeeScript is It’s just JavaScript.

It is worth pointing out there a good bunch of CoffeeScript forks and dialects with different goals like Coco, that aims to be more radical, or IcedCoffeeScript, which is a superset of CoffeeScript that adds some keywords to deal with asynchronows control flow.

TypeScript

TypeScript is a Microsoft project that adds structural typing on top of JavaScript:

TypeScript is a language for application-scale JavaScript development. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.

You can think on TypeScript as JavaScript plus optional static types and class-based object-oriented programming; so, TypeScript provides support for classes, properties, inheritance, interfaces and namespaces. By default, TypeScript delegates to dynamic typing (type any) when it can’t find the type out. So, valid JavaScript code is valid TypeScript code too.

The TypeScript compiler has a flag, --noImplicitAny, which fires a warning on untyped expressions and declarations. There is a repository in github where you can find TypeScript type definitons for more thab 300 JavaScript libraries and APIs.

PureScript

PureScript is a Phil Freeman’s project. PureScript is a rewording of JavaScript with a strongly type system in the style of Haskell type system. In the words of its creator:

I was looking for a simple functional language which would compile to JavaScript and have the following characteristics:

• Generates simple readable Javascript
• Provides the ability to compile to tight loops if necessary
• Reasonable type system
• Ideally, written in a programming language I would enjoy working in
• Provides a simple interface to existing Javascript code

PureScript is not designed to be a general-purpose programming language. The primary use case is as a generator for purely-functional core libraries, with the main application code written in another language.

A look to PureScript code shows is clearly inspired by Haskell. As Haskell, it provides algebraic datatypes, homogeneous arrays, polimorphic types, type inference, typeclasses, pattern matching… If you are a Haskeller, you likely want to try PureScript.

The main problem with PureScript is, contrary to what happens to TypeScript, the absent of wrappers for most common JavaScript libraries. It provides a simple Foreign Function Interface that allows you to write wrappers by yourself. This language is neither popular enought nor supported by a big company. I hope that PureScript will increase its community, so, this problem will be a matter of time.

th

th is a command-line todo list manager in the style of t written in Haskell.

th shares with t the same features:

• It’s simple.
• It just uses a human readable plain file.
• It works nicely with Dropbox, control version systems and shell scripts.

Installing th

th requires Haskell Platform and a UNIX-like shell (I use zsh). It may work on Linux, OS X and Windows (using Cygwin).

Once you have installed Haskell Platform, you have to download the latest version or clone the repository using git, git clone https://github.com/damianfral/th.git.

Having the repository downloaded/clone, you just need to execute cabal install. You may set up your path to be able to access ~/.cabal/bin/ without the absolute path.

Using th

You can execute th -h to show the usage information:

> th -h

Usage: th [OPTION...]
  -v, -V       --version          Show the version of th
  -h, -H       --help             Show help for th
  -c TASKNAME  --create=TASKNAME  Create a new task
  -s TASKID    --start=TASKID     Mark task as started
  -f TASKID    --finish=TASKID    Mark task as finished
  -d TASKID    --delete=TASKID    Delete task
  -l FILENAME  --list=FILENAME    Use this file as the task list

By default, if you don’t specify a file with --list, th will use todo.txt.

Each task can be in one of these 3 states: not done, started, finish.

Create tasks

> th -c "Release version v1.6"

1 - [ ] Release version v1.6


> th -c "Review open issues"

1 - [ ] Release version v1.6
2 - [ ] Review open issues

Start/Finish a task

> th -s 1

1 - [-] Release version v1.6
2 - [ ] Review open issues

> th -f 1

1 - [x] Release version v1.6
2 - [ ] Review open issues

Delete a task

> th -d 1

1 - [ ] Review open issues

Show tasks

> th

1 - [ ] Review open issues

Introduction

This is a brief post about my final year project in computer engineering. I’ve developed a small command line application to do high dynamic range fusion on RAW images (Bayer domain). I’ve coded it in C++ using Halide and LibRaw.

This little application takes some RAW files, 2 or more, as input and returns a HDR TIFF image.

RAWs I’ve used to get the images showed in this post belongs to The HDR Book: Unlocking the Pros Hottest Post-Processing Techniques (I haven’t read it).

Noise measurement

If we take a photography of an uniform zone with an ideal camera all pixels in the image will have the same value. But the perfect camera does not exist. This image will always have some interference, noise, that will break the uniformity making pixels fluctuate around a value, the mean value. So, we can equate average value with noiseless value and standard deviation with noise. Hence, we can express signal to noise ratio (SNR) this way:

$$SNR(image)=\frac{\mu (image)}{\sigma (image)}$$

We can meassure the SNR for different relative exposures by taking some pictures to an uniform zone (using the manual focus to blur the image in order to avoid textures) with different exposure times.

HDR fusion

Reading the previous chart we realize we need to increase exposure, exposing to the right if we want to get less noise. But there is a limit, the saturation point. This is the point at which it can no longer generate new electrons for additional photon strikes.

We could take two photos, one well-exposed and another one overexposed. The well-exposed picture will have detail in the highlights but more noise than the overexposed picture. The overexposed image will have the opposite features, much less noise and saturated highlights. Equalising the exposure level and taking the best parts of each image (the highlight from the well-exposed picture, the non-saturated parts form the overexposed one) we can get a image with higher dynamic range and less noise. This is called High Dynamic Range fusion.

Fusion Map

The key to get a fused HDR image with lower noise is in the generation of the fusion map. In the case of two input images, this approach binarizes the more exposed picture with the next formula to get a fusion map where pixels with value 0 are fitted with the well-exposed picture, and pixel with value 1, with the over-exposed one:

$$map(x,y)=overexposed(x,y)\le (saturation\cdot threshold)$$

The above formula has a threshold value between 0 and 1 to take more (higher threshold) or less (lower value) highlights from de overexposed image. The binarized image is blurred with Guassian kernel to avoid sudden transitions in the final image.

Extending this process to support more than two images is pretty simple.

Bayer Domain

There is a diference between my application and common approaches, it uses directly RAW images. A RAW image contains only one channel per pixel (R,G or B). So, while other aplications use raster images, which have one real and two interpolated channels, this application only works with real data. This way, the performance may be improved.

Noise reduction

The level of noise reduction depends on the exposure schema. A scheme like [0 EV, +3 EV, +6 EV] works pretty well. A wider exposure scheme can increase the noise reduction, but it could generate artifacts (visible fusion borders) due to the difference SNR between pixels from photos with a high exposure level difference.

Tonemapping

This application uses the less exposed photography as reference, so the fusion result has the same look. This way we can avoid the tonemapping process. Nevertheless, by applying a tonemapping operator we can get a better result if the less exposed image is too underexposed. Anyway, this application does not include a tonemapping option, but the user could use an external tool like pfstmo.

Next steps

I may open source this application in the future. But, firstly, I want to change some parts an fix some bugs. If someone want me to explain this project more deeply or something about digital photography or image processing, just ask it.

Thanks

I would like to thank some people for their support. In the first place, I want to express my gratitude to my girlfriend, Ángela, for all those hours in the library and for her photographies, advices and help. Next, I want to mention Guillermo Luijk, his work on digital photography is the base of this project. I also want to thank Quobis, the company I work for (they have been unselfish and gave me the posibility to shift my working schedule), and my friends Aitor and Eleazar for encouraging me.

This article is based on Why use monads.

Suppose you have some functions that take a number and answer another number or null:

inc = (x) ->
    if x isnt 6
        x + 1
    else
        null

double = (x) ->
    if x % 2
        x * 2
    else
        null

dec = (x) ->
    if x isnt 3
        x - 1
    else
        null

Now, you want to compose a new function chaining previous functions. Something like this:

all = (x) ->
    dec(double(inc(x)))

This is not the most elegant way of chaining functions, so you write a generic chain function:

chain = (funcs...) ->
    (arg) ->
        for func in funcs
            arg = func arg
        return arg

all = chain dec, double, inc
all 3 # Wrong result: 3. Expected result: null

In spite of being a better path, you still have to deal with null values or otherwise we will see things like last line of the above code (in JavaScript null plus 1 is 1). You could change previous chaining function in order to be specific for this problem or create new all function that stops running and returns null when a chained function returns null:

all = (x) ->
    return null if tmp is null
    tmp = inc x
    return null if tmp is null
    tmp = double tmp
    return null if tmp is null
    tmp = dec tmp
    return tmp

There is a clear pattern there; these functions are monadic functions under the maybe monad, we can combine them like this ¹:

all = doMonad MaybeMonad, inc, double, dec
all null # null
all 3    # null
all 8    # 17

Other languages like Haskell allow this kind of composition without effort. In JavaScript (or CoffeeScript) we have to work a little more to get it:

None       = null
MaybeMonad =
    mReturn: (value) ->
        if value in [undefined, null, NaN]
            return None
        return value

    mBind: (value, f) ->
        return None if value is None
        return f value



doMonad = (monad, funcs...) ->
    (result) ->
        iterator = (i = 0) ->
            if i is funcs.length
                return monad.mReturn result
            else
                result   = funcs[i] result
                return monad.mBind result, -> iterator i + 1

        return monad.mBind (monad.mReturn result), -> iterator 0

What the hell do we have here? It easier than it seems. There is a None variable, a MaybeMonad associative array and a doMonad function. The MaybeMonad has 2 functions.

• mReturn takes a value and transform it (or maybe not).
• mBind takes a value (it will be always returned by mReturn) and a function and do some computations to call that function (or maybe not).

The doMonad functions takes a monad and a bunch of functions (funcs) and returns a new function. This function will receive an argument (result) and it will iterate over funcs to call them with the value returned for the previous function as argument except for the first function (it has not previous function) that receives the same argument, called result, as the wrapper function. The special thing here is that these iterative execution of functions are proxied with monad.mBind. In the case of MaybeMonad, mBind decides if the next function will be executed or not.

The point is doMonad is generic and you can write your own monads to composing functions with your own pattern. Let’s see the List monad:

flatten = (value) ->
    if Array.isArray value
        output = []
        value.map (elem) ->
            if Array.isArray elem
                output = output.concat flatten elem
            else
                output.push elem
        return output
    else
        return [value]

In this case, mBind doesn’t stops the chained executions, but just flats the returned array received as argument. We can get this:

ListMonad =
    mBind: (list, f) ->
        output = list.map f
        return flatten output

    mReturn: (value) ->
        return [value]


replicate = (n) ->
    (v) -> [0...n].map -> v

generation = (value) -> (replicate 3) value

f = doMonad ListMonad, generation, generation
f ["No God! Please no!"]

# [ 'No God! Please no!',
#   'No God! Please no!',
#   'No God! Please no!',
#   'No God! Please no!',
#   'No God! Please no!',
#   'No God! Please no!',
#   'No God! Please no!',
#   'No God! Please no!',
#   'No God! Please no!' ]

Prototypal Object Orientation

Class-based object orientation is the most used approach to object orientation. JavaScript is the only mainstream language that has prototypes. I don’t want to say which one is better, just that I feel more confortable with classes. JavaScript prototypes can emulate class systems. In fact, there are many libraries for that.

Modules and Var declaration

JavaScript has no formal construct for namespaces. Module pattern (passing the namespace as an argument to an anonymous self-invoking function) is really helpful. Lexical scope and closures are nice, which allows the module pattern, but something as important as namespaces must be part of the language, don’t you think?

Another weird behaviour is related to the var keyword. If you declare a variable with var, it will belong to the local scope. If you don’t, its scope will be global with overwritting problems and performance penalty (the interpreter will look up the scope chain to find the global variable).

Syntax

Event driven code is really common in JavaScript. Usually, if you don’t use promises or some stuffs like Flow-Based Programming (FBP), you define a callback that is passed as argument to a function that binds that function to an event, like DOM events in the browser or EventEmitter events in Nodejs. So, when you have a callback that binds another callback to another event that binds another callback to… and enclosed by the module pattern, you will see something like this:

(function()
{
    $("#my-button1").on("click", function(msg1)
    {
        alert(msg1);
        $("#my-button2").on("click", function(msg2)
        {
            alert(msg2);
            $("#my-button3").on("click", function(msg3)
            {
                alert(msg3);
            });
        });
    });
}).call(this);

I prefer indentation over braces and parenthesis, so the above code looks pretty ugly for me.

Dynamic typing and late binding

Delaying type-checking to runtime is nice for fast-prototyping and data intensive applications (generating types and behaviours based on runtime data). Not so many years ago, JavaScript was used as a toy language to add some animations, form validations and simple stuffs. AJAX changed it all. JavaScript has been growing up since then and nowadays it is used in bigger apps (databases, game engines, communications apps, multimedia apps..) that may have a high cyclomatic complexity. Since JavaScript just checks types and binds names in runtime, a stupid unnoticed error misnaming a variable or a method could slap your face in the worst moment (demo effect).

Static typing is not the holy grail, but it is safer. Haskell guys, as @EleDiaz , know that if Haskell code compiles, it is almost certain that it will work as expected.

And some web applications need performance. Doing some tasks in the compilation time (AOT), can give us, for example, a higher FPS value in our game.

Weak typing

Coercion plus dynamic typing results on a debugging hell. Many JavaScript programmers, I guess, have noticed that debugging JavaScript code is not easy. Many errors are hidden by implicit conversions. It might speed up development (in my opinion, it’s just true in the case of small apps; bigger applications require safety), but it slows down debugging by a higher factor.

Surprise behaviour

JavaScript is a joker. Let’s see:

var a = (7, 5); // -> a = 5
typeof({} + []) // -> "string"
typeof([] + {}) // -> "number"

"1" >= -Infinity // true
"A" >= -Infinity // false
"A" < -Infinity  // false

Despite of the fact that ES 6 has some new proposals to minify or solve these and other problems, there is another path to avoid them: use another programming language that targets JavaScript.

There are some new languages that try to hide the bad parts adding a syntax sugar layer keeping the JavaScript semantics. Other languages have a completely new syntax and semantics. And there is another option, compilers for old languages that generate JavaScript code.