That’s fine, I have seen it happen. I have also seen it in other cases, like simple webpages that could be done with HTML+CSS built on so many layers of toolkits that they took minutes to load.
But, for raw processing, I think that a client-server model would make a lot of sense and the separation would actually introduce useful discipline to the code, and lower the barrier for people with different skillsets to contribute as they would need to understand a smaller codebase.
I guess that might also open the door to using render farms or suddenly cheap AI processing facilities once that bubble bursts, overkill for stills but useful for video
Yes, I agree, my rant completely unrelated to your idea, only triggered by it.
Your idea is solid and being able to use only one computer in the home for powerful image processing is a good idea. I have a home lab and it would just be another service being hosted. It could even be a benefit for people who are on vacation or away from home, or those who don’t have the money for hardware and rent a server. The latency would not be a problem with a good connection. Worst case scenario a round trip of 200ms is not a lot worse than some darktable sliders on heavier modules 
Could also setup FOSS rendering swarms where processing is done from a pool of hardware connect to the swarm. Stable Diffusion has a few of these applications and would work perfectly here. The possibilities are endless of course.
This would also allow for different user interfaces which could harness the FOSS community better. People have different needs and also different programming specializations.
Great ideas. I will also think about this for a bit 
I think performance is key for a nice user experience, and at least on the same machine it should be no compromise. Having not too much experience with client-server architectures, I guess remaining on the GPU for display will be impossible with that architecture? (On a single machine of course)
However, the idea of having a more modern image processing library, separate from the UI, was the same I was having and asking about in this thread:
https://discuss.pixls.us/t/image-signal-processing-library
I think that would be really great to help development of more independent UIs based on different user needs.
Yeah, you would have to send the preview image constantly from the server to the client. Lots of optimizations that could be done like sending only the parts of the image that change, compressing the image on the gpu, and many more things people smarter than me can come up with.
On the same house with a fast network it’s probably not a problem, but it would introduce challenges when using certain UI elements like incremental sliders, curves, etc, if the user expects instant feedback.
If nvidia and other companies can implement game streaming with reasonable latency, image editing should be able to be implemented without issues.
GeForce Now claims to do 4K 240Hz 10-Bit HDR. With that sort of bandwidth, photo editing should be no issue. (But I’d trade off some of those FPS for a better-detail codec)
I doubt the rendering (and even transmission?) is done at full res and at this framerate.
ouch.
i just tried vkdt on a mi13u telephone. while of course the ui is unusable on a tiny device like this, processing the 12MP dng it produces (full res, unlike dt) takes 158ms in total (default pipeline, including hierarchical highlight reconstruction and local laplacian pyramids for local contrast). like 9ms highlights, 26ms demosaic, 74ms local laplacians and some crazy 20ms for waveform histogram collection. seems atomics aren’t the strength of this thing
so yes you can probably do better with remote rendering and fast network. not sure by how much and for what price.
also i really enjoy working on monitors with 160Hz or more, especially with wayland which actually makes use of this. it’s a different kind of experience dragging a slider. i suppose i’d always want a fully local codepath for situations where the local device is strong enough for local work.
Some lighter esports titles can definitely be rendered natively at even higher framerates, but for the rest they are definitely using DLSS.
There’s really no reason to not use DLSS nowadays and it just keeps getting better and better.
The improvements in the recent version are incredible , I think a few months from now RR will be on par with DT/LR’s recent versions. I do wish it had lens profiles , perspective and distortion correction.
Hi @hanatos , you’ve mentioned a couple of times about running vkdt on a phone. Is this on Android? Is there a guide yo install it?
Also useful if someone wanted to make a mobile app frontend for example…
Are people here basically proposing putting RapidRAWs UI on top of vkdt? How feasible of an idea would that be? Haven’t been keeping up with the discussion (and it seems to be going sort of off topic?)
…or maybe a single Solaris server running 13 (count 'em, 13) different JVMs just to support all the specific Java version requirements of its “universal, write once / debug everywhere” software.
But I digress… 
“Java runs 6 quintillion machines…”
Not realistically. There is easy stuff that may initially give the illusion of fast progress, but things get harder down the line. @hanatos has been working on vkdt for 6 (?) years now, he is very active (4500+ commits) and (whithout offense) probably a lot more knowledgeable with coding RAW development software. Still vkdt (though a really fascinating program) is nowhere near Darktable or Lightroom.
I played around with vkdt in the last few days. I like it a lot, especially because it has the spectral film simulations and the performance is just out of this world.
However my impression is that the software is rather meant as a tech demo that shows what is possible and also a playground to implement algorithms. The architecture is super clean, which is very attractive from a programmer’s point of view. But the UI is extremely minimal, this is why I don’t see it becoming a widely used software.
Since the code is so clean and the license is permissive, it is surely possible to re-use code for other software. I personally would love to see a project that focusses on the UI side, is written in rust (many coders like rust these days), uses algorithms from vkdt and stays close in the long-term, so both programs can continue sharing newly developed code in the future.
But as discussed above, the initial choice of the framework may be a hindrance for RR. It is possible that a lot of the existing code has to be replaced for this to work. But RR is only a few weeks old, better change direction now than later.
What is vkdt?
I believe the idea was for others to build a “proper” UI on top of the engine. @hanatos ?
In darktable we hear endlessly about the UI/UX, but the code for the UI and the underlying processing is fairly tangled, which makes it hard to change things. vkdt keeps them completely separate, so that the UI/UX whizzes can do what they please, and they underlying pixelpipe is not affected.
It would be nice if a few of the underlying modules from darktable were ported over (CB RGB, Tone Equalizer, AgX) as it’d be interesting to have them in a nodal interface.
I think the UI is nice, although I would probably shrink it down slightly as it feels like it was made for tablets rather than desktop. Maybe I have a setting wrong? He needs a better Rotate & Perspective module something that mirrors Darktable or Lightroom where I can draw the lens and the image with correct the perspective , keystoning etc. Lens Correction which he can use Lensfun which is seemingly used by every raw editor except dxo and Lightroom. I can’t really use RR till I can correct the distortion and straighten the photos out as I use ultra-wide angle lens.
Isn’t the CB RGB under the Color tab?
I would also like to see a panorama and HDR tool included, which LR has had since version 6. I do use hugin and xpano but it would be nice to have them under one program.