| Message ID | 20261029152058.896209-1-halfline@gmail.com |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
On Thu, Oct 29, 2026 at 11:20:47AM -0400, Ray Strode wrote: > Hi, > > This series makes GPU statistics follow the sensor region visible in the > output, keeping exposure and white balance metering aligned with the image. > The simple pipeline also reports the configured CPU or GPU crop through > ScalerCropMaximum and ScalerCrop request metadata. > > It includes the optional-result getSelection() API from the earlier > discussion: success with an empty optional means no rectangle was reported > for the current configuration. The crop metadata uses physical pixel-array > coordinates, with the control and property documentation corrected to match. > > The first patch is Martin's GPU crop-centering fix [1], included unchanged. > > [1] https://patchwork.libcamera.org/patch/28178/ > > --Ray Can I ask you to please stop post LLM-generated patches ? I know the policy document is overdue, but this will just not be allowed, period. > Martin Neiva de Carvalho (1): > libcamera: software_isp: Centre the crop the GPU debayer applies > > Ray Strode (10): > libcamera: Document ScalerCrop in physical pixel-array coordinates > libcamera: v4l2_subdevice: Return optional selection rectangles > software-isp: Align statistics with the visible sensor crop > tests: Validate the visible sensor crop > software-isp: Expose the configured image crop > tests: Check the configured CPU image crop > software-isp: Map input crops to native sensor coordinates > tests: Validate native sensor crop coordinates > pipeline: simple: Report the software ISP's maximum crop > pipeline: simple: Include the software ISP crop in request metadata > > > .../internal/software_isp/debayer_geometry.h | 48 ++++++++++ > .../libcamera/internal/software_isp/meson.build | 1 + > .../libcamera/internal/software_isp/software_isp.h | 1 + > include/libcamera/internal/v4l2_subdevice.h | 5 +- > src/libcamera/control_ids_core.yaml | 7 +- > src/libcamera/pipeline/simple/simple.cpp | 95 +++++++++++++++++- > src/libcamera/property_ids_core.yaml | 4 +- > src/libcamera/sensor/camera_sensor_legacy.cpp | 42 +++++--- > src/libcamera/sensor/camera_sensor_raw.cpp | 31 +++--- > src/libcamera/software_isp/debayer.cpp | 11 +++ > src/libcamera/software_isp/debayer.h | 1 + > src/libcamera/software_isp/debayer_cpu.h | 4 + > src/libcamera/software_isp/debayer_egl.cpp | 38 +++++--- > src/libcamera/software_isp/debayer_egl.h | 3 +- > src/libcamera/software_isp/software_isp.cpp | 14 +++ > src/libcamera/v4l2_subdevice.cpp | 40 +++++--- > test/debayer-geometry.cpp | 106 +++++++++++++++++++++ > test/meson.build | 2 + > test/software_isp/debayer-crop.cpp | 102 ++++++++++++++++++++ > test/software_isp/meson.build | 20 ++++ > 20 files changed, 516 insertions(+), 59 deletions(-)
Hi, On Thu, Oct 29, 2026 at 11:36 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Can I ask you to please stop post LLM-generated patches ? I know the > policy document is overdue, but this will just not be allowed, period. So I must say I find your energy incredibly demotivating. These patches are *good*, solve real problems with exposure and white balance, address requests made specifically by Kieran, implement features from his wish list he asked me to work on (ScalerCrop metadata reporting) and they took me time and effort to produce and test. I’m happy to explain the changes, discuss technical objections, and fix problems identified in review. I am not happy to defend which development tools I use. I am not submitting slop here. You, of course, can accept or refuse whatever you want, but refusing geometry fixes in metering code, that prevent the camera from looking washed out, or refusing clear off-by-one's in the gpu bayer sampling code that result in purple lines in the output helps no one. It's just code. --Ray
On Thu, Oct 29, 2026 at 12:51:58PM -0400, Ray Strode wrote: > On Thu, Oct 29, 2026 at 11:36 AM Laurent Pinchart wrote: > > Can I ask you to please stop post LLM-generated patches ? I know the > > policy document is overdue, but this will just not be allowed, period. > > So I must say I find your energy incredibly demotivating. These patches are *good*, solve real > problems with exposure and white balance, address requests made specifically by Kieran, > implement features from his wish list he asked me to work on (ScalerCrop metadata reporting) > and they took me time and effort to produce and test. > > I’m happy to explain the changes, discuss technical objections, and fix problems identified in review. > > I am not happy to defend which development tools I use. I am not submitting slop here. > > You, of course, can accept or refuse whatever you want, but refusing geometry fixes in metering code, > that prevent the camera from looking washed out, or refusing clear off-by-one's in the gpu bayer > sampling code that result in purple lines in the output helps no one. > It's just code. We can agree to disagree, I'm fine with that. I still ask you to please stop posting LLM-generated patches to the libcamera project. Those contributions are not welcome.
Hi, This series makes GPU statistics follow the sensor region visible in the output, keeping exposure and white balance metering aligned with the image. The simple pipeline also reports the configured CPU or GPU crop through ScalerCropMaximum and ScalerCrop request metadata. It includes the optional-result getSelection() API from the earlier discussion: success with an empty optional means no rectangle was reported for the current configuration. The crop metadata uses physical pixel-array coordinates, with the control and property documentation corrected to match. The first patch is Martin's GPU crop-centering fix [1], included unchanged. [1] https://patchwork.libcamera.org/patch/28178/ --Ray Martin Neiva de Carvalho (1): libcamera: software_isp: Centre the crop the GPU debayer applies Ray Strode (10): libcamera: Document ScalerCrop in physical pixel-array coordinates libcamera: v4l2_subdevice: Return optional selection rectangles software-isp: Align statistics with the visible sensor crop tests: Validate the visible sensor crop software-isp: Expose the configured image crop tests: Check the configured CPU image crop software-isp: Map input crops to native sensor coordinates tests: Validate native sensor crop coordinates pipeline: simple: Report the software ISP's maximum crop pipeline: simple: Include the software ISP crop in request metadata .../internal/software_isp/debayer_geometry.h | 48 ++++++++++ .../libcamera/internal/software_isp/meson.build | 1 + .../libcamera/internal/software_isp/software_isp.h | 1 + include/libcamera/internal/v4l2_subdevice.h | 5 +- src/libcamera/control_ids_core.yaml | 7 +- src/libcamera/pipeline/simple/simple.cpp | 95 +++++++++++++++++- src/libcamera/property_ids_core.yaml | 4 +- src/libcamera/sensor/camera_sensor_legacy.cpp | 42 +++++--- src/libcamera/sensor/camera_sensor_raw.cpp | 31 +++--- src/libcamera/software_isp/debayer.cpp | 11 +++ src/libcamera/software_isp/debayer.h | 1 + src/libcamera/software_isp/debayer_cpu.h | 4 + src/libcamera/software_isp/debayer_egl.cpp | 38 +++++--- src/libcamera/software_isp/debayer_egl.h | 3 +- src/libcamera/software_isp/software_isp.cpp | 14 +++ src/libcamera/v4l2_subdevice.cpp | 40 +++++--- test/debayer-geometry.cpp | 106 +++++++++++++++++++++ test/meson.build | 2 + test/software_isp/debayer-crop.cpp | 102 ++++++++++++++++++++ test/software_isp/meson.build | 20 ++++ 20 files changed, 516 insertions(+), 59 deletions(-)