Hacker News Reader

Comment by Youden | Hacker News Reader

Interesting but for photography at least, there's a massive hole: RAW support. What they've implemented is very limited and basic, nothing like parity with Lightroom or Photoshop. Just try loading a RAW photo into Lightroom/Photoshop and put the window next to Lightcraft/Photocraft - the results are completely different and not in a good way. Lightcraft's image looks like an amateur attempt at RAW processing from first principles, without any of the most basic colour profiles and adjustments that Lightroom applies. Photocraft doesn't even offer RAW processing, it just dumps the raster straight in.

I'd treat this as completely new, far from complete software heavily inspired by the Adobe Suite, rather than a "port".

But maybe folks who use workflows that don't involve RAW photos have better luck.

View on HN

Or maybe you'll have better luck in a week when somebody familiar with RAW and a 20 year grudge against Adobe chooses to spend a day of tokens on the problem. Maybe me.

Rome wasn't built in a day, nor Adobe destroyed in a single git push. But they both shall fall.

That's exactly what I was thinking. It's only a matter of time. Surely the models, when well directed, can get most or all of the way there in short order.

Surely the models, when well directed, can get most or all of the way there in short order.

"Hey ChatGPT, what would the sufficiently smart compiler argument look like in the LLM era?"

I did this a few months ago and it's not simple: different sensors have different pixel arrangements, files can have different data structures, and the default tone mapping is provided by the app (so opening the same raw file in darktable vs preview will have different results). There are different algorithms for how you assemble the raw data as well, and the issue is that you can get something _passable_ that isn't _optimal_, and it's really hard for the LLM to recognize that something isn't right. Is it the pixel processing, or is it the tone mapping, or is that just how the image looked?

And on top of that, you need a bunch of different files from different sensors to test with. Canon, sony, apple, fuji, nikon, olympus, etc. -- if you're building a truly general application, that's a concern.

Or if you're like me and you shoot fuji, you just build a fuji raw parser and call it good. The "TAM of 1" world of software development...

Adobe employee here. We have access to LLMs and tokens as well.

And 500 levels of org tree, and grumpy customers that freak out if you change anything about their workflows, and decades of legacy code across dozens of micro-services, and backwards compatibility requirements with 20 year old formats...

You have:

1. LLMs

2. an executive team that hates your customers. this problem with company culture goes back at least 13 years: https://fstoppers.com/video/adobes-ceo-deftly-dodges-questio...

Unfortunately any benefit from #1 is neutralized by #2

How are LLMs and tokens going to help you retain customers who you've spent the past decade pissing off?

Those customers are already pissed off, yet record sales every quarter. This will be great to offer this diminished experience to them until they start using AI to do all of their editing.

You also have managers actively hostile towards your customers.

People are underestimating heavily what has happened here and to our industry in general.

I also built one of these photoshop clones. It has raw support. I use it for Fuji raw editing. I've been building it with Claude for 6 months now.

https://lopsy.art

How many painting applications have been built by LLMs I wonder?

I also let it build one btw: https://egeozcan.github.io/ketchup/ (not a PS clone, more amateur painting oriented)

Yeah, it's a really well defined problem space with quantifiable outcomes, so LLMs are very well suited to it.

For lopsy, the biggest issue I ran into was combinatorial bugs: certain sequences of tools and actions would cause a bug to occur that wasn't obvious from isolated tool testing. I solved it by having Claude generate complete projects, full documents with novel concepts chosen randomly, built in the browser with playwright. This continues to expose so much more than individual unit/tool tests, and I have an automated loop that addresses them. (And a bonus from that: I use the outputs to make tutorials to show what the tool can do).

I find it awfully funny that your response to someone creating the entire Adobe software suite in a day is “the colours aren’t rich enough for my liking”

Oh the times we live in.

>amateur attempt at RAW processing from first principles

That tracks.

So it's the Omarchy of Adobe-like software?

Raw was a tough one when I tried it a few months ago -- I never thought about how individual color pixels on the sensor come together to form a color value for a point in an image file. Super interesting, and not at all standard between the different manufacturers. It's a hard problem for software to solve in a general way.

Reply on news.ycombinator.com