Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Fixing Google Nano Banana Pixel Art with Rust

github.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Show HN: Fixing Google Nano Banana Pixel Art with Rust

#31

Post by krisoft »

im3w1l wrote: post #30
krisoft wrote: post #15

It feels weird to me that on the before/after comparision they felt the need to zoom in on the “before” but not on the “after”. Either both should have the magnifying glass or neither. This just makes it hard to see the difference.

The purpose of zoomed out comparison is to show the quality reduction of applying this tool. The purpose of zoomed in before picture is to show how a typical pixel misalignment. Aligned pixels can be easily imagined.

> The purpose of zoomed out comparison is to show the quality reduction of applying this tool.

Reduction? Shouldn't the tool be improving the quality of the image? If it is reducing the quality then why do it?

> The purpose of zoomed in before picture is to show how a typical pixel misalignment.

Okay, but how does this supposed "misalignment" look on the picture? Would I even notice it? If not, does it matter? Did they just zoom in, and draw a misaligned grid over the zoomed in image? Or the grid fault lines are visible in the gestalt?

> Aligned pixels can be easily imagined.

Everything can be easily imagined. Misaligned pixels can be imagined. They could just write "our processed images look better" and let me imagine how much nicer they are. The purpose of a comparison is to prove that they are nicer/better/crisper whatever they want to claim.

Re: Show HN: Fixing Google Nano Banana Pixel Art with Rust

#32

Post by coldtea »

krisoft wrote: post #31
im3w1l wrote: post #30

Earlier quoted context omitted.

The purpose of zoomed out comparison is to show the quality reduction of applying this tool. The purpose of zoomed in before picture is to show how a typical pixel misalignment. Aligned pixels can be easily imagined.

> The purpose of zoomed out comparison is to show the quality reduction of applying this tool. Reduction? Shouldn't the tool be improving the quality of the image? If it is reducing the quality then why do it? > The purpose of zoomed in before picture is to show how a typical pixel misalignment. Okay, but how does this supposed "misalignment" look on the picture? Would I even notice it? If not, does it matter? Did th…

>Okay, but how does this supposed "misalignment" look on the picture?

People who are the target audience for this tool already know.

>Would I even notice it?

Yes.

>The purpose of a comparison is to prove that they are nicer/better/crisper whatever they want to claim.

They don't need to prove it to their target users. They already know the problem (for which several tools exist).

Re: Show HN: Fixing Google Nano Banana Pixel Art with Rust

#33

Post by im3w1l »

krisoft wrote: post #31
im3w1l wrote: post #30

Earlier quoted context omitted.

The purpose of zoomed out comparison is to show the quality reduction of applying this tool. The purpose of zoomed in before picture is to show how a typical pixel misalignment. Aligned pixels can be easily imagined.

> The purpose of zoomed out comparison is to show the quality reduction of applying this tool. Reduction? Shouldn't the tool be improving the quality of the image? If it is reducing the quality then why do it? > The purpose of zoomed in before picture is to show how a typical pixel misalignment. Okay, but how does this supposed "misalignment" look on the picture? Would I even notice it? If not, does it matter? Did th…

The way I see it, converting something to pixel art is akin to lossy compression or quantization. The goal is to retain as much detail as possible given the constraints.

The exact way that pixels are misaligned is a feature of the specific AI models that generated the almost-pixel art.

Re: Show HN: Fixing Google Nano Banana Pixel Art with Rust

#34

Post by IgorPartola »

forgotoldacc wrote: post #28
IgorPartola wrote: post #21

This is perfect! I have had such a time with Nano Banana asking it to generate some very simple pixel art. One of the worst things is that it cannot seem to generate transparent backgrounds or even solid ones. It’s always some blotchy cloud of off-white pixels or a simulated fuzzy grid that shows up in some places. I will need to give this a try to clean up some of what I had to try by hand.

I simply cannot understand people who'll spend forever trying to get AI to generate basic art that any amateur with a bit of practice could do in a minute.

I am terrible at this kind of art. I could find another amateur but the "REPL" for that is just too slow for prototyping. No it isn't perfect, but tools like this make it better, and it means that I can generate something in an hour of my time rather than spending many hours finding and interfacing with another amateur or professional. Plus the cost is better. While generating one really high quality asset is almost certainly better with a pro, generating three dozen prototypes to choose from isn't.

Re: Show HN: Fixing Google Nano Banana Pixel Art with Rust

#36

Post by cipehr »

skavi wrote: post #14
cipehr wrote: post #4

Is it possible that some of the reason pixels are messed up is because of the watermarking? https://deepmind.google/models/synthid/ Or is it purely because the models just don't understand pixel art?

I wonder if this would be a simple (limited) example of defeating the watermarking? Surely there's no way SynthID is persisting in what is now a handful of pixels.

Agree with you! I wonder that myself, also minor unperceetable pixel color differences can be corrected as well i'd guess?
Post reply on HN