{"id":34376,"date":"2021-05-05T12:00:52","date_gmt":"2021-05-05T10:00:52","guid":{"rendered":"https:\/\/www.statworx.com\/?p=34376"},"modified":"2022-08-17T11:24:39","modified_gmt":"2022-08-17T09:24:39","slug":"car-model-classification-4-integrating-deep-learning-models-with-dash","status":"publish","type":"post","link":"https:\/\/www.statworx.com\/en\/content-hub\/blog\/car-model-classification-4-integrating-deep-learning-models-with-dash\/","title":{"rendered":"Car Model Classification IV: Integrating Deep Learning Models With Dash"},"content":{"rendered":"

In the last three posts of this series, we explained how to train a deep-learning model to classify a car by its brand and model given an image of a car (<\/span>Part 1<\/span><\/a><\/span>), how to deploy that model from a docker container with TensorFlow Serving (<\/span>Part 2<\/span><\/a><\/span>) and how to explain the model’s predictions (Part 3<\/a>). This post will teach you how to build a nice-looking interface around our car classifier using Dash.<\/span><\/p>\n

We’ll transform our machine learning predictions and explanations into a fun and exciting game. We present the user with an image of a car. The user has to guess what kind of car model and brand it is \u2013 the machine learning model will do the same. After 5 rounds, we’ll evaluate who is better at predicting the car brand: the user or the model.<\/span><\/p>\n

\"\"<\/p>\n

The Tech Stack – What is Dash?<\/span><\/h2>\n

Dash<\/span><\/a><\/span>, as the name suggests, is software made to build dashboards in Python. In Python, you ask? Yes – you do not need to code anything directly in HTML or Javascript (although a basic understanding of HTML certainly helps). For a great introduction, please check out the excellent <\/span>blog post<\/span><\/a><\/span> from my colleague <\/span>Alexander Blaufuss<\/span><\/a><\/span>.<\/span><\/p>\n

To make the layout and styling of our web app easier, we also use <\/span>dash bootstrap components<\/span><\/a><\/span>. They follow broadly the same syntax as standard dash components and integrate seamlessly into the dash experience.<\/span><\/p>\n

Keep in mind that Dash is made for dashboards \u2013 which means it’s made for interactivity, but not necessarily for apps with several pages. Anyways, we are going to push Dash to its limits.<\/span><\/p>\n

Let’s Organise Everything – The Project Structure<\/span><\/h2>\n

To replicate everything, you might want to check out our <\/span>GitHub repository<\/span><\/a><\/span>, where all files are available. Also, you can launch all docker containers with one click and start playing.<\/span><\/p>\n

The files for the frontend itself are logically split into several parts. Although it’s possible to write everything into one file, it’s easy to lose the overview and subsequential hard to maintain. The files follow the structure of the article:<\/span><\/p>\n

    \n
  1. In one file, the whole layout is defined. Every button, headline, text is set there.<\/span><\/li>\n
  2. In another file, the whole dashboard logic (so-called callbacks) is defined. Things like what’s going to happen after the user clicks a button are defined there.<\/span><\/li>\n
  3. We need a module that selects 5 random images and handles the communication with the prediction and explainable API.<\/span><\/li>\n
  4. Lastly, there are two files that are the main entry points to launch the app.<\/span><\/li>\n<\/ol>\n

    The Big Picture – Creating the Entry Points<\/span><\/h3>\n

    Let’s start with the last part, the main entry point for our dashboard. If you know how to write a web app, like a Dash application or also a Flask app, you are familiar with the concept of an app instance. In simple terms, the app instance is everything. It contains the configuration for the app and, eventually, the whole layout. In our case, we initialize the app instance directly with the Bootstrap CSS files to make the styling more manageable. In the same step, we expose the underlying flask app. The flask app is used to serve the frontend in a productive environment.<\/span><\/p>\n

    # app.py\nimport dash\nimport dash_bootstrap_components as dbc\n\n# ...\n\n# Initialize Dash App with Bootstrap CSS\napp = dash.Dash(\n    __name__,\n    external_stylesheets=[dbc.themes.BOOTSTRAP],\n)\n\n# Underlying Flask App for productive deployment\nserver = app.server<\/code><\/pre>\n
    This setting is used for every Dash application. In contrast to a dashboard, we need a way to handle several URL paths. More precisely, if the user enters <\/span>\/attempt<\/code><\/span>, we want to allow him to guess a car; if he enters <\/span>\/result<\/code><\/span>, we want to show the result of his prediction.<\/span><\/p>\n
    First, we define the layout. Notable, it is initially basically empty. You find a special Dash Core Component there. This component is used to store the current URL there and works in both ways. With a callback, we can read the content, figure out which page the user wants to access, and render the layout accordingly. We can also manipulate the content of this component, which is practically speaking a redirection to another site. The empty <\/span>div<\/code><\/span> is used as a placeholder for the actual layout.<\/span><\/p>\n
    # launch_dashboard.py\nimport dash_bootstrap_components as dbc\nimport dash_core_components as dcc\nimport dash_html_components as html\nfrom app import app\n\n# ...\n\n# Set Layout\napp.layout = dbc.Container(\n    [dcc.Location(id='url', refresh=False),\n     html.Div(id='main-page')])<\/code><\/pre>\n
    The magic happens in the following function. The function itself has one argument, the current path as a string. Based on this input, it returns the right layout. For example, the user accesses the page for the first time, the path is <\/span>\/<\/code><\/span>and, therefore, the layout is <\/span>start_page<\/code><\/span>. We’ll talk in a bit about the layout in detail; for now, note that we always pass an instance of the app itself and the current game state to every layout.<\/span><\/p>\n
    To get this function actually working, we have to decorate it with the callback decorator. Every callback needs at least one input and at least one output. A change in the input triggers the function. The input is simply the location component defined above, with the property <\/span>pathname<\/code><\/span>. In simple terms, for whatever reason the path changes, this function gets triggered. The output is the new layout, rendered in the previously initially empty div.<\/span><\/p>\n
    # launch_dashboard.py\nimport dash_html_components as html\nfrom dash.dependencies import Input, Output\nfrom dash.exceptions import PreventUpdate\n\n# ...\n\n@app.callback(Output('main-page', 'children'), [Input('url', 'pathname')])\ndef display_page(pathname: str) -> html:\n    """Function to define the routing. Mapping routes to layout.\n\n    Arguments:\n        pathname {str} -- pathname from url\/browser\n\n    Raises:\n        PreventUpdate: Unknown\/Invalid route, do nothing\n\n    Returns:\n        html -- layout\n    """\n    if pathname == '\/attempt':\n        return main_layout(app, game_data, attempt(app, game_data))\n\n    elif pathname == '\/result':\n        return main_layout(app, game_data, result(app, game_data))\n\n    elif pathname == '\/finish':\n        return main_layout(app, game_data, finish_page(app, game_data))\n\n    elif pathname == '\/':\n        return main_layout(app, game_data, start_page(app, game_data))\n\n    else:\n        raise PreventUpdate<\/code><\/pre>\n
    Everything needs to be Nice and Shiny – Layout<\/span><\/h3>\n
    Let’s start with the layout of our app \u2013 how should it look? We opted for a relatively simple look. As you can see in the animation above, the app consists of three parts: the header, the main content, and the footer. The header and footer are the same on every page, just the main content changes. Some layouts from the main content usually are rather difficult to build. For example, the result page consists of four boxes. The boxes should always have the same width of exactly half of the used screen size but can vary in height depending on the image size. However, they are not allowed to overlap, and so on. Not even talking about the cross-browser incompatibilities.<\/span><\/p>\n
    I guess you can imagine that we could have easily spent several workdays figuring out the optimal layout. Luckily, we can rely once again on <\/span>Bootstrap<\/span><\/a><\/span> and the <\/span>Bootstrap Grid System<\/span><\/a><\/span>. The main idea is that you can create as many rows as you want (two, in the case of the result page) and up to 12 columns per row (also two for the result page). The 12 columns limit is based upon the fact that Bootstrap divides the page internally into 12 equally sized columns. You just have to define with a simple CSS class how big the column should be. What’s even cooler, you can set several layouts depending on the screen size. So it would not be difficult to make our app fully responsive.<\/span><\/p>\n
    Coming back to the Dash part, we build a function for every independent layout piece. The header, footer, and one for every URL the user could access. For the header, it looks like this:<\/span><\/p>\n
    # layout.py\nimport dash_bootstrap_components as dbc\nimport dash_html_components as html\n\n# ...\n\ndef get_header(app: dash.Dash, data: GameData) -> html:\n    """Layout for the header\n\n    Arguments:\n        app {dash.Dash} -- dash app instance\n        data {GameData} -- game data\n\n    Returns:\n        html -- html layout\n    """\n    logo = app.get_asset_url("logo.png")\n\n    score_user, score_ai = count_score(data)\n\n    header = dbc.Container(\n        dbc.Navbar(\n            [\n                html.A(\n                    # Use row and col to control vertical alignment of logo \/ brand\n                    dbc.Row(\n                        [\n                            dbc.Col(html.Img(src=logo, height="40px")),\n                            dbc.Col(\n                                dbc.NavbarBrand("Beat the AI - Car Edition",\n                                                className="ml-2")),\n                        ],\n                        align="center",\n                        no_gutters=True,\n                    ),\n                    href="\/",\n                ),\n                # You find the score counter here; Left out for clarity\n            ],\n            color=COLOR_STATWORX,\n            dark=True,\n        ),\n        className='mb-4 mt-4 navbar-custom')\n\n    return header<\/code><\/pre>\n
    Again, you see that we pass the app instance and the global game data state to the layout function. In a perfect world, we do not have to mess around with either one of these variables in the layout. Unfortunately, that’s one of the limitations of Dash. A perfect separation of layout and logic is not possible. The app instance is needed to tell the webserver to serve the STATWORX logo as a static file.<\/span><\/p>\n
    Of course, you could serve the logo from an external server, in-fact we do this for the car images, but just for one logo, it would be a bit of an overkill. For the game data, we need to calculate the current score from the user and the AI. Everything else is either regular HTML or Bootstrap components. If you are not familiar with that, I can refer once again to the <\/span>blog post<\/span><\/a><\/span> from my colleague Alexander or to one of the several HTML tutorials on the internet.<\/span><\/p>\n
    Introduce Reactivity – Callbacks<\/span><\/h3>\n
    As mentioned before, callbacks are the go-to way to make the layout interactive. In our case, they mainly consist of handling the dropdown as well as the button clicks. While the dropdowns were relatively straightforward to program, the buttons caused us some headaches.<\/span><\/p>\n
    Following good programming standards, every function should have precisely one responsibility. Therefore, we set up one callback for every button. After some kind of input validation and data manipulation, the ultimate goal is to redirect the user to the following site. While the input for the callback is the button-click-event and potentially some other input forms, the output is always the Location component to redirect the user. Unfortunately, Dash does not allow to have more than <\/span>one callback to the same output<\/span><\/a><\/span>. Therefore, we were forced to squeeze the logic for every button into one function. Since we needed to validate the user input at the attempt page, we passed the current values from the dropdown to the callback. While that worked perfectly fine for the attempt page, the button at the result page stopped working since no dropdowns were available to pass into the function. We had to include a hidden non-functional dummy dropdown into the result page to get the button working again. While that is a solution and works perfectly fine in our case, it might be too complicated for a more extensive application.<\/span><\/p>\n
    We need Cars – Data Download<\/span><\/h3>\n
    Now, we have a beautiful app with working buttons and so on, but the data are still missing. We have to include images, predictions, and explanations in the app.<\/span><\/p>\n
    The high-level idea is that every component runs on its own – for example, in its own docker container with its own webserver. Everything is just loosely coupled together via APIs. The flow is the following:<\/span><\/p>\n