To pass some time in a train yesterday, I've copy'n'pasted my recent GPU ISP into Millipixels' postprocessing code to see how it compares with what was already there. Before/after:

#mobilelinux #linuxmobile #librem5 #shotonlibrem5

Unlike Glowup, which takes about 30 seconds and lots of RAM to process, this is still just as fast - the photo is developed within 2 seconds from shooting.

#mobilelinux #linuxmobile #librem5 #shotonlibrem5

There are still some crucial things missing, such as profiled denoising or proper highlight recovery, but since the performance budget for a still photo is much higher than for a 30 FPS video, there's plenty of room to add more stuff - and most of these 2 seconds are spent reading DNG and saving JPG anyway.

#mobilelinux #linuxmobile #librem5 #shotonlibrem5

And the great thing is that you can take your past photos and re-develop them again with whatever code you have available now. No need to be picky, it's fast enough to just go through them all.

#mobilelinux #linuxmobile #librem5 #shotonlibrem5

FWIW, don't mind the stripes on the bottom or right edge on some of these photos. It was just me poorly rotating and noticing too late 😛

#mobilelinux #linuxmobile #librem5 #shotonlibrem5

Last one for today 😴

#mobilelinux #linuxmobile #librem5 #shotonlibrem5

@dos I tried to do something similar -- using good, external debayer, then attempting to use GPU pipeline. I attempted to use texture mode than 8200 pictures wide, and GPU did not like that. Rest can be seen in tui/ccam. Pass --cmd:convert, but clearly more work needs to be done there. If you have your code somewhere, I can try to play with it.

@pavel ??? Full 13MP is still well within GL texture limits. The code just works as-is.

@dos I wanted to do high-quality debayering, which turns 13Mpix into 52Mpix image if I want to pass it to existing shaders. Doing high quality debayer in the shaders would solve that. Really advanced debayer is probably too hard to do on GPU, but it should be possible to do better than current debayer-and-downscale.

@pavel That's not how it works. A 4-channel 13Mpix image remains a 13Mpix image and still fits within limits.

@dos Do you have code to share? :-). My version is a tui/ccam. I reformatted debayered RGB data back into RGGB bayer format to feed it into shaders easily, and hit the limit.

@pavel Just take a step back and think a bit about what you just wrote and you won't need any code 😜

@dos It is too late for a bit of thinking, I'm afraid. I wanted to experiment with "good" debayering, and I have code that is unsuitable for GPU. I thought putting it back into RGGB format would be easy way to pass it through the shaders. Well, it was not :-).

@pavel I'd rather give the shader RGB values than rebayer debayered data so it can debayer it again if I wanted "easy", but that's just me.

@dos Yeah, you are clearly more comfortable modifying shader code than me :-).

@pavel How comfortable does one need to be to replace a single line that calls a function called "debayer"? 🤔

@dos Well, deleting that line was simple. Replacing it seems to be more difficult. Plus img_attrs need to be modified to be RGB888, if I understand things correctly.

@dos These photos look great! 😮
Is this solution generalizable enough for different camera sensors? (e.g. other phones)

@fizzo Nothing sensor-specific there (except calibration data of course), just doing very basic stuff that you need to do in order to get a proper image from any Bayer sensor (unless it does parts of it for you already). See the description at https://source.puri.sm/-/snippets/1223 for details.

@fizzo (although many other devices have a dedicated piece of hardware to do this and more for you)

@dos Ok, so after a bit of fight, I got it to work. As usual, problem was elsewhere than I was looking: gl_init(), not shader.