How to check if a picture is an image or a floor plan by using Javascript

Hi there! Oh, maaaan… This Coronavirus situation was pretty difficult. I hope you all managed to overcome it without any serious consequences. As you might have guessed, it did impact my writings on my blog and youtube video recordings as well.

The home office proved to be much more exhausting than it sounds at first. My productivity did increase but it was hard to separate work from leisure. But that’s going to be a blog post for itself.

Let’s get going with some new cool content. 

The challenge

Recently, I had the opportunity to work on some awesome reactjs project. And I stumbled upon a feature request to determine if a picture is an image or a floor plan by using Javascript. And without using any Google, Microsoft, machine learning, AI whatsoever hyper-cool trending stuff.

What does that mean? 

Well, it means that you need to upload some photos and determine if it’s a proper photo taken by a camera or if it’s a floor plan (schema). The very tricky part of this feature was that the floor plan can be in color, not just black and white. Which would significantly make my life easier of course? But hey, we love challenges! Especially this kind of Javascript challenges, don’t we!? 🙂

via GIPHY

The search

After googling around for a while I couldn’t find a proper copy/paste solution. Even more, I had a problem by only finding how to use google, to search what I needed. And after a while, I ended up on some forum posts which gave me an idea of how to solve this issue.

via GIPHY

The whole idea is to load an image and check each pixel of an image then based on that make some calculations regarding color size and saturation.

The solution (theory)

To determine if one photo is a floor plan or not:

  1. Check photo saturation and if it’s lower then XYZ it’s a floor plan
  2. Check the number of pixel colors. If it’s below certain color number then it’s a floor plan 

Okay, number of colors makes sense but what the heck is saturation?
If you google it, you will find a definition which says:

Saturation refers to the intensity of a color. The higher the saturation of a color, the more vivid it is. The lower the saturation of a color, the closer it is to gray. Lowering the saturation of a photo can have a “muting” or calming effect while increasing it can increase the feel of the vividness of the scene.”

So black and white colors have saturation 0 (zero) or almost 0 (zero) while photos are more saturated. So, camera taken photos is more saturated than the floor plan images (although) this might not always be the case.
The higher the resolution the image is more saturated. That’s why this solution isn’t 100% bulletproof. But does cover more than 98% of cases which was definitely more than enough.

via GIPHY

Pseudocode

Okay, let’s get more into pseudocode which says the following:

  • Obviously, load the image into pixel array
  • You should implement the function which loops through each pixel of an image, and then you need to find the average saturation number
  • If that number is below the constant number we set by ourselves (which proved to be around 0.03, but you can tune this a little bit more) we can assume it’s a floor plan.
  • To make our solution more rigid we will also implement a function that shall check the number of colors. 

Oh, by the way, I will only show you the snippets of code. If You want to challenge yourself, feel free to create a custom library based on this.

I will provide you in the end a more pseudocode steps to ease you the process.

The (partial) solution

getSaturation({ pixelArray, pixelCount }).then((saturationValue) => {
            if(saturationValue < 0.03){
              getPixelColorsSize({ pixelArray, pixelCount, imgData }).then(colorSize => {
                if (colorSize < 1000){
                  accept(true)
                } else { 
                  accept(false);
                }
              });
            } else {
              accept(false);
            }
          });


const getSaturation = ({ pixelArray, pixelCount }) => {
  return new Promise((resolve, reject) => {

   const sum = pixelArray.reduce((total, pixel) => total + calculateSaturation(pixel));

    const checkValue = sum / pixelCount;

    resolve(checkValue);
  });
};


const calculateSaturation = (pixel) => {
  let r = pixel[0];
  let g = pixel[1];
  let b = pixel[2];

  // Make r, g, and b fractions of 1
  r /= 255;
  g /= 255;
  b /= 255;

  // Find greatest and smallest channel values
  const cmin = Math.min(r, g, b);
  const cmax = Math.max(r, g, b);
  const delta = cmax - cmin;
  let s = 0;
  let l = 0;

  // Calculate lightness
  l = (cmax + cmin) / 2;

  // Calculate saturation
  s = delta === 0 ? 0 : delta / (1 - Math.abs(2 * l - 1));

  return (s);
};

