Re: [Q] sensors, corrupting the top line
On Mon, Aug 17, 2009 at 7:09 PM, Guennadi Liakhovetskig.liakhovet...@gmx.de wrote: Hi Hans, all In soc-camera since its first version we have a parameter y_skip_top, which the sensor uses to tell the host (bridge) driver I am sending you that many lines more than what is requested, and you should drop those lines from the top of the image. I never investigated this in detail, originally this was a strong tip that the top line is always corrupted. Now I did investigate it a bit by setting this parameter to 0 and looking what the sensors actually produce. I am working with four sensor: mt9m001, mt9v022, mt9t031 and ov7725, of which only the first two had that parameter set to 1 from the beginning, the others didn't have it and also showed no signs of a problem. mt9m001 (monochrome) doesn't have the problem either, but mt9v022 does. It does indeed deliver the first line with randomly coloured pixels. Notice - this is not the top line of the sensor, this is the first read-out line, independent of the cropping position. So, it seems we do indeed need a way to handle such sensors. Do you have a suggestion for a meaningful v4l2-subdev API for this? Yep I also went through similar cases and I just skipped corrupted lines. That happens in various sensor devices isn't it? Moreover, we sometimes have whole corrupted image frames which are due to stabilization issue when we initialize the sensor device. In this case I decide to drop corresponding image frames with enough number.(3 frames enough in my experience). So, how about making an API which can cover all over these phonomenum? which can drop or skip line and frames. Host (bridge) queries through the API and get how many lines should skip or how many frames should drop or something like that.. Sounds fair to make an API which can cover general H/W defects or characteristics (even though that is not a defect) Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Q] sensors, corrupting the top line
Hi Hans, all In soc-camera since its first version we have a parameter y_skip_top, which the sensor uses to tell the host (bridge) driver I am sending you that many lines more than what is requested, and you should drop those lines from the top of the image. I never investigated this in detail, originally this was a strong tip that the top line is always corrupted. Now I did investigate it a bit by setting this parameter to 0 and looking what the sensors actually produce. I am working with four sensor: mt9m001, mt9v022, mt9t031 and ov7725, of which only the first two had that parameter set to 1 from the beginning, the others didn't have it and also showed no signs of a problem. mt9m001 (monochrome) doesn't have the problem either, but mt9v022 does. It does indeed deliver the first line with randomly coloured pixels. Notice - this is not the top line of the sensor, this is the first read-out line, independent of the cropping position. So, it seems we do indeed need a way to handle such sensors. Do you have a suggestion for a meaningful v4l2-subdev API for this? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Q] sensors, corrupting the top line
On Monday 17 August 2009 12:09:12 Guennadi Liakhovetski wrote: Hi Hans, all In soc-camera since its first version we have a parameter y_skip_top, which the sensor uses to tell the host (bridge) driver I am sending you that many lines more than what is requested, and you should drop those lines from the top of the image. I never investigated this in detail, originally this was a strong tip that the top line is always corrupted. Now I did investigate it a bit by setting this parameter to 0 and looking what the sensors actually produce. I am working with four sensor: mt9m001, mt9v022, mt9t031 and ov7725, of which only the first two had that parameter set to 1 from the beginning, the others didn't have it and also showed no signs of a problem. mt9m001 (monochrome) doesn't have the problem either, but mt9v022 does. It does indeed deliver the first line with randomly coloured pixels. Notice - this is not the top line of the sensor, this is the first read-out line, independent of the cropping position. So, it seems we do indeed need a way to handle such sensors. Do you have a suggestion for a meaningful v4l2-subdev API for this? Hmm, I think that the best way is to make a struct v4l2_subdev_sensor_ops, move the enum_framesizes/intervals from the video_ops to the sensor_ops (since these are only used by sensors AFAIK), and add a new op to sensor_ops: int (*skip_top_lines)(struct v4l2_subdev *sd, u32 *lines). When we add the op to set the bus_params, then that can be added to sensor_ops as well. I've always thought that we need sensor-specifc ops eventually and this is a good reason to do so. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
