SaaS – IMG.LY Blog

Building the Creative Engine of the Digital World

Daniel — Wed, 22 Apr 2020 12:42:48 GMT

Since releasing our first Software Development Kit (SDK) for photo editing in 2015, it quickly found its way into the hands of thousands of application developers. The demand allowed us to ramp up our efforts to expand our SDK to cover more platforms, add features and launch VideoEditor SDK.

At the same time, two very important things happened to us.

First of all, we got experienced in building rendering engines, while learning in-depth about the requirements of processing photos for professional and semi-professional use-cases, on every platform. Our team leveled up big time, to a degree where we are confident there aren’t many teams with such a domain-specific expertise.

Secondly, we gained critical insights into the visual creation process across many different industries, ranging from print services, social networks to marketing tools. In these processes, photo editing is only one part of the creative flow. There are topics like layouting, animation, generative design and many more, which go beyond the mere editing of an image, but are still essential to the business case.

Our vision is to fill the obvious gap, providing a holistic solution that allows users to map entire creative flows into a tool. By leveraging our technology our customers will become a lot faster and more competitive in their markets.

Six months ago, we decided to build the foundation for this vision and kicked off the development of UBQ, an engine empowering a new generation of tools for creativity.

It’s time to shed some light on our creative engine.

What is a Creative Engine?

Before we go forward, let’s establish what we mean by a creative engine. In general, an engine is a platform that allows developers to create tools that support creators to perform specific tasks such as editing photos, creating visual appealing posters, or social media posts. From our perspective, a creative engine will ease the development of design tools for various niches and as such it must be easily adaptable for different usage and user requirements.

To ensure that we don’t have to reinvent the wheel for each creative tool, a creative engine provides building blocks especially targeted to creative output. Some examples for these are:

High-quality image adjustment, editing, filtering, and manipulation.
Automated layouting of design elements on a canvas.
High-quality text rendering and layout algorithms.
Support for various industry-standard assets, image, and video formats.

However, these are only some of the basic features – there are far more advanced things that a creative engine can provide.

On the one hand, this may include scripting tools to ease the generation of generative art or automation for tedious design tasks via automated image segmentation.

On the other hand, there are also tools that not only help the individual creator but ease the cooperation and collaboration between multiple creators and editors. The details may vary, but it can be as simple as defining formats to exchange assets and designs between creators or even allow the simultaneous editing of their creation.

Introducing the UBQ Creative Engine

With UBQ we strive to lay the groundwork for modern visual and communication design.

Believing that these days, a good design tool has to be there for you every step of the way – it has to be ubiquitous**.** Let us explain what this means for us.

Usable on any Platform

In this sense, we want it to be easily accessible to everyone, and as such the UBQ stands for its availability across multiple platforms. It is conceptionally web- and mobile-first but is also available for classic operating systems such as macOS, Linux, and Windows, while being easily portable across various platforms.

Unified Rendering, Generative, and Inference Engine

While our previous products focused on processing a single image or video, our scope is greatly extended with UBQ. Besides being able to process multiple images, with effects such as filters, adjustments, and so forth, in UBQ we generalized images to a concept we call Design Blocks. As such, static images are not the only source of data. It can be anything, even code that generates the visual input. In turn allowing that generative patterns and complex generative art is processed directly in the engine.

We put a lot of work in the last years into modern tools for automation to help creators get rid of time-consuming tasks such as image segmentation, color adjustments, and many others. Our foundation for this stems from modern machine learning and neural network advancements. As such UBQ supports executing neural networks and inferring information. Thus basically allowing any neural network to be part of a design generalized in what we call Compute Blocks*.*

Collaboration – Interact in Realtime with other Creators

The cooperation and collaboration between multiple creators are dear to our hearts. Therefore, we believe that creation is not only the effort of an individual but of many.

UBQ will enable multiple creators to work together. Thus, allowing a design team to work together, share thoughts and assets instantly. Consequently, this constributes in accelerating their workflows and enriching their creative process.

All that is reinforced due to the multiplayer approach to design as well as reusable design elements.

Creators shall be enabled to work together locally as well as remotely and interact on the same design at the same time.

Cooperation – Ease Exchange of Designs with your Peers

Besides the collaborative aspect, UBQ is built around the interaction of creators and non-designers – which we refer to as editors.

Editors will be enabled to take existing designs and adapt it to their needs, by either just giving instant feedback to the creators, changing color palettes to fit the needs of their corporate design guidelines or changing images and text passages to make a design appealing to their audience.

Design Blocks – Smart and Reusable Design Element

Another important design decision is the ability to exchange and reuse design elements between several projects. Therefore, UBQs foundation is built around the concept of smart design elements that we call blocks.

Blocks are reusable design elements that encapsulate complex and tedious design tasks.

They currently come in two flavors, Design and Compute Blocks ranging from simple predefined image adjustments settings to automated image segmentation as well as predefined adaptable design elements.

From our point of view, creators should not have to spend their time with the recreation of preexisting designs. They should not have to watch tutorials just to get to the same output as someone else before. In UBQ, these design blocks are the core foundation for building adaptable and interchangeable designs.

Design blocks respond to the available space, adapting their content accordingly and may include complex logical rules or just a combination of assets. UBQ has all batteries included, providing a rich library of predefined blocks. By design, blocks can easily be built from a combination of other blocks or by using a scripting language similar to processing or p5.js to allow even generative and parametric design.

Final Words

As of April 2020, we are working on the UBQ creative engine for almost half a year now incorporating knowledge from 5+ years developing our SDKs.

We believe we can make an impact on how designs and design-tools are created, adapted and distributed. We are interested in your feedback and open to discussions, also we are looking for people who want to get involved as team members, early adopters or just want to play with it. Expect some demos during the end of summer showcasing what the UBQ engine is capable of.

