[HN Gopher] Show HN: A little side project, a watercolor art gen...
       ___________________________________________________________________
        
       Show HN: A little side project, a watercolor art generator
        
       Hi HN - this is a little side project I threw together. Some
       implementation details: image processing is all done with headless
       GIMP (running inside a Docker container) through its built-in
       Python API. It's _very_ slow (about 50 seconds/image), and
       currently it processes exactly one image at a time. The website is
       built with NextJS; payments are processed by Stripe.  I've had the
       best results with pictures of houses, although certain photos of
       people or nature can look neat, too. (For example:
       https://brushify.art/s/ruYmQWk, original photo from
       https://en.wikipedia.org/wiki/Pillars_of_Creation.) The effect
       obscures the edges of the photo, so images with plenty of margin
       around the subject work best.  Something I'd like to play around
       with is swapping the GIMP script for an AI-based process (maybe
       using something like Stable Diffusion?), with the goal of
       generating images that look more handmade (something like these:
       https://www.etsy.com/ca/search?q=watercolor+house). I have exactly
       zero AI experience though, so there would be a bit of a learning
       curve.  Would love any thoughts or critiques!  ----  edit: remove
       unrelated details
        
       Author : nfriend
       Score  : 168 points
       Date   : 2022-11-11 14:32 UTC (8 hours ago)
        
 (HTM) web link (brushify.art)
 (TXT) w3m dump (brushify.art)
        
       | synapticpaint wrote:
       | It sounds like your app turns photos into a watercolor style
       | image? You can definitely do this faster with Stable Diffusion
       | (~6s per image before optimization).
       | 
       | Here's how I would approach it: train a dreambooth model on
       | watercolor style images, then run image-to-image using that
       | model.
       | 
       | For examples of what dreambooth models can do see:
       | https://synapticpaint.com/dreambooth/info/ (sample images here
       | generated using a "modern disney" style model).
       | 
       | If you need help getting this set up feel free to email me! This
       | stuff is probably not harder than getting gimp to run in a
       | container.
        
         | rlv-dan wrote:
         | This comment make me sad. Replacing human creativity with "ai"
         | is like we've reached the peak so no need to put any effort
         | into life anymore..
        
           | jamesgreenleaf wrote:
           | Human creativity isn't being replaced; new layers of it are
           | being added.
        
           | adammarples wrote:
           | running a GIMP script is hardly the opposite
        
           | synapticpaint wrote:
           | I don't think that AI image generation in its current form
           | replaces human creativity. You still need a human to guide
           | the process, compose the image, judge the output, etc. What's
           | being automated is the manual, traditional process of
           | painting and drawing.
           | 
           | I see this technology as more analogous to hand writing books
           | -> printing. I predict that more people, not less, will be
           | involved in creative industries related to visual arts
           | (design, film, illustration, animation, etc.) as a result of
           | this technology becoming more accessible.
        
             | JoeAltmaier wrote:
             | That's skipping over all the skill and training needed to
             | draw, well, what most of us are unable to draw.
             | 
             | We can all write words with a pencil. That's not the same
             | as drawing an original character or scene with skill.
        
           | [deleted]
        
           | JoeAltmaier wrote:
           | Yes, this is different from much of art history. Instead of
           | coming up with original characters or styles or backgrounds
           | and palettes, we just ask a computer to do it all and usually
           | by copying somebody that _can_ do those things.
           | 
           | Art will take a hit to be sure, and the brunt of it will be
           | taken by artists with actual skills.
        
         | nfriend wrote:
         | Very interesting, I will look into this! Thanks!
        
         | wongarsu wrote:
         | Stable Diffusion on beefy hardware is faster than OPs process
         | in OPs docker container, but I don't think we can judge from
         | this that OP uses a slower process. For all we know this is
         | running on the equivalent of a $10 Digital Ocean droplet.
        
           | nfriend wrote:
           | Currently running on a t3.medium AWS EC2 instance! (My max
           | budget is currently $50/month since I get that much in AWS
           | credits each month for building an Alexa skill a few years
           | back.)
        
           | synapticpaint wrote:
           | That's true. I just wanted to provide some context for OP and
           | others reading since they mentioned an interest in AI
           | generation, and I think not everyone knows that dreambooth +
           | stable diffusion has this kind of capability.
        
       | stoobs wrote:
       | Estimated wait time: 6 hours, 33 minutes
       | 
       | Oops, sorry OP for all the traffic :D
        
       | _448 wrote:
       | In addition to upload/drop image, you could also provide an
       | option to enter an URL of online image. That will make it easy
       | for users to try the project very quickly. Then provide an
       | ephemeral preview URL to see the output.
        
       | wingworks wrote:
       | The results are pretty cool, though it's a shame it cropped the
       | edges.
       | https://brushify.art/result/aa4e68ae-d9de-4673-830e-f88032ec...
        
       | kuu wrote:
       | My recommendation: Add examples on the main page, so the new
       | users don't need to overload your site.
       | 
       | Otherwise the process is the following:
       | 
       | I enter the page -> Upload image -> See 4h of queue for getting
       | my result -> I close the tab, leaving there a pending task.
        
       | andai wrote:
       | Here's a suggestion, port it to run in the browser. Free
       | parallelism, because every user brings their own hardware :) So
       | it scales infinitely, for free.
        
       | moffkalast wrote:
       | > Estimated wait time: 2 hours, 35 minutes
       | 
       | Bruh moment.
       | 
       | I suppose it would make more sense to WASM the implementation and
       | run it clientside?
        
         | [deleted]
        
       | serge1978 wrote:
        
       | diego_moita wrote:
       | I just loved the messages while it is processing!
        
       | _dan wrote:
       | Perhaps put the wait time on the homepage - If I'd known you were
       | running at an 8 hour delay I wouldn't have added to it!
        
       | the_arun wrote:
       | There should be a smart phone app for this already, right?
        
       | mlvljr wrote:
        
       | pknerd wrote:
       | The message on the page:
       | 
       | It's a busy day! There are currently 512 people in front of you.
       | Please keep this tab open!
       | 
       | Estimated wait time: 7 hours, 7 minutes
        
         | thih9 wrote:
         | 1h later it's:
         | 
         | > It's a busy day! There are currently 1073 people in front of
         | you. Please keep this tab open!
         | 
         | > Estimated wait time: 14 hours, 54 minutes
        
       | xchip wrote:
       | Why do we need to know you did this while on paternity leave?
        
         | nfriend wrote:
         | Thought it was some fun context, but I can see why it might
         | come off as a strange detail to include. Edited to remove the
         | distraction.
        
         | [deleted]
        
         | KraxKrokat wrote:
         | Why do we need to know that this was made at all? Let the guy
         | share a bit of context about his little side project (cool work
         | btw!). Why are you so snarky today?
        
           | yuvalkarmi wrote:
           | I feel the same way. I like the context and it adds a bit of
           | story around this.
        
         | pvg wrote:
         | _Be kind. Don 't be snarky. Have curious conversation; don't
         | cross-examine._
         | 
         | https://news.ycombinator.com/newsguidelines.html
        
         | quest88 wrote:
         | What's the point of your comment? Why do you care? Why do we
         | need to know about this project at all? Why is anything posted
         | to hackernews at all? Why?
         | 
         | Please discuss the project if it's interesting to you,
         | otherwise move on. There is a human who posted the project.
         | Maybe they were nervous to post because of the feedback they
         | get. Maybe they wish it ran faster (as they noted on its
         | slowness), and provided some context by stating they couldn't
         | devote 100% focus to this project because they were caring for
         | a new born baby.
        
       | nfriend wrote:
       | Sorry all for the long wait times! Was not expecting much
       | interest. At the very least, I need to look into removing photos
       | from the queue when people exit the page.
        
         | wishinghand wrote:
         | How is the image processing being done? In broad strokes,
         | what're you doing with the Python API?
        
           | dylan604 wrote:
           | Do water color artists use broad strokes?
        
             | gilleain wrote:
             | Ho ho. As far as I know, you can make a wash with a broad
             | brush.
             | 
             | Watercolour is a nice way to paint blurry things like
             | oceans and clouds, which involves broad strokes.
        
         | selcuka wrote:
         | I wouldn't even let people add new images to the queue if the
         | wait period is over, say, 10 minutes.
        
           | nfriend wrote:
           | Not a bad idea!
        
         | jansan wrote:
         | It says I should keep that tab open for the next 17 hours. What
         | happens if I still close it?
         | 
         | Congrats for the unexpected success :)
        
           | nfriend wrote:
           | Unfortunately nothing at the moment! Currently working on
           | removing images from the queue if the user has left the page
           | (which I'm guessing is the case for about 99% of the current
           | queue).
        
             | nfriend wrote:
             | Fixed! Now abandoning the tab will remove the image from
             | the queue.
        
         | nfriend wrote:
         | Moving it to a larger AWS instance - will be down for a few
         | minutes!
        
           | nfriend wrote:
           | Done - upgraded to a t3.xlarge. Now it can process 4 images
           | in parallel. Still not enough to keep up with HN demand, but
           | it should chew through the queue a _bit_ faster.
        
       | bambax wrote:
       | > _I 'd like to play around with is swapping the GIMP script for
       | an AI-based process_
       | 
       | Dall-e offers an API with some limitations (max 4MB square PNG,
       | content filtering):
       | https://beta.openai.com/docs/guides/images/usage
       | 
       | Photopea.com has a watercolor filter, in JS, all client side.
       | It's not very good ATM so there's certainly room for improvement.
       | Doing it all client side would solve the queue problem.
        
       | [deleted]
        
       | notyourav wrote:
       | 14h wait time
        
       | Kiro wrote:
       | Why NextJS for this?
        
       | effnorwood wrote:
        
       | gregoriol wrote:
       | If you can make it with GIMP, you could probably look into OpenGL
       | shaders to do it directly yourself: the processing could be
       | faster and would provide you with more flexibility and coding fun
       | times. I don't know of server-side libraries for that, but on iOS
       | we have MetalPetal which provides some filtering features like
       | ones in Gimp/Photoshop.
       | 
       | Have fun!
        
       | d1l wrote:
        
         | yuvalkarmi wrote:
         | Dude what's with the toxicity? Who says he's not helping? Also,
         | babies sleep sometimes... Lay it off with the snarky / toxic
         | comments - totally off topic to the submission.
        
       | Kaotique wrote:
       | Looks really nice!
        
       | yuvalkarmi wrote:
       | This is super cool! Didn't know you could run GIMP in headless
       | mode.
        
       | XCSme wrote:
       | I hope the result is worth the wait!
       | 
       | > There are currently 1069 people in front of you. Please keep
       | this tab open!
       | 
       | > Estimated wait time: 14 hours, 51 minutes
        
         | TT-392 wrote:
         | I have been stuck on 9 hours for a while now
        
         | [deleted]
        
         | calibas wrote:
         | Currently:
         | 
         | >There are currently 1200 people in front of you. Please keep
         | this tab open!
         | 
         | >Estimated wait time: 16 hours, 40 minutes
        
       | tristanbvk wrote:
       | Very vool
        
       | hollowdene wrote:
       | Can't see myself paying $5.99 for one of these, but it's nice. I
       | appreciated the fun messages in the progress bar.
       | 
       | PS: Congrats on the little one. :D
        
       | ale42 wrote:
       | Now: Estimated wait time: 9 hours, 49 minutes...
       | 
       | The hug is getting tighter ;-)
        
         | [deleted]
        
         | rikroots wrote:
         | "It's a busy day! There are currently 1048 people in front of
         | you. Please keep this tab open! Estimated wait time: 14 hours,
         | 33 minutes"
        
       | rikroots wrote:
       | Creating a watercolor filter which can be applied to an image
       | dragged into a website <canvas> element is on my list of Fun
       | Things To Do Over The Holidays - but having previously looked at
       | the the mechanics that need to feed into the filter ... well it
       | looks like I'd be jumping down a rabbit hole of complex maths and
       | generative art approaches[1][2]. It's a complex problem space and
       | I'm not sure I have the brain power and tenacity to do a good job
       | of it.
       | 
       | [1] - Tyler Hobbs (2017) - a guide to simulating watercolor paint
       | with generative art -
       | https://tylerxhobbs.com/essays/2017/a-generative-approach-to...
       | 
       | [2] - Curtis|Anderson|Seims|Fleischery|Salesin (undated) -
       | Computer-Generated Watercolor -
       | https://grail.cs.washington.edu/projects/watercolor/paper_sm...
        
       | jasonjmcghee wrote:
       | Fortunately OP, experience with AI is generally unrelated to
       | success with Stable Diffusion / DALLE.
       | 
       | What you want to gain is experience with prompt engineering for
       | these tools.
       | 
       | Here's a good resource https://openart.ai/promptbook
        
       | tfsh wrote:
       | The example looks cool, but I'm currently in an 11 hour queue :(
       | 
       | Any chance of porting this to the web using WASM? I've used
       | ImageMagick in the browser before, I've never used Gimp, but if
       | there's enough overlap you could use the former. That's of course
       | assuming two things:
       | 
       | 1) you have the time
       | 
       | 2) you're happy to port the closed source, source code to the
       | client
       | 
       | Both of which are perfectly fine to answer with a "no" :)
       | 
       | Also, I think it would be prudent to terminate the request if the
       | client instance is destroyed. Right now I assume there's a bunch
       | of requests being processed for users who have closed the tab.
        
       | hackmiester wrote:
       | I'm going to go against the grain here. If this were my project I
       | would try to spin up render machines dynamically in response to
       | load. (Similarly to how gitlab CI runners can be spun up
       | automatically, for instance.) There is no need to replace a
       | working technology stack to make it faster. 1 minute is a
       | reasonable wait time, and if your wait time goes over 5 minutes,
       | then spin up some more workers.
       | 
       | Plus we have to be real and say, is the only reason the queue so
       | long, because you let a bunch of nerds on HN add to the queue for
       | free? I'm guessing the answer is, "probably." No need to engineer
       | a fix for a problem that will typically not exist.
        
         | [deleted]
        
       | asmosoinio wrote:
       | Site seems to be down - could you post the example output on some
       | image sharing site?
       | 
       | Seeing example output would be interesting, even if service is
       | hugged to death.
        
       | justchad wrote:
       | Nice, this is really cool! I don't see myself waiting for my
       | photo to process as it's a ~4 hour wait but the example image is
       | cool.
       | 
       | Like you said I bet using Stable Diffusion would speed this up
       | dramatically but who knows if you'll get the same effect on your
       | images.
        
       | iruoy wrote:
       | It's not exactly a hug of death, but a wait time of 90m is a bit
       | long. I hope that people that leave the queue won't be processed.
        
       ___________________________________________________________________
       (page generated 2022-11-11 23:00 UTC)