BrandFrame-AI

AI-Powered text-to-image model for modern brands, creators/influencers & small businesses.

Comment

Inspiration

BrandFrame-AI was inspired by the challenges many small, medium business, creators and brands face when trying to create professional, visually appealing product content and images. Unlike the use or before the advent of AI to produce images, businesses were reverting back to the traditional way which requires access to a studio, proper lighting, editing skills, and sometimes having to spend alot on generating images for their brands which was always quite unrealistic and strenous. This project was created to remove that barrier by ensuring that brands and businesses are able to have access to highly aesthically visuals for thier products through AI so as to ease the tedious process of the traditional way of getting images which represents their brands.

What it does

BrandFrame-AI helps with producing highly visually and engaging images for brands, businesses and creators who are into producing images that promotes that brands on the social medium and, even outside of the social medium. BrandFrame focuses on speeding up product launches and ensuring businesses scales higher in te marketing cycles. It aims on producing beautiful images which creators, businesses either small or medium and brands to promote their products either through ads, on their websites, social media or e-commerce listings of what embody. BrandFrame AI is driven with the best interest at heart of democratizing branding and visual creativity of businesses and creators who struggles with the capability of maintaining consistent aesthetics across their website or business structure. Also, with the integration of resuable brand presets on BrandFrameAI that define styles, angles, colour, and shot types, it(BrandFrameAI) acts like a lightweight brand operating system/superpower which enables businesses to maintain coherent and consistent visual identity.

How we built it

BrandFrame AI was primarily built as a backend-first, API-driven system focused on reliablity, scalability and real-word cases usability. We had designed and designated an architecture that revealed step by step process which included; prompt generation, image genration, tighter authentication,request validation, external communication, seamless image uploading and data persistence. All these were carefullu structured and planned to ensure our users have a seamlesss and enjoyable experience of the application.

At the core of the application backend lies Laravel(php) structure which is responsible for handling authentication, image uploads, request validation and database operations. Larvel's structure and relationship with APIs allowed us to move & ship faster while keeping our codebase organised and maintainable.

User Authentication: our first step was building a tighter authentication for users in order to handle registration, login and logout, and other security measures endpoints for users. Plus, during the buildup, it was essential to note that every image genration and brand presets needed to be linked to a specific user and, not loosely for all users simultaneously. And so, we implemented the registration, login and logout endpoints early, ensuring that they were protected via the middleware in Laravel and had the capability to reliably identify authenticated user throughout the sytem.

Database Design: after authentication were in placed and tested, we migrated to database design; although, our first used database was MariaDB for handling schemas for users, brand presets, generated images, queues, shot types and also, whilst establishing relationship and integrity across the database before we had eventually moved to postgres for deploying on Fly.io This well structured foundation ensured that it was possible to linked and sought every generated image with both a user and specific brand preset.

Brand Preset Endpoints: next, we had moved to building endpoints which we specificially started and moved to the brand preset endpoint; this endpoints focuses on allowing users to store reusable brand configuration such as shot type, description, metadata and structured prompts. This step was crucial for consistency as it enables users to genearate multiple images while maintaing a unified and unique brand style. Presets were saved as a structured JSON, making them really flexible and easy to extend.

Image Generation Endpoint: we had also implemented this; this endpoint accepts a product image upload, shot types and optional description for requests extraction and handling. The uploaded image is stored securely, while a custom "PromptBuilder" helper dynamically constructs a well detailed prompt based on user input. This prompt is then sent to the Bria AI image generation API, which then runs, process and stored/saved images being generated.

Generated Image Data: this is entirely not an endpoint per se but, a named variable which contained the JSON data and request for image generation throgh the Bria AI API call. It contains the image URL, structured prompt, style, angle and metadata and was also written to be persisted in the database to make sure that users can retrieve, view and manage their generated images later.

Batch Processing Endpoint: we had outsourced ourselves and thought beyond just one image generation or two images generations which user might attempted while trying to generate images, and built batch processing to handle more than 20 requests of image generations by user concurently. The batch processing endpoint runs along with the Queue as it handles multiple calls at once. With the implementation of queue alongside batch processing, concurrent run of images is made possible and easy aand even at that much faster and quicker as it processes and runs images in the background(due to Queue jobs) and generate images quickly to users.

Challenges we ran into

Despite the finishing of this amazing and impactful project, they have also been many setbacks and take on which was also quite encouraging and, intriguing. Some of it includes:

Handling Empty Database Response: before the generating after deploying the API, the database had return an empty array, reflecting that no data was yet to be in the database which was so frustrating. 

