[{"id":38653,"web_url":"https://patchwork.libcamera.org/comment/38653/","msgid":"<2c2ec86b-def0-4782-9c22-cb329fcc2f3b@nxsw.ie>","date":"2026-04-25T01:25:29","subject":"Re: [RFC PATCH v3 4/7] ipa: simple: Add LSC algorithm","submitter":{"id":226,"url":"https://patchwork.libcamera.org/api/people/226/","name":"Bryan O'Donoghue","email":"bod.linux@nxsw.ie"},"content":"On 24/04/2026 21:02, Milan Zamazal wrote:\n> +\t/*\n> +\t * The constructed table is compressed by converting from floats to bytes.\n> +\t * This makes the texture uploaded to a GPU smaller and we don't have to\n> +\t * deal with textures containing float values.\n> +\t * The byte range 0..255 represents floating point values 1.0..4.0. Values\n> +\t * outside this range are clamped. When accessed in the shader, the byte\n> +\t * range is represented by 0.0..1.0 range. Then the resulting pixel value\n> +\t * can be computed as\n> +\t * rgb + rgb * 3.0 * LUT_VALUE\n> +\t */\n\nThis is ~ certainly something we can skip with a compute shader.\n\nI'll bring a laptop on holidays and will get an RFC mutlipass pipeline done.\n\nI almost feel its worthwhile doing the work to fit this into a compute \nshader since we calculate float to byte and then do another conversion \nin the shader - when if we just fed in floats...\n\nBeing more pragmatic. This code works now - but it is certainly the most \nobvious use-case for ...\n\nActually why can't we just pass floats to the shader .. ?\n\nglTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, width, height, 0, GL_RGBA, \nGL_FLOAT, data);\n\nand then\n\nrgb = rgb * texture2D(lsc_tex, textureOut).rgb;\n\nWe would cut out a lot of jump through hoops that way. Yeah we don't \nreally need a compute shader to upload a float.\n\nYeah ... really thinking about this - I think the conversion to bytes is \nunnecessary.\n\nJust calculate everything in float and upload it to the GPU - our worst \ncase is passing GL_RGBA16F and loosing some precision, probably \npreferable unless the maximum value of the float exceeds 65.5k which it \nprobably ? doesn't\n\n16f is plenty of precision for a gain LUT and halves the texture \nmemory/bandwidth required.\n\nI'd try :\n\nglTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA16F, width, height, 0, GL_RGBA, \nGL_FLOAT, data);\n\nrgb = rgb * texture2D(lsc_tex, textureOut).rgb;\n\nAnd dropping of that conversion to bytes - seems like just overhead to me.\n\nCheck \"GL_OES_texture_half_float_linear\" in the GL_EXTENSIONS - we \nalready interrogate these and just don't do LSC if float/half-float is \nmissing.\n\nBTW the internet machine tells me these two extensions became part of \nGLES 3.0 in 2012 and were optional before that so we are \"pretty safe\" \nin conjoining LSC to \"GL_OES_texture_half_float_linear\" IMO and \ngracefully refusing to run LSC without it.\n\n---\nbod","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id DFC51BDCB5\n\tfor ;\n\tSat, 25 Apr 2026 01:25:37 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id C392162FAE;\n\tSat, 25 Apr 2026 03:25:36 +0200 (CEST)","from sea.source.kernel.org (sea.source.kernel.org\n\t[IPv6:2600:3c0a:e001:78e:0:1991:8:25])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id DEA4962010\n\tfor ;\n\tSat, 25 Apr 2026 03:25:34 +0200 (CEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby sea.source.kernel.org (Postfix) with ESMTP id D798D40160;\n\tSat, 25 Apr 2026 01:25:32 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 80873C19425;\n\tSat, 25 Apr 2026 01:25:31 +0000 (UTC)"],"Message-ID":"<2c2ec86b-def0-4782-9c22-cb329fcc2f3b@nxsw.ie>","Date":"Sat, 25 Apr 2026 02:25:29 +0100","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [RFC PATCH v3 4/7] ipa: simple: Add LSC algorithm","To":"Milan Zamazal , libcamera-devel@lists.libcamera.org","Cc":"Xander Pronk ,\n\tHans de Goede ,\n\tRick ten Wolde ","References":"<20260424200255.356798-1-mzamazal@redhat.com>\n\t\n\t<20260424200255.356798-5-mzamazal@redhat.com>","From":"Bryan O'Donoghue ","Content-Language":"en-US","In-Reply-To":"<20260424200255.356798-5-mzamazal@redhat.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":38713,"web_url":"https://patchwork.libcamera.org/comment/38713/","msgid":"<85ik935tc9.fsf@mzamazal-thinkpadp1gen7.tpbc.csb>","date":"2026-05-04T11:04:22","subject":"Re: [RFC PATCH v3 4/7] ipa: simple: Add LSC algorithm","submitter":{"id":177,"url":"https://patchwork.libcamera.org/api/people/177/","name":"Milan Zamazal","email":"mzamazal@redhat.com"},"content":"Hi Bryan,\n\nBryan O'Donoghue writes:\n\n> On 24/04/2026 21:02, Milan Zamazal wrote:\n>> +\t/*\n>> +\t * The constructed table is compressed by converting from floats to bytes.\n>> +\t * This makes the texture uploaded to a GPU smaller and we don't have to\n>> +\t * deal with textures containing float values.\n>> +\t * The byte range 0..255 represents floating point values 1.0..4.0. Values\n>> +\t * outside this range are clamped. When accessed in the shader, the byte\n>> +\t * range is represented by 0.0..1.0 range. Then the resulting pixel value\n>> +\t * can be computed as\n>> +\t * rgb + rgb * 3.0 * LUT_VALUE\n>> +\t */\n>\n> This is ~ certainly something we can skip with a compute shader.\n>\n> I'll bring a laptop on holidays and will get an RFC mutlipass pipeline done.\n>\n> I almost feel its worthwhile doing the work to fit this into a compute shader since we calculate float to\n> byte and then do another conversion in the shader - when if we just fed in floats...\n>\n> Being more pragmatic. This code works now - but it is certainly the most obvious use-case for ...\n>\n> Actually why can't we just pass floats to the shader .. ?\n>\n> glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, width, height, 0, GL_RGBA, GL_FLOAT, data);\n>\n> and then\n>\n> rgb = rgb * texture2D(lsc_tex, textureOut).rgb;\n>\n> We would cut out a lot of jump through hoops that way. Yeah we don't really need a compute shader to\n> upload a float.\n>\n> Yeah ... really thinking about this - I think the conversion to bytes is unnecessary.\n>\n> Just calculate everything in float and upload it to the GPU - our worst case is passing GL_RGBA16F and\n> loosing some precision, probably preferable unless the maximum value of the float exceeds 65.5k which it\n> probably ? doesn't\n>\n> 16f is plenty of precision for a gain LUT and halves the texture memory/bandwidth required.\n>\n> I'd try :\n>\n> glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA16F, width, height, 0, GL_RGBA, GL_FLOAT, data);\n\nAh, that's it, thank you for the tip. My previous float attempts\nresulted in a black screen, using 16 bits does the trick. With your\nsuggestion (and s/RGBA/RGB/), it works and is ~3 % faster in my\nenvironment than the compressed bytes version. So I'll switch to floats\nin v4.\n\n> rgb = rgb * texture2D(lsc_tex, textureOut).rgb;\n>\n> And dropping of that conversion to bytes - seems like just overhead to me.\n>\n> Check \"GL_OES_texture_half_float_linear\" in the GL_EXTENSIONS - we already interrogate these and just\n> don't do LSC if float/half-float is missing.\n>\n> BTW the internet machine tells me these two extensions became part of GLES 3.0 in 2012 and were optional\n> before that so we are \"pretty safe\" in conjoining LSC to \"GL_OES_texture_half_float_linear\" IMO and\n> gracefully refusing to run LSC without it.\n>\n> ---\n> bod","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 37BA9BE173\n\tfor ;\n\tMon, 4 May 2026 11:04:31 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 3BB4562FE8;\n\tMon, 4 May 2026 13:04:30 +0200 (CEST)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.129.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id EF60962FE1\n\tfor ;\n\tMon, 4 May 2026 13:04:27 +0200 (CEST)","from mail-wm1-f70.google.com (mail-wm1-f70.google.com\n\t[209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS\n\t(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n\tus-mta-437--uOZd0TbPOita0u8Vo-QhA-1; Mon, 04 May 2026 07:04:25 -0400","by mail-wm1-f70.google.com with SMTP id\n\t5b1f17b1804b1-486fa07f2bbso30261425e9.2\n\tfor ;\n\tMon, 04 May 2026 04:04:25 -0700 (PDT)","from mzamazal-thinkpadp1gen7.tpbc.csb\n\t(ip-77-48-47-4.net.vodafone.cz. [77.48.47.4])\n\tby smtp.gmail.com with ESMTPSA id\n\t5b1f17b1804b1-48a8ebb2f32sm266629825e9.13.2026.05.04.04.04.22\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tMon, 04 May 2026 04:04:23 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"VukROwS4\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1777892666;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=6LzN4sS+L43UQgFKk+YCGJMUpXT7omr/GwRnMp8JKYE=;\n\tb=VukROwS4RykYYieKglPpSfL5GshNDEPBktcg0sJIlhmdRvuTlbcCAefPO9D7XEYMySHlxg\n\tki1l+DRe27UPxvVP2wN8ZyrPF0G8dpGtVZoGP+D5KPnWBJcjT8wGd3ZvotuKoaa5v7VxhJ\n\tiljpPgUEO2Cu5wjzlIALYdrbCbwjRtI=","X-MC-Unique":"-uOZd0TbPOita0u8Vo-QhA-1","X-Mimecast-MFC-AGG-ID":"-uOZd0TbPOita0u8Vo-QhA_1777892664","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20251104; t=1777892664; x=1778497464;\n\th=mime-version:user-agent:message-id:date:references:in-reply-to\n\t:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject\n\t:date:message-id:reply-to;\n\tbh=6LzN4sS+L43UQgFKk+YCGJMUpXT7omr/GwRnMp8JKYE=;\n\tb=qOXXPbNhYCxssXNXUGyn02/x4oq1g9R/7Qn3vcs7CfaAbELgn86hsC5x+/b+po9j/R\n\tupbmc0iaXqDapsfz/rOMbv15ixc5K/DiQmGplHb3UKH6jtEDQak6BNmDJWY6fw3b9E2o\n\tjimmVPByXzq/6mgy3UQtNocy2zp1MitYKBPKt6jfurR73r6yFddxU/BXV32iYx4ALewf\n\tt4k21EtRfZmMxtcLfhKJBcRdpMQm0eXRkAqXd0SnEGi6um7YnbQpUySHE2swUqIAE+mR\n\tMcLoml6RbF2cYQbDpEPlpRo+NOxLResIG8tGz4+lcxyXkGkSt5SMFxzkhtzJRhZQSFwS\n\tmTkA==","X-Gm-Message-State":"AOJu0Yz9a8bMK52Ri1Govjc3E7UzvSKj6HYoQ4bD180uEv+Jw26eD9nl\n\tI+bYYsK7XXnMPkmuBSE7d2yVBPWEhDqXzP5RraIZZFe06alyIhPniX4dSMMTLFBbkTQOyba03qq\n\tZIMU+C24z9ky0zkA3heWZNT26tlD1wpIFBIQggdfoTiSL8qyKFk0OSZxsRal8rfPgvhy0mkpB9P\n\tM=","X-Gm-Gg":"AeBDieu2LheblC5xR7y0S3dE2hBTYSGaFQIAuXO0WnwiXlMqeAlhaZdOswc1e9fWmZC\n\toSCng5CV63OzkzeDQpXon1Q4SKnXkJGyrX+vMewHGylOhFJIjVPCz5JeYPYiAa3u1DqqHjn1xGU\n\t0WPYtOTjdLik07Zj0VFKrliXUD3R/5r9XS+2r3WHrnFdGJsrtza1CyC7gCvvO4FsmIIMo82ewi/\n\ttqJsGVL3nqiIna6zlXSQMwDhbW8Ii20wEzUObIs0iRhFrzM2lbmwHBwiFrqT1ykkQeDECf15dKq\n\terETNyhTEXpmPn3DO+X8J+PQnsnkrYuBFa6xwGzLHpYaoGcT0ODWbwsPzXaqKisf+tJ2brOKymb\n\t8XqR0uCZneqkczG5EEAE6pNqe3Dvcx0R72oR/fOm3yd1soXGAmffp4oxNiNVdaZthmuS42yubOb\n\tWJXEhiQ14txg==","X-Received":["by 2002:a05:600c:859a:b0:48a:7f90:2231 with SMTP id\n\t5b1f17b1804b1-48a9865f859mr105149125e9.19.1777892664265; \n\tMon, 04 May 2026 04:04:24 -0700 (PDT)","by 2002:a05:600c:859a:b0:48a:7f90:2231 with SMTP id\n\t5b1f17b1804b1-48a9865f859mr105148685e9.19.1777892663841; \n\tMon, 04 May 2026 04:04:23 -0700 (PDT)"],"From":"Milan Zamazal ","To":"Bryan O'Donoghue ","Cc":"libcamera-devel@lists.libcamera.org, Xander Pronk\n\t, Hans de Goede\n\t, Rick ten Wolde\n\t","Subject":"Re: [RFC PATCH v3 4/7] ipa: simple: Add LSC algorithm","In-Reply-To":"<2c2ec86b-def0-4782-9c22-cb329fcc2f3b@nxsw.ie> (Bryan\n\tO'Donoghue's message of \"Sat, 25 Apr 2026 02:25:29 +0100\")","References":"<20260424200255.356798-1-mzamazal@redhat.com>\n\t\n\t<20260424200255.356798-5-mzamazal@redhat.com>\n\t<2c2ec86b-def0-4782-9c22-cb329fcc2f3b@nxsw.ie>","Date":"Mon, 04 May 2026 13:04:22 +0200","Message-ID":"<85ik935tc9.fsf@mzamazal-thinkpadp1gen7.tpbc.csb>","User-Agent":"Gnus/5.13 (Gnus v5.13)","MIME-Version":"1.0","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"iMlJh2MaviBpoqwFyMgKlEdiZisf41GCQVczV3HBT_Q_1777892664","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":38720,"web_url":"https://patchwork.libcamera.org/comment/38720/","msgid":"<851pfr58rr.fsf@mzamazal-thinkpadp1gen7.tpbc.csb>","date":"2026-05-04T18:28:40","subject":"Re: [RFC PATCH v3 4/7] ipa: simple: Add LSC algorithm","submitter":{"id":177,"url":"https://patchwork.libcamera.org/api/people/177/","name":"Milan Zamazal","email":"mzamazal@redhat.com"},"content":"Milan Zamazal writes:\n\n> Hi Bryan,\n>\n> Bryan O'Donoghue writes:\n>\n>> On 24/04/2026 21:02, Milan Zamazal wrote:\n>>> +\t/*\n>>> +\t * The constructed table is compressed by converting from floats to bytes.\n>>> +\t * This makes the texture uploaded to a GPU smaller and we don't have to\n>>> +\t * deal with textures containing float values.\n>>> +\t * The byte range 0..255 represents floating point values 1.0..4.0. Values\n>>> +\t * outside this range are clamped. When accessed in the shader, the byte\n>>> +\t * range is represented by 0.0..1.0 range. Then the resulting pixel value\n>>> +\t * can be computed as\n>>> +\t * rgb + rgb * 3.0 * LUT_VALUE\n>>> +\t */\n>>\n>> This is ~ certainly something we can skip with a compute shader.\n>>\n>> I'll bring a laptop on holidays and will get an RFC mutlipass pipeline done.\n>>\n>> I almost feel its worthwhile doing the work to fit this into a compute shader since we calculate float to\n>> byte and then do another conversion in the shader - when if we just fed in floats...\n>>\n>> Being more pragmatic. This code works now - but it is certainly the most obvious use-case for ...\n>>\n>> Actually why can't we just pass floats to the shader .. ?\n>>\n>> glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, width, height, 0, GL_RGBA, GL_FLOAT, data);\n>>\n>> and then\n>>\n>> rgb = rgb * texture2D(lsc_tex, textureOut).rgb;\n>>\n>> We would cut out a lot of jump through hoops that way. Yeah we don't really need a compute shader to\n>> upload a float.\n>>\n>> Yeah ... really thinking about this - I think the conversion to bytes is unnecessary.\n>>\n>> Just calculate everything in float and upload it to the GPU - our worst case is passing GL_RGBA16F and\n>> loosing some precision, probably preferable unless the maximum value of the float exceeds 65.5k which it\n>> probably ? doesn't\n>>\n>> 16f is plenty of precision for a gain LUT and halves the texture memory/bandwidth required.\n>>\n>> I'd try :\n>>\n>> glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA16F, width, height, 0, GL_RGBA, GL_FLOAT, data);\n>\n> Ah, that's it, thank you for the tip. My previous float attempts\n> resulted in a black screen, using 16 bits does the trick. \n\nAnd I wonder why...\n\n> With your suggestion (and s/RGBA/RGB/), it works and is ~3 % faster in\n> my environment than the compressed bytes version. So I'll switch to\n> floats in v4.\n>\n>> rgb = rgb * texture2D(lsc_tex, textureOut).rgb;\n>>\n>> And dropping of that conversion to bytes - seems like just overhead to me.\n>>\n>> Check \"GL_OES_texture_half_float_linear\" in the GL_EXTENSIONS - we already interrogate these and just\n>> don't do LSC if float/half-float is missing.\n\nIt's not listed among EGL_EXTENSIONS reported in my environment but it\nstill works.\n\n>> BTW the internet machine tells me these two extensions became part of GLES 3.0 in 2012 and were optional\n>> before that so we are \"pretty safe\" in conjoining LSC to \"GL_OES_texture_half_float_linear\" IMO and\n>> gracefully refusing to run LSC without it.\n>>\n>> ---\n>> bod","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id B7666BE173\n\tfor ;\n\tMon, 4 May 2026 18:28:48 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 64D016302B;\n\tMon, 4 May 2026 20:28:48 +0200 (CEST)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.129.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A84D36302B\n\tfor ;\n\tMon, 4 May 2026 20:28:46 +0200 (CEST)","from mail-wm1-f71.google.com (mail-wm1-f71.google.com\n\t[209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS\n\t(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n\tus-mta-435-Xoh91j4OM5yGFAogU7Xe_w-1; Mon, 04 May 2026 14:28:44 -0400","by mail-wm1-f71.google.com with SMTP id\n\t5b1f17b1804b1-48a55ecc32cso41035935e9.1\n\tfor ;\n\tMon, 04 May 2026 11:28:44 -0700 (PDT)","from mzamazal-thinkpadp1gen7.tpbc.csb\n\t(ip-77-48-47-4.net.vodafone.cz. [77.48.47.4])\n\tby smtp.gmail.com with ESMTPSA id\n\t5b1f17b1804b1-48a82307f28sm581009695e9.13.2026.05.04.11.28.40\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tMon, 04 May 2026 11:28:41 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"SqfCepOZ\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1777919325;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=NdIu+9ecEqOZKuhCqWKHaKRAQEqm7jzKHWmqSOpDLuM=;\n\tb=SqfCepOZN6phwKn1380hsjaK5NFILYVAimccwfkfyASz1l5832vANZ+2W8RhFKWTHymJ0h\n\tluxslSHbi9vi6UgoRmH42OO8ADhaLzP56g2uCqIRWTvytCuqGAs7kPb8o/TXw1eDrEWHBu\n\tf4objWoCMS1VG2v5Ni3TONebVrX7RxU=","X-MC-Unique":"Xoh91j4OM5yGFAogU7Xe_w-1","X-Mimecast-MFC-AGG-ID":"Xoh91j4OM5yGFAogU7Xe_w_1777919323","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20251104; t=1777919323; x=1778524123;\n\th=mime-version:user-agent:message-id:date:references:in-reply-to\n\t:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject\n\t:date:message-id:reply-to;\n\tbh=NdIu+9ecEqOZKuhCqWKHaKRAQEqm7jzKHWmqSOpDLuM=;\n\tb=HiBfaHR51KeDQYOTeYGMLCmEpzDWBDzg/j4ZNvm3vU8csafiOFG+p1fiGBzXRqnVNH\n\tEPzniSUIH1yjgJgLG4nZ3xzyYTS6mzbPJq3vN2f3uQ65LiOilPmowyTtqpLkiOa1hHex\n\tnni7vR740RJme1CLICHfnFzu4M/g6PhtKf+2XmTPvez2UvN8CMFRx/uY4yf6pjSJ4i2c\n\tMSppIY/kHAkIXaZ6YmsAtgaD+k/kH0/5dpkyXXXE6/fPQ7R0wMHaNi8OXHH9NqEX+VCz\n\txSficbClFB5Jhi2vlVpiPZEcq9wGEizZk1orbbztYyXFcL7hqlGE13+9o66J9GZjrtP5\n\tHPWg==","X-Gm-Message-State":"AOJu0Yz3DZfV+laUsWz7GrnPyp1nJyPPTOXoNAYBwNg6+9O6+zcdEqSe\n\ttzAPeVyv3o724TOiyfvGx7+35Z4zFp31T2z/Ww+dMKy3XcItaEkZT9xCdNYZawg9Usbq90JEeZt\n\t5e9FiwTBonSIKoJeSC2noe4eBXffx0RV7T5bo9/CxjTQ+A+xEHoIGm16HpBypElAW7AR+FPAh9b\n\tAp0q+Lq7U=","X-Gm-Gg":"AeBDieuHNrO0E+KNOASBbZRga8x4e7qIQ/mDq/pwkhmr76GoxLjzTMDN+9sdUHRoCGi\n\tnev8RWinwpyWkDZSTKkbk8INx9xzfK395cohbeMVy5K6NAgryEjVWjqZEH36dTrZS5p8bfIp5s4\n\tRX/3kfis2TNc19s2v4+1DNkB13/pw8j8qDhpUs/w+3XfHWcbqkHL/C/TOv2Qr+NJx3rZSNym86f\n\tgUVcTvI6rs+gdLqv4Z4fibXZmoaXs2pPbWLm2YqDPGH5Tl54zwdy8R2zpMjFcHmC42i6TAWsfH4\n\t8EHp3RSqYqInzH+AwsR3a0q8TPM/YW9nTFUxDdCRXRXgGlTTX/8F0dWU9zDyDh1dLZDJ5DtWmJc\n\t58TKDBhc1SO8jMXf0vNBxNCih3R6MJL+13BqHN8aDtd18cgojVC9L2NP2HLwnRaib4q+aPC/FqT\n\t46k9KZ2k2u2g==","X-Received":["by 2002:a05:600c:4e8e:b0:489:6c22:e081 with SMTP id\n\t5b1f17b1804b1-48a980fc4ffmr182799495e9.0.1777919322755; \n\tMon, 04 May 2026 11:28:42 -0700 (PDT)","by 2002:a05:600c:4e8e:b0:489:6c22:e081 with SMTP id\n\t5b1f17b1804b1-48a980fc4ffmr182799015e9.0.1777919322269; \n\tMon, 04 May 2026 11:28:42 -0700 (PDT)"],"From":"Milan Zamazal ","To":"Bryan O'Donoghue ","Cc":"libcamera-devel@lists.libcamera.org, Xander Pronk\n\t, Hans de Goede\n\t, Rick ten Wolde\n\t","Subject":"Re: [RFC PATCH v3 4/7] ipa: simple: Add LSC algorithm","In-Reply-To":"<85ik935tc9.fsf@mzamazal-thinkpadp1gen7.tpbc.csb> (Milan\n\tZamazal's message of \"Mon, 04 May 2026 13:04:22 +0200\")","References":"<20260424200255.356798-1-mzamazal@redhat.com>\n\t\n\t<20260424200255.356798-5-mzamazal@redhat.com>\n\t<2c2ec86b-def0-4782-9c22-cb329fcc2f3b@nxsw.ie>\n\t<85ik935tc9.fsf@mzamazal-thinkpadp1gen7.tpbc.csb>","Date":"Mon, 04 May 2026 20:28:40 +0200","Message-ID":"<851pfr58rr.fsf@mzamazal-thinkpadp1gen7.tpbc.csb>","User-Agent":"Gnus/5.13 (Gnus v5.13)","MIME-Version":"1.0","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"t2RCny8Yh3uZBbSk0UzeUCVoLMYRAVptIduwmpOYBc4_1777919323","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]