Building DUSK Local: A Dev Diary
The first version of DUSK relied heavily on cloud-based Google Gemini, which made it quick to test but also introduced some awkward baggage. Commercial Scaling, Future Proofing, Long-term Reliability, Costs to run, and Cost to generate.
After much consideration, rather than turning the original prototype into a public web app, I made the decision to try rewriting it as a local-first approach. The aim is for as much of the app as possible to run on the user’s own machine. The browser can still act as the studio where the work happens, but it should not be trusted with sensitive keys, access control or important processing decisions.
That became the foundation of DUSK Local.
The Gemini-specific code from the earlier version has now been removed, and the project has been rebuilt as a more flexible lighting visualisation harness. Instead of being tied to one AI provider, DUSK Local can work with a local engine, a simple preview renderer or a custom provider endpoint.
The aim is to make the app less dependent on a single model or company, and more adaptable as the AI image landscape continues to shift.
One of the biggest steps forward has been the DUSK Local Engine. This runs on the user’s machine and handles the image generation work. It can connect to local model files and return the results directly to the app.
Some of the more advanced model support still passes through a hidden compatibility layer, so there is still some engineering tidying to do. Even so, the important shift has already happened. DUSK is no longer just a web prototype sending requests to one cloud model.
AI models can be surprisingly literal.
Draw orange guide marks onto an image and there is always a chance the model will proudly reproduce them in the final picture. A fair amount of work has gone into teaching the system that these marks are instructions, not part of the design.
In other words, orange means “do this here”, not “please decorate the wall with orange scribbles”.
The lasso tool has been another important step. Sometimes the user needs to say, “Put the lighting effect here, not somewhere vaguely similar on the other side of the image.”
Lasso mode makes it possible to select a specific area, although getting it to behave properly with the new local configuration has taken several rounds of trial and error.
At one stage, the selected area became too dark. Then the lighting effect worked, but the rest of the scene did not respond enough. Then the whole image reacted, but the light refused to stay inside the selected area. Placement improved, only for temporary guide marks to appear in the finished image.
Each version solved one problem and introduced another.
That is probably the most honest summary of development so far: a series of small victories, each followed by something new to fix.
Still, those fixes have moved the project forward. Area Inpaint now behaves much more like the intended tool. The selected area controls where the lighting is placed, while the rest of the image can still respond through night-time atmosphere, shadows, reflections and spill.
Another quieter improvement is image handling. DUSK Local now has clearer upload limits and supports common image formats such as JPG, PNG and WebP.
So, what has actually been accomplished?
The main rewrite is now well underway. DUSK has moved away from its original cloud-heavy prototype and into a local-first structure. The old Gemini-specific workflow has gone. The app now has a clearer DUSK Local identity, a local engine, provider settings, presets, image history, comparison tools, downloads, and Area Inpaint.
Next up will be getting the Light Painter tool to work, as well as the luminaire asset importer.
What then remains is the less glamorous work of turning it into a proper product.
The local engine needs easier installation, clearer diagnostics and friendlier error messages. Longer generations need better progress feedback, so the user knows whether the app is working, thinking or quietly having a crisis.
Model settings need to become easier to understand, with sensible profiles for quality, speed and different model types. Project saving also needs to move beyond browser storage, allowing users to close the app and return to their work properly.
Once all sections of the application are running successfully in Local mode, I will move on to Cloud API operation, and potentially need to run back through each step.
I will also need to look at how to assist people in knowing what local model configurations work best with their hardware.
Eventually, DUSK will need to be packaged as a real desktop application rather than a development server running alongside a separate local engine process.
The work has also been a useful reminder that building AI tools is not just about producing one impressive result. The real work sits around that result: how the user communicates intent, how the system interprets it, how mistakes are corrected, how privacy is handled, how versions are compared and how the tool responds when something goes wrong.
DUSK is still an MVP, but it is now an MVP with a stronger direction.
Dan | BloqDigital is a lighting designer and digital artist based in the UK, who writes about Art, Technology, AI and Culture.
Have any thoughts on this article? I’d love to hear them! Drop them in the post’s comments section and let’s talk about it.
Thanks so much for reading! If you really enjoyed this post, please consider sharing it with friends as this really helps us grow! Or you can subscribe to receive future posts.