@dcz @libcamera While I certainly welcome new projects and efforts in the camera space, I would appreciate if references to @libcamera gets removed from this and other posts as the two projects are not related.

@awai @thomzane @rmader @linmob had no idea about that name clash! Wasn't "gnome-camera" acceptable as name ? I presume I should ask jwestman..

@linmob @thomzane I think there's some confusion here, "camera" from either Robert's https://gitlab.gnome.org/rmader/camera forkend from https://gitlab.gnome.org/jwestman/camera is a GTK application written in Vala, while Adam Pigg's pinehole is a Qt camera application developed for sailfish at https://github.com/piggz/harbour-pinhole/

Looking at this https://packages.debian.org/bullseye/pinhole seems debian packagers have mixed the two ?

@awai @rmader

@marcan @ljs @sailus and don't get me wrong, I recognize that no "abusive masochist" person would recognize himself as such :)

@marcan @ljs I feel a bit called out (maybe I'm wrong) as I've been saying that "I learned to enjoy the struggle" and that I tend to enforce nitpicking comments (the "reverse xmas tree nonsense") particularly on newcomers these days.

Let me clarify again that I don't consider myself any sort of abusive masochist (is this even a thing in English?) which likes to put people through the pains he suffered, but the two things are strictly related to the end quality of the code that it is merged and how.

- clunky process make sure you check every part and make sure you know and think about what you're sending out and to who (and I still make a mistakes, so I know it's not all good). That said, I concur that a git push -f over the whole "format, edit cover letter, add receivers in" etc is simpler, even more for simple fixups. I don't see this happening easily though. In the subsystem I work the most there are at least 4 sub-maintainers maintaining their own trees and to get to a point where you can git push to a single tree it will take time to re-organize the whole subsystem workflow (not saying it's not possible, what I'm saying is that it's not a purely technical problem).

- nitpicking, even on style details, is for the sole sake of consistency of the code base. Some reviewers are annoying, some other try to phrase it in a way that sounds like a kinds suggestion, and I'm aware of the usual caveat of per-subsystem unwritten rules and personal preferences, which should be better handled I agree. You're free to use a styler if you like, nobody requires you to do so by hand so I don't get all this emphasis on "I'm gonna use clang-format for my subsystem", you're welcome to do so and everyone has her own formatting tools in place already (in the editor, in commit-hooks whatever). As others like @sailus pointed out, once you let a driver diverge (style wise) you will soon get other submitters copying whatever is there and confront review comments with "I copied it from xyz, why is fine for others but not me?". Most comments here do not seem to consider this a problem at all and I suspect there's an underestimation of how bad things could go when thousands (ok, maybe hundreds if you consider a big sub-system like media) of people messes with the same code base.

Again, thanks for bringing this up, but please stop the "us" versus "them" thing though.

@marcan @Conan_Kudo @jacksonchen666 @monsieuricon I'm not sure I know how to quote your post, by trying by points:

- the nitpicking non-sense: I completely disagree here :) code is maintainable if its consistent, and code is consistent if rules are enforced, including reverse xmas-tree nonsenses :) (I got grumpy the first time I've been told to change a patch to adhere to that rule. Now I (kindly) ask people to comply with that especially newcomers). This doesn't mean that a well styled but bad engineered piece of code is acceptable of course. But form is substance when roughly a few thousand people are messing with the same code repository at the same time.

- the argument that "perfection is the enemy of good" stands, I see your point and I've recently dealt with a community that would have a lot of code to upstream but simply don't want to go through that struggle as they don't see the effort justified. This isn't good for anyone, but I feel the culprit is maybe in the downstream development process. Upstreaming should be planned early, budgeted (in time and funds) accordingly, and should be clear that you're putting yourself forward for future maintainership and you are willing to help the community with reviews of other people's code. If those conditions are not met, for whatever reason, it's better to have that code downstream otherwise someone will have to maintain it on your behalf. Might sound harsh, but maybe lowering the bar would make it easier to "merge and forget" and put additional burden on the community without giving anything back ?

By the way, these are all questions I'm asking myself as well, I got very sad by the recent push-backs I've received when I suggested to upstream that code I mentioned and the message I got back was along the lines of "hell no, I'm not going to spend time moving comment lines around to satisfy your OCD, as my code works already" (surprise surprise, it works for that single use case but not for others, if they would have upstreamed they would have known :)

Thanks for the discussion though

@marcan @Conan_Kudo @jacksonchen666 @monsieuricon let me add two points to your list:

- Tens of years of scripting/automation developers and maintainers have hand-grown to accommodate their workflows and from which it is hard to detach from.

And then if you want my perspective, as someone who approached kernel development with a background in webUI systems: sending patches by email is a tedious process, which requires you're in control of each single step. I've learned that doing things "slowly" is the only way one can keep up with the complexity of kernel development. I hate manually adding receivers to a formatted patch ready to be sent out, but that forces me to think about exactly who should receive the patch. I hate getting to v10 and gong through format/resend but that forces me to rebase and re-check every patch I send out. So yes, I guess the clunky process serves also to make sure you do check every little detail of the process, to make sure things are as "perfect" as possible.

So yes, I guess i definitely fall into your 3) point above. I've learned to love the struggle as it contributes to the overall quality of the end result.

