linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kaaira Gupta <kgupta@es.iitr.ac.in>
To: Helen Koike <helen.koike@collabora.com>
Cc: Kaaira Gupta <kgupta@es.iitr.ac.in>,
	linux-media@vger.kernel.org,
	Kieran Bingham <kieran.bingham@ideasonboard.com>
Subject: [PATCH] media: vimc: Apply right blue and red channels to BGR
Date: Fri, 22 May 2020 20:57:02 +0530	[thread overview]
Message-ID: <20200522152701.GA26597@kaaira-HP-Pavilion-Notebook> (raw)
In-Reply-To: <d0668aa2-a091-6c33-bdc2-d0bddbb3e50e@collabora.com>

On Fri, May 22, 2020 at 11:15:21AM -0300, Helen Koike wrote:
> Hi Kaaira,

Hii!

> 
> Thanks for the patch.
> 
> On 5/22/20 4:11 AM, Kaaira Gupta wrote:
> > rgb[] is already calculated in the right order, there is no need to swap
> > the blue and red channels in it for BGR images. Hence give right rgb
> > channels to the src_frame.
> 
> It would be nice if you explain the issue you are facing, and what this fixes.

Sure. So libcamera's qcam configures the Capture to BGR for certain qt versions
(<5.14). So when we test qcam using vimc (by configuring the subdevs
from qcam side to BGR as well), we see that the red and blue channels on
the test image get inter-changed.This is a fix for that.

Should I describe this in the commit message as well?

> 
> > 
> > Signed-off-by: Kaaira Gupta <kgupta@es.iitr.ac.in>
> > ---
> >  drivers/media/test-drivers/vimc/vimc-debayer.c | 14 ++------------
> >  1 file changed, 2 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/media/test-drivers/vimc/vimc-debayer.c b/drivers/media/test-drivers/vimc/vimc-debayer.c
> > index c3f6fef34f68..d41d9f6180df 100644
> > --- a/drivers/media/test-drivers/vimc/vimc-debayer.c
> > +++ b/drivers/media/test-drivers/vimc/vimc-debayer.c
> > @@ -318,21 +318,11 @@ static void vimc_deb_process_rgb_frame(struct vimc_deb_device *vdeb,
> >  				       unsigned int col,
> >  				       unsigned int rgb[3])
> >  {
> > -	const struct vimc_pix_map *vpix;
> >  	unsigned int i, index;
> >  
> > -	vpix = vimc_pix_map_by_code(vdeb->src_code);
> >  	index = VIMC_FRAME_INDEX(lin, col, vdeb->sink_fmt.width, 3);
> > -	for (i = 0; i < 3; i++) {
> > -		switch (vpix->pixelformat) {
> > -		case V4L2_PIX_FMT_RGB24:
> > -			vdeb->src_frame[index + i] = rgb[i];
> > -			break;
> > -		case V4L2_PIX_FMT_BGR24:
> > -			vdeb->src_frame[index + i] = rgb[2 - i];
> > -			break;
> > -		}
> > -	}
> 
> This code looks correct to me.
> 
> The rgb[] arrays is an intermediary representation of the pixel, in the order of Red Green Blue.
> 
> If you look at vimc_deb_calc_rgb_sink(), you will see that rgb[] is indexed by this enum:
> 
> enum vimc_deb_rgb_colors {
> 	VIMC_DEB_RED = 0,
> 	VIMC_DEB_GREEN = 1,
> 	VIMC_DEB_BLUE = 2,
> };
> 
> So rgb[0] is the red component, rgb[1] green and rgb[2] blue.
> 
> The, in this part of the code that you removed, we use rgb[] array to calculate the final frame.
> 
> So, if there is an error, then I don't think it is here.
> Maybe the rgb[] array is wrong, and the error would be somewhere in vimc_deb_calc_rgb_sink().

I printed out the rbg[] array, and it was correctly calculating the r,g,
and b components. I think the channels should not be swapped while
assigning to src_frame, because for all the cases (BGR or RGB) it takes
input in the order of R,then G and finally B. Hence when we swap the
assignment to the frame, we are interchanging the channels.

> 
> Regards,
> Helen
> 
> 
> > +	for (i = 0; i < 3; i++)
> > +		vdeb->src_frame[index + i] = rgb[i];
> >  }
> >  
> >  static int vimc_deb_s_stream(struct v4l2_subdev *sd, int enable)
> > 

      reply	other threads:[~2020-05-22 15:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-22  7:11 [PATCH] media: vimc: Apply right blue and red channels to BGR Kaaira Gupta
2020-05-22 14:15 ` Helen Koike
2020-05-22 15:27   ` Kaaira Gupta [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200522152701.GA26597@kaaira-HP-Pavilion-Notebook \
    --to=kgupta@es.iitr.ac.in \
    --cc=helen.koike@collabora.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).