$images = GeneratedImage::where('user_id', $request->user()->id)->get();
return response()->json($images); //unfortunately without the API, this had returned an empty array[]

** Database Enum Migration:** prior to updating and modifying the syntax for the "shot_type" table to sync with that of postgresql, I had experinced a syntax error.

$table->enum('shot_type', [
    'lifestyle','hero','flat_lay','context','white_background'
])->change(); // failed in PGSQL before proper migration fix

** Route Naming Conflict :** while running the fly.io logs after deployment, it had returned a report from Laravel complaining that two routes were sharing the same name.

Unable to prepare route [register] for serialization. Another route has already been assigned name [register].

** API Response Handling:** the api had unfortunately refused to come up with results for specific endpoints due to a small mishandling in the json requests.

 Log::info("BRIA RESPONSE RAW: " . $response->body());

** Github Action Workflow Not Triggering:** after installation of Fly.io for deployment of the API, we had we experienced a slight setback as our code set up were reverting to the "main" branch instead of "dev" which unfortunately then caused the code not to be deployed. Solution:

on:
  push:
    branches:
      - main
      - dev  // We added this

** Fly CLI Not Recognised:** after the installation of "fly" via the powershell, the command had refused to run on vs code editor terminal as it was got unrecognised. Solution: Added Fly CLI path to Windows PATH environment variable

C:\Users\YourUsername\.fly\bin\

** Window File Permission Error:** we had faced a window file error while trying to install Fly.io via the powershell and not only that, we also faced connectivity issues, and inability to update the powershelll to use the command "pwsh".

Error: failed to solve: archive/tar: unknown file mode ?rwxr-xr-x

** Window/Linux Case Sensitivity**: we had also experienced a case sensitity error(http ≠ Http) which stemmed from Linux while trying code for deployment via the fly command line "fly ssh console"

"autoload": {
    "files": [
        "app/Http/Helpers/PromptBuilder.php"  // Capital H
    ]
}

** SSL Error**: during the backend development of BrandFrame-AI project, we had experienced a slight SSl error which served as a misconfiguration for our script file.

   curl.cainfo = "C:\ssl\cacert.pem"

Accomplishments that we're proud of

** Built a fully functional AI Image generation System.** ** We had designed a clean and structure API which was consistent, reliable and handled error properly.** We had implemneted a secure and organised data storage which was scalable. We had created a resuable prompt building system which enable users to get their prompts converted into visually appealing images. ** We solved Real-World Integration Issues like the integration of BriaAI for AI image generation and particulary bogus errors we had solved along the way.** ** We had also implemented CI/CD with GitHub Actions.** ** We had created a system for brand consistency such as enabling users to create presets and apply the them to previous generated images.** ** We had also worked with and scaled through Multi-Region deployment with proper infrastructure while using Fly.io for deploying the API.** ** We had also built a scalable Queue Architecture to handle images generations via jobs so as to ease troubles of users while trying to generate multiple images at once.** ** Against the odd, we we were capable of building with and also integrating multiple complex services such as Fly.io(for deployment), Redis(for queue & caching), GitHub Actions(CI/CD), Upstash(Managed Redis via Fly.io), Postgresql(for database handling & persistence) and AI API Integration.**

What we learned

Windows ≠ Linux: Case sensitivity matters. Fly.io secrets: there is a bigger need for both DATABASE_URL AND individual connection vars such as API Keys, env etc. while uisng fly.io for deployment. API-only applications: while building, i learned that we don't need frontend assets/Vite. Local build on Windows = I had learned that it's preferably much better to use GitHub Actions instead of local build on wndows while attempting to deploy a Laravel API on fly.io PostgreSQL syntax: Different from MySQL/SQLite.

What's next for BrandFrame-AI

** More Photography Presets:** more photography presets will be added to enhance users capabilties to use vastly large amount of presets for images they may tend to generate. This includes Studio shots, Outdoor product placement and minimalist e-commerce white backgtound.

** Addition Of Image Editing Tools:** several image editing tools will be implemented after such as background removal, colour correction, upscaling, and light retouching.

** Analytics For Brands:** a simple dashboard will be built to show brands, small businesses stats on their most used presets, most generated images categories, most generated images shot types,most generated product categories and also weekly image generation activity.

** Automated Social Media Crops:** we will be implenting crops feature that will ensure that after image generation, BrandFrame-AI will be able to automatically exports sepcific ratios for instagram post/stories, facebook ad and other flat-lay shot types for brands.

** Smart Prompt Suggestions:** will be implemented to enhance how user will be able to use the services of BrandFrame-AI to generate images.

Built With

Share this project:

Updates