Soon, we will get back to you with more exciting news.

Stay tuned!

We’re hiring!

Oh, and by the way, we’re hiring a Senior Frontend Developer at img.ly to reinforce our team and help shaping the frontend of our new design tool. Check out the job here and drop us a line, if you are interested.

Build or Buy?

Daniel — Thu, 02 Nov 2017 00:00:00 GMT

For many years, we at IMG.LY and our partners at 9elements have been developing various applications for customers and ourselves. Often, we had to decide whether to build everything from scratch or to consider third party components. Sounds familiar?

As developers, makers and tinkerers we often tend to build everything ourselves. It seems to be in our nature and part of who we are. Truth be told, this is the point where we often got irrational.

Taking a good look at modern application development, we quickly realize that everything is getting more complex in a tremendous pace. While it was feasible to develop apps without any third party libraries back then, it has become more or less of a standard to employ third party libraries or tools that solve certain problems for us. Nowadays, there are a lot of features that are must haves and simply expected to be in your product.

Thus, we are more aware than ever when it comes to the decision whether to build or buy.

Decisions

Most often, our resources are not endless. With limited time, money, and labour power we always struggle to make the decision whether to build a certain component of our software ourselves or buy it from a third-party.

But why do we struggle? Are we sure we can do it better than everybody else? Are we not trusting the third-party? Do we just think it is cheaper to do it ourselves? Or, do we just underestimate the amount of work that is required to build that one component?

Most certainly we know that software, even a small app, can be a complex beast that is comprised out of a lot of components. Even more surely, our idea or product should stand out of the masses. So, should we really spend too much time building a component or rather focus on getting things done efficiently? How do we set the priorities?

Priorities

Probably, we want to focus on the things that set our product apart from all others, may it be a singular specific feature or a novel combination of already existing ones.

Surely, most of us will never consider writing their own relational database like PostgreSQL. But, what about features such as payment, authentication or a content management system?

Speaking from experience, most of us won’t even think about implementing payment themselves and eventually, we will use a popular SaaS such as Stripe. But, what about authentication? Would we build that ourselves?

Thinking about all the details that you need to account for when building an authentication system, it becomes obvious that more is needed than just providing a simple registration with username and password. Depending on the software we are developing, people might expect to be able to login with their social logins via e.g. Facebook or GitHub. Also, we would need to provide a way to reset passwords, send emails on registration and so on. Over time, the list of requirements will grow and we will be forced to spend our precious resources on it, whether we want it or not.

So, why not just let someone else do the job for you and solve all these problems?

Don’t we trust services like Auth0 to solve all these problems for us, or what is the reason we build those things ourselves? Evidently, if our product is an authentication system we should build it ourselves. But, let’s be honest, most of the time it is just something we need for our product and nothing we care about deeply.

Unfortunately, we know that everything comes at a price. In case of Auth0, the login data may not be any more in our possession. However, are we sure that it is really bad? We tell ourselves that we can protect our data in a way that no one else would have access, no data would be leaked and so on. At least, that is what we would be thinking, right? But, are we sure that we can protect the data better than the service whose one and only task is to care about exactly that? And what about backups? Do we really want to put our resources into creating and checking that our data is properly backed up and restorable in case of a server failure? Probably we won’t and in many cases it would be a good idea to let someone do the job who does it on a day to day basis. Being completely honest with ourselves, we realized that:

By zeroing in on one specific problem, we can build better and more advanced tools than we could by trying to solve multiple problems at once.

We experienced first hand how much time and effort is required to tackle one specific problem when we needed a photo editing solution as part of one of our projects. In that particular case, we needed to go down the rabbit hole and build it ourselves. Back then, we didn’t have any other option as there was no component available that we could have used.

Was it a good idea? Probably not for the project but while building the components we realized that others could benefit from our learnings. This is basically why we started building and advancing our PhotoEditor SDK.

Apart from the previous mentioned pros and cons about building and buying, there is also another important factor: These services cost money and most of us will look at the pricing and believe it may be too expensive. Especially, if you have to take out your credit card and start a subscription that may feel like slowly draining your bank account. Even more so if you’re a small business or startup and every additional expense poses a threat to your project as a whole. However, this is the time to really weigh your options.

Time is Money

We always hear and rephrase the good old time is money slogan. And this is true in many ways. Even if we don’t care much about the cost of our own time, we would still have to invest it to build said feature and by that might delay the whole product. Do we really want to spend that time and delay our whole product?

Ok, assuming we don’t do it ourselves and we have a team of developers and parallelize our efforts, we still need to pay for it with, and let’s be honest … money.

According to PayScale the average salary of a software developer is around 45k€ in Germany. Considering that we work around 220 days per year, each day would at least cost us approximately 200€, but to be fair it will surely be more. Depending on the software component you are considering to build or the SaaS we consider to use, we most surely would get a lot more for our 200€ than what we could build in one day. And, if we are honest, 200€ are definitely not enough to develop any feature that requires more than just a few lines of code.

Final words

Summing it up, we should definitely not just buy every component from a third party or subscribe to every SaaS, but we should weigh carefully in which cases we really have to build it ourselves or when buying is the better option.

The whole point is that whether you buy some of your components or build everything yourself really doesn’t matter as long as it’s the smartest decision for your business. And if you automatically shy away from solutions that cost you something and decide to build it yourself no matter what, that decision might cost you a whole lot more.

The good thing is, that there is a trend that third parties tend to focus on more granular problems, which allows us to make the distinct decision whether to build or buy a specific component of our application.

Thanks for reading! To stay in the loop, subscribe to our Newsletter.