@RLetot @markgrieveson @libcamera @fosdem @PINE64 this is separate development from megapixels, which doesn't use libcamera.

@Conan_Kudo @jacksonchen666 @vincent @marcan I'm not convinced this is accurate. It's easy to blame tooling, which is the most visible part of the process. However, I'm pretty sure if we replace this with the most amazing workflow of submitting and reviewing the code, we'll still be 90% in the same situation, because:

1. Writing kernel code is hard
2. Reviewing kernel code is even harder
3. Upstreaming to rapidly-moving mainline is the hardest

We need maintainers, preferably well-paid teams of maintainers, much more than we need a shiny code review toolset.

@Conan_Kudo @jacksonchen666 @marcan while I could agree that the process is perfectible (and thanks to lei, b4 and lore @monsieuricon is getting better every month) putting forward the argument that "patch review by email sucks" doesn't help your cause, as it's a purely personal preference. I consider web-UI review a toy unsuitable for getting any serious work done, but I realize that I cannot use such argument to push back against any proposal to change to the status-quo as it mostly relates to my preferences/workflow/toolset/mindset.

So please, I'm honestly interested in reading where the discussion goes, but don't use such argument as it's purely a personal preference.

@PINE64 @fosdem @libcamera for the image-tuning nerds, be aware that the #PinephonePro back camera is the PDAF capable version of the Sony IMX258 sensor.

PDAF provides an estimate of the image contrast and sharpness (which an algorithm needs to maximize by getting the focus distance right) through some "special" pixels and it's way more efficient than purely software-based algorithms where the scene contrast is estimated using the ISP provided statistics. It's way more efficient and performant, but needs dedicated hw support (which the ppp has).

The @Raspberry_Pi backend in @libcamera is, as usual, one step forward and provides a PDAF based algorithm for their newest v3 camera module which can be used as a base for extending the support to other platforms and sensors. It's not a negligible effort but the code is there and just need someone to work on that.

@insl @libcamera @fosdem @PINE64 shaky hands don't help and for sure it's perfectible, but it indeed focuses (more visible after the first 10 seconds of video).

Of course it perfectible, but it's a starting point at least :)

I was honestly surprised myself, as I was told contrast based continuous auto-focus was a no-go, while it can achieve decent results.

I'm about to replace my beloved laptop and I'm considering "Linux-native" producers instead of the usual Lenovo/Dell/BigBrand. The usual suspects (I know of) for someone living in Europe are Tuxedo computers, Star Lab System and .... ?

Requirements: a lot of CPU (45W TDP) preferably no dGPU, 15 or 16 inches and extended warranty and "next day" repair (which is never the next day, but you know..)

Any opinion to share ?

@rmader @libcamera @fosdem @PINE64 uh that's interesting! does this goes through pipewire/gst as well ?

@markgrieveson @libcamera @fosdem @PINE64 oh this is just 'cam' (one of the libcamera test applications) with SDL output. It's just for testing, shouldn't be considered a real camera application.

However, at fosdem we have (well, Kieran has, actually) just presented how is it possible to run any camera application that goes through pipewire/gstreamer with libcamera on the pro and mentions a few other libcamera-based camera application such as pinhole.

https://fosdem.org/2023/schedule/event/linux_camera_apps/

@PINE64 @fosdem @libcamera credits to Daniel Semkowicz from Theobroma Systems as original patches author https://patchwork.libcamera.org/project/libcamera/list/?submitter=126

@libcamera has recently received an implementation proposal of an auto-focus algorithm for Rockchip RK3399. A great occasion to continue the work done at @fosdem to support the @PINE64 PinephonePro cameras.

Here it is a quick test of the auto-focus algorithm running in "continuous auto-focus mode" on the PinephonePro IMX258 rear camera.

Let's try to merge it soon upstream!

PS:
Sorry for my shaky hands during the first 10 seconds, let's say I was trying to make things harder for the algorithm