Posts
2157
Following
96
Followers
198
Riding horses, hacking computers, phones and smartwatch.
@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.
0
0
0
@dos Yeah, you are clearly more comfortable modifying shader code than me :-).
1
0
0
@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 :-).
1
0
0
@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.
1
0
0
@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.
1
0
0
@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.
1
0
0
Clicks machine (tui/ccam) can now do phase-detection auto focus. Unfortunately, for good focus, you need to integrate phase-detection and contrast-detection. Plus, you need patched kernel. Fun :-).
0
0
2
OSSEU: koho uvidim v Amsterdamu a koho potkam v letadle? :-).

OSSEU: who will be there?
0
0
0
@arnd I'll be at osseu. I'll try to make it to your talk :-).
0
0
1
@dos @martijnbraam @linmob Martijn, if you agree with the analysis, would it be worth it to somehow "retract" that blog post / publish updated one?
1
0
0
@dos @martijnbraam @linmob Yes, agreed, effect may be from differences between the pixels. If it was bigger, it may be worth it to try to work with it, but it is likely too small to exploit.
0
0
0
@dos @martijnbraam @linmob Aha, thanks for this. Agreed, there's nonlinearity at the top, but we should not need to correct for it as it is really small.
1
0
0
@dos @martijnbraam @linmob Can you get, dunno, 20% too bright source in R, G and B? I believe you'll be able to distinguish between 100% and 120% in the averages. And that's the nonlinearity... Aha, I see the new post :-).
0
0
0
@dos @martijnbraam @linmob So... you are right only center pixels should be considered. And it surely looks like it is linear from 0 to 95% or so. I assume there would be similar effect at the 5% near saturation on red and blue ... and that surely is non-linearity, but may not be important enough to be worth correcting.
1
0
0
@dos @martijnbraam @linmob Do you have some data to back up that linearity claim? I believe there's consensus that it will not be linear near saturation. OTOH I don't believe there's consensus of how important that effect is :-(. https://www.mdpi.com/1424-8220/24/6/1841
1
0
0
@linmob @martijnbraam Yep, sensor calibration can be a lot of fun, too. There's enough work to be done all over the place. (And first step -- linearize data from sensor -- is something I'll need to investigate for Clicks Machine).
1
0
0
@linmob @martijnbraam (And yes, you could / should modify Clicks Machine so that it can do debayer + ISP on files on demand.) (And yes, eventually this should be all integrated into libcamera).
1
0
1
Show older