Conclusion

I hope this article helped you a lot if you stumbled upon this kind of feature request. I surely know, if I had it it would be a breeze to implement it.

Anyways, thanks for reading and let me know if You managed to create a custom library based on this?

Cheers

The challenge (homework)

More pseudocode:

  1. Load image
  2. Get pixel array (hint: use get-pixels library)
  3. Use above explained saturation code
  4. Loop through pixel array and add each pixel r-g-b value to a collection to check color size

Redux – simplified

What is Redux?

It’s a library for state management based on Flux pattern and functional programming.
It’s best used for medium to enterprise applications.

Why and when to use it?

When?

By adding Redux to your application you add up complexity. So when developing small apps it’s not necessary to use Redux.

Why?

We use Redux to avoid spaghetti code and ease debugging.
If you ask yourself how is that so, here is the answer?!

Keeping the state in sync

If you are developing large scale application (without Redux) you will probably end up with bunch of events flowing around between various components. You will end up with all sorts of data workflow, coming in and out, and you will not be able to track your bug easily.
Without using Redux, keeping the state in sync across the application becomes difficult.

So, benefits of using Redux are:

  • decoupled architecture
  • easy state management
  • testing
  • undo functionality (becomes breeze to implement)

Building blocks of Redux

There are three building blocks of Redux:

  • Store:
    Contains state of the application (something like local client db).
    It might contain lists, props etc.
    [IMPORTANT] Only store can change the state (push,pop…)
  • Actions:
    Contains objects which represent events that have happened i.e.:
    { type: ‘POSTED_BLOGPOST’, body: ‘…’ }
  • Reducers:
    Are functions which specify what needs to happen depending on an action (state changes based on action responses).
    [IMPORTANT] Reducer does NOT change the state.
    He only returns a new state (hence functional paradigm)

PURE VS IMPURE FUNCTIONS

PURE ONES

Pure functions are the ones who return always the same result and do nothing else in the background.

IMPURE ONES

On the other hand Impure functions return different result each time they are called and might do something in the background.

For example, function to increment or function to add something to DB are “Impure functions”.

Example of pure vs impure function:

// IMPURE

function increment(number){
     return number++;
 }

// PURE

 function increment(number){
     return { result: number + 1 };
 }

The difference

The difference between these two are that by providing the same input for impure function, we always get other result. Result is changing the input param.

While in pure function, we always get the same result, which we expect though. There is no change of input param.

Example of Reducer

Example of writing simple reducer by following the above example would be like so:

function reducer(state, action) {
     switch (action.type) {
         case: 'INCREMENT':
             return { result: state.result + 1 };
     }
 }

Redux Implementations

There are a bunch of Redux implementations for Angular like ngrx store, ngxs, rxjs or Akita.

I find Akita as the easiest one of them all to work with. A collegue of mine, introduced me to Akita so we did implement it into our enterprise application.

But generally speaking, principles are more or less the same for each and everyone one of them. That’s why I won’t go deeper into specific implementations.

There are a bunch of nice tutorials how to add and use them into your Angular applications:

FINAL WORDS

Bottom line is that you must use some kind of state management library when developing medium to large scale SPA applications.

It will drastically ease your debugging life, reduce spaghetti code and make your life easier when writing your tests. Since you don’t need to provide any mockup data for testing purposes (hence immutability).

Reactive user interfaces using SvelteJS

Today I’ll be writing about SvelteJS.

A truly refreshing Javascript framework (Well, Svelte is not a framework. It’s a compiler.) which will, as stated on Svelte.dev web, enhance you web apps.

But I must say, not just your web apps, your whole experience of developing, will be enhanced.

Only few..ermmm, frameworks (should I call it a framework, NO!!!) blew my mind and this is one of them.

Continue reading

Overview of UI frameworks in 2019

Last blog post I announced I’ll be writing about a new Javascript framework.
In the meantime (while I was preparing that new blog post) I got asked by PMF Split university to do some presentation. I said yes, of course.
That’s why my new blog post, about the new Javascript framework, is on hold.
So I decided, instead, to write a blog post about a presentation I held for PMF Split.

Continue reading