On Hands and Knees Begging for a proper-Good Camera

[htcohio]

Hello,

First, I just want to say thank you for all the great things you guys have created, Raspberry Pi has open the door to so many possibilities.

With that said my inquiry is focused on the need for a new camera that is better suited for the streaming and UAV drone robotic type applications that a majority of people use them for.

My application is Open.HD (Branch of EZ-WIFIBROADCAST) which is a low latency packet injection/monitor mode based long-range video transmission system.

https://github.com/HD-Fpv/Open.HD

Latency:
https://youtu.be/9wORSRSSVvY

Vid 1
https://youtu.be/9IdX1wz22ZQ

Vid 2
https://youtu.be/C3-fypJs2P8

One of the video uses the Toshiba CSI to adapter for the GoPro and as you can see the video is really clear it also has a better dynamic range.

I'm trying to understand why for example in the V2 camera you chose a 8MP IMX219 1/4" 2.7K sensor we're very few people actually stream 2.7k video?

The Achilles heel of open HD has been the lack of wide dynamic range abilities of the V1 or V2 camera.

I have learned that more megapixels does not necessarily mean a better camera.

What we desperately need is a good, High quality 1MP - 2MP 1/2" sensor like the IMX290 or Aptina AR0330 capable of very low lux, WDR and large sensor/pixel size as to optimize 720p 60/1080p 30fps video application.

So much of our conversation outside of this forum for the open HD Wi-Fi broadcast system is about users trying to find alternative camera solutions such as the Auvidea B101 module, Arducam MIPI cams, Veye IMV291 or USB cameras.... However, those cameras have limited resolution options and don't have access to all of the juicy Raspivid advanced paramaters...

It is my hope that this message will not fall on deaf ears and within the next year, a new camera with some or all of the following:

• A high quality, Glass wide-angle lens,
• 1/2" WDR Sensor
• FPV Style tilt mount
• 1MP-3MP Sensor

[norbert_k]

Yes, we need it desperately , please help us

[scruss]

With that said my inquiry is focused on the need for a new camera that is better suited for the streaming and UAV drone robotic type applications that a majority of people use them for.

Oddly, I've yet to meet anyone doing this with a Raspberry Pi. How big is your community?

I'm trying to understand why for example in the V2 camera you chose a 8MP IMX219 1/4" 2.7K sensor …

It's cheap, small and it makes quite nice stills for kids in schools?

What we desperately need is a good, High quality 1MP - 2MP 1/2" sensor like the IMX290 or Aptina AR0330

That might be what you desperately need: it might be a little niche for the Foundation's needs. Could you sell such a thing for £25? The MIPI-CAM-290 with an IMX290 is rather more expensive than that.

[htcohio]

With that said my inquiry is focused on the need for a new camera that is better suited for the streaming and UAV drone robotic type applications that a majority of people use them for.

Oddly, I've yet to meet anyone doing this with a Raspberry Pi. How big is your community?

I'm trying to understand why for example in the V2 camera you chose a 8MP IMX219 1/4" 2.7K sensor …

It's cheap, small and it makes quite nice stills for kids in schools?

What we desperately need is a good, High quality 1MP - 2MP 1/2" sensor like the IMX290 or Aptina AR0330

That might be what you desperately need: it might be a little niche for the Foundation's needs. Could you sell such a thing for £25? The MIPI-CAM-290 with an IMX290 is rather more expensive than that.

Hi,

If you search "wifibroadcast" or "Openhd FPV" you will find many groups and forums. It is comparitively small to educational uses I am sure.

However, the MIPI290 Cam is specialized limited supply from innomaker which explains the high price however, the Imx290 (or imx 291, 327, 117) *Starvis line* are available for less than $30 in ip/usb camera format from multiple sources.

I would imagine a rpif compatible pi cam "V3" could be similarly priced at $25 especially with a new licensing deal with crypto chip like the IMX219 Pi cam V2 is.

Obviously we could try using the USB camera option with v4l2 but, that does not have access to the high-speed CSI bus, 120ms glass to glass latency and wide range of framerates.

Basically, I think 6by9 mentioned that the cameras were one of the biggest revenue makers for RPIF so, I stand to think that they would benefit from releasing a new camera to the masses.

Maybe I'm wrong????

[htcohio]

Also, UAV/Drone stuff aside, why do the only available options always have to be the absolute cheapest thing possible? Here is an example of a camera and DVR for $69 but, I'm just trying to share an example of an alternative to the stiff FlatFlex FFC Cable... Many similar cameras that use MIPI interfaces have a micro coaxial cable connection. This is just an example of a similar concept idea.

https://m.banggood.com/Caddx-Turtle-V2- ... m-alsolike

Basically, The commercial drone Industry is and is a $100 Billion industry which is growing fast.

The Raspberry Pi has extraordinary potential as a companion computer to the UAV drone industry between hobbyists and Commercial applications. Just myself personally along with people in the various drone groups Im certain that there are 1000+ people that I personally communicate with that are interested in an updated MIPI CSI2 Pi cam "V3" with IMX290 or similar and 160° wide angle lens .... Myself and them would gladly pay $30-$40 x 2-4 units for multiple drones if that becomes a reality.

Actually, just take a look online for the market involving drone/fpv cameras... There is definitely a huge market and, the good news is that people who have drones, tend to crash them resulting in the need of purchase a new camera... More $$ for rpi.

On a side note, the Raspberry Pi zero is a really nice format, price and size but, is slightly underpowered.

Pi3A+ was almost a home run but it's a little too big and someone decided to cut the memory in half otherwise I would have bought 12 of them myself.

The ideal Drone Pi wpuld have:

a Pi3A+ type board with a standard drone hole pattern of 30.5mm x 30.5mm.
1 x CSI-2 for camera
1 x micro hdmi out
Then, solder pads around the perimeter just like the Arducam SOM module prototype board.

Eliminate the bulky 40 pin gpios And instead have a Hirose 40pin socket (Similar to LatticeSemiconductor FPGA) so that whatever gpio is are needed can connect to an external header or individual wires.

*Sorry, I didn't mean to sway off topic but, just making some suggestions.

P.S. I know that Raspberry Pi does not really announce when new things are released but, I'm curious process is followed when making decisions about new releases? Do these forum posts mostly fall on deaf ears where other teams or developers decide themselves what should be included? Or, are there meetings at RPI Towers where new ideas are brought up based on various suggestions on the forums and users?

I just really believe that there is so much potential with Raspberry Pi that is not being explored.

[Pilotnbr1]

Yes the camera options are very mediocre... One nice things with the drone community is we often buy multiples of everything. Most of us have several aircraft and if there is a good solution, we outfit our "fleet'. And we crash and destroy things So we are repeat customers.

[Gavinmc42]

Years ago there was a third party PCB with a BCM2835 and camera/lens on the one PCB.
It was quickly shut down, but it is too bad RPF did not run with that, the OpenCV industry would have liked it?

An OpenDV system for drones? 4K+ res.
Rats, OpenDV is taken - Digital Voice.
A nice standard system, swap lenses etc, it is a fast growing market.

[narpat007]

Yes, we need it desperately , please help us

[jamesh]

I think the use case is too small for camera devices this specific.

Also worth noting it takes some YEARS to go from deciding on a sensor to releasing it.

[fruitoftheloom]

Hello,

First, I just want to say thank you for all the great things you guys have created, Raspberry Pi has open the door to so many possibilities.

With that said my inquiry is focused on the need for a new camera that is better suited for the streaming and UAV drone robotic type applications that a majority of people use them for.

My application is Open.HD (Branch of EZ-WIFIBROADCAST) which is a low latency packet injection/monitor mode based long-range video transmission system.

https://github.com/HD-Fpv/Open.HD

Latency:
https://youtu.be/9wORSRSSVvY

Vid 1
https://youtu.be/9IdX1wz22ZQ

Vid 2
https://youtu.be/C3-fypJs2P8

One of the video uses the Toshiba CSI to adapter for the GoPro and as you can see the video is really clear it also has a better dynamic range.

I'm trying to understand why for example in the V2 camera you chose a 8MP IMX219 1/4" 2.7K sensor we're very few people actually stream 2.7k video?

The Achilles heel of open HD has been the lack of wide dynamic range abilities of the V1 or V2 camera.

I have learned that more megapixels does not necessarily mean a better camera.

What we desperately need is a good, High quality 1MP - 2MP 1/2" sensor like the IMX290 or Aptina AR0330 capable of very low lux, WDR and large sensor/pixel size as to optimize 720p 60/1080p 30fps video application.

So much of our conversation outside of this forum for the open HD Wi-Fi broadcast system is about users trying to find alternative camera solutions such as the Auvidea B101 module, Arducam MIPI cams, Veye IMV291 or USB cameras.... However, those cameras have limited resolution options and don't have access to all of the juicy Raspivid advanced paramaters...

It is my hope that this message will not fall on deaf ears and within the next year, a new camera with some or all of the following:

• A high quality, Glass wide-angle lens,
• 1/2" WDR Sensor
• FPV Style tilt mount
• 1MP-3MP Sensor

If you are adamant that a better camera is absolutely necessary, why not develop the product yourself ??

Crowd funding has brought many products to market.

[htcohio]

I think the use case is too small for camera devices this specific.

Also worth noting it takes some YEARS to go from deciding on a sensor to releasing it.

Thank you for the response,

The proposed examples of image sensors would not only benefit UAVs, but any application related to robotics, machine vision, vehicle ADAS etc...

The case I am trying to make is that the OV5647 and IMX219 V1/V2 cameras currently available do have drawbacks.

Also, just to clarify... Our specific Open.HD system achieves something that no other DIY high-definition long-range, low latency video transmission even comes close to. Also, Open.HDs video stability is highly dependent on the VideoCore GPU and CSI-2 interface.

All things aside, I what assume that a updated camera version would be well received by the community as a whole.

[htcohio]

Hello,

First, I just want to say thank you for all the great things you guys have created, Raspberry Pi has open the door to so many possibilities.

With that said my inquiry is focused on the need for a new camera that is better suited for the streaming and UAV drone robotic type applications that a majority of people use them for.

My application is Open.HD (Branch of EZ-WIFIBROADCAST) which is a low latency packet injection/monitor mode based long-range video transmission system.

https://github.com/HD-Fpv/Open.HD

Latency:
https://youtu.be/9wORSRSSVvY

Vid 1
https://youtu.be/9IdX1wz22ZQ

Vid 2
https://youtu.be/C3-fypJs2P8

One of the video uses the Toshiba CSI to adapter for the GoPro and as you can see the video is really clear it also has a better dynamic range.

I'm trying to understand why for example in the V2 camera you chose a 8MP IMX219 1/4" 2.7K sensor we're very few people actually stream 2.7k video?

The Achilles heel of open HD has been the lack of wide dynamic range abilities of the V1 or V2 camera.

I have learned that more megapixels does not necessarily mean a better camera.

What we desperately need is a good, High quality 1MP - 2MP 1/2" sensor like the IMX290 or Aptina AR0330 capable of very low lux, WDR and large sensor/pixel size as to optimize 720p 60/1080p 30fps video application.

So much of our conversation outside of this forum for the open HD Wi-Fi broadcast system is about users trying to find alternative camera solutions such as the Auvidea B101 module, Arducam MIPI cams, Veye IMV291 or USB cameras.... However, those cameras have limited resolution options and don't have access to all of the juicy Raspivid advanced paramaters...

It is my hope that this message will not fall on deaf ears and within the next year, a new camera with some or all of the following:

• A high quality, Glass wide-angle lens,
• 1/2" WDR Sensor
• FPV Style tilt mount
• 1MP-3MP Sensor

If you are adamant that a better camera is absolutely necessary, why not develop the product yourself ??

Crowd funding has brought many products to market.

Would love to but the VideoCore GPU is closed source.

[fruitoftheloom]

Hello,

First, I just want to say thank you for all the great things you guys have created, Raspberry Pi has open the door to so many possibilities.

With that said my inquiry is focused on the need for a new camera that is better suited for the streaming and UAV drone robotic type applications that a majority of people use them for.

My application is Open.HD (Branch of EZ-WIFIBROADCAST) which is a low latency packet injection/monitor mode based long-range video transmission system.

https://github.com/HD-Fpv/Open.HD

Latency:
https://youtu.be/9wORSRSSVvY

Vid 1
https://youtu.be/9IdX1wz22ZQ

Vid 2
https://youtu.be/C3-fypJs2P8

One of the video uses the Toshiba CSI to adapter for the GoPro and as you can see the video is really clear it also has a better dynamic range.

I'm trying to understand why for example in the V2 camera you chose a 8MP IMX219 1/4" 2.7K sensor we're very few people actually stream 2.7k video?

The Achilles heel of open HD has been the lack of wide dynamic range abilities of the V1 or V2 camera.

I have learned that more megapixels does not necessarily mean a better camera.

What we desperately need is a good, High quality 1MP - 2MP 1/2" sensor like the IMX290 or Aptina AR0330 capable of very low lux, WDR and large sensor/pixel size as to optimize 720p 60/1080p 30fps video application.

So much of our conversation outside of this forum for the open HD Wi-Fi broadcast system is about users trying to find alternative camera solutions such as the Auvidea B101 module, Arducam MIPI cams, Veye IMV291 or USB cameras.... However, those cameras have limited resolution options and don't have access to all of the juicy Raspivid advanced paramaters...

It is my hope that this message will not fall on deaf ears and within the next year, a new camera with some or all of the following:

• A high quality, Glass wide-angle lens,
• 1/2" WDR Sensor
• FPV Style tilt mount
• 1MP-3MP Sensor

If you are adamant that a better camera is absolutely necessary, why not develop the product yourself ??

Crowd funding has brought many products to market.

Would love to but the VideoCore GPU is closed source.

Poppycock !!

https://www.arducam.com/use-almost-any- ... pberry-pi/

[jamesh]

I think the use case is too small for camera devices this specific.

Also worth noting it takes some YEARS to go from deciding on a sensor to releasing it.

Thank you for the response,

The proposed examples of image sensors would not only benefit UAVs, but any application related to robotics, machine vision, vehicle ADAS etc...

The case I am trying to make is that the OV5647 and IMX219 V1/V2 cameras currently available do have drawbacks.

Also, just to clarify... Our specific Open.HD system achieves something that no other DIY high-definition long-range, low latency video transmission even comes close to. Also, Open.HDs video stability is highly dependent on the VideoCore GPU and CSI-2 interface.

All things aside, I what assume that a updated camera version would be well received by the community as a whole.

Just because I'd be interested in what you think about this, how many cameras do you think could be sold in this market, per year? I won't say how many we currently sell, as that might influence your numbers.

We are obviously aware of the limitations of the current camera. We do not just sit back here in Pi towers sitting on our hands, we keep a very close eye on technology in all areas that we deal in.

[htcohio]

If you are adamant that a better camera is absolutely necessary, why not develop the product yourself ??

Crowd funding has brought many products to market.

Would love to but the VideoCore GPU is closed source.

Poppycock !!

https://www.arducam.com/use-almost-any- ... pberry-pi/

Please read the page, you will see that it implements a userland driver. This does not allow access to the full Raspivid controls.

You can only use 1080p 30fps. Or a couple framerates.

Also, the latency is approx 50ms higher .

[fruitoftheloom]

Would love to but the VideoCore GPU is closed source.

Poppycock !!

https://www.arducam.com/use-almost-any- ... pberry-pi/

Please read the page, you will see that it implements a userland driver. This does not allow access to the full Raspivid controls.

You can only use 1080p 30fps. Or a couple framerates.

Also, the latency is approx 50ms higher .

Unfortunately you will have a very long wait for someone else to Manufacture the Product which is Commercially viable

[HermannSW]

> Please read the page, you will see that it implements a userland driver. This does not allow access to the full Raspivid controls.
>
The Arducam driver is raspiraw based because any kernel driver would run into GPL problems:
https://github.com/ArduCAM/MIPI_Camera

> You can only use 1080p 30fps. Or a couple framerates.
>
You said you want 1-3MP, right?
Then the color rolling shutter cameras are not right (13MP/16MP/18MP).
I got samples of 0.3MP/1MP/2MP monochrome global shutter cameras from Arducam.
The 2MP module will be available as color model as well
"list_formats" tells you the available formats, I did run that on ov9281 1MP camera stereo module two days ago:
https://www.raspberrypi.org/forums/view ... 3#p1551503
There is no 1080p, available formats are 1280x800/1280x720/640x400/320x200/160x100 for the 1MP module.
I can run list_formats for the 2MP camera when back home tomorrow evening.

> Also, the latency is approx 50ms higher .
>
Where do you have that information from?
I did not look at latency, but the 1MP camera did capture [email protected] when I tested it first (static scene).
They found a way to pipe the stream of frames received from CSI-2 through GPU for fast .h264 encoding (MMAL?).

[htcohio]

I think the use case is too small for camera devices this specific.

Also worth noting it takes some YEARS to go from deciding on a sensor to releasing it.

Thank you for the response,

The proposed examples of image sensors would not only benefit UAVs, but any application related to robotics, machine vision, vehicle ADAS etc...

The case I am trying to make is that the OV5647 and IMX219 V1/V2 cameras currently available do have drawbacks.

Also, just to clarify... Our specific Open.HD system achieves something that no other DIY high-definition long-range, low latency video transmission even comes close to. Also, Open.HDs video stability is highly dependent on the VideoCore GPU and CSI-2 interface.

All things aside, I what assume that a updated camera version would be well received by the community as a whole.

We are obviously aware of the limitations of the current camera. We do not just sit back here in Pi towers sitting on our hands, we keep a very close eye on technology in all areas that we deal in.

Hi, thank you again for the response, I realize that you guys have to keep track of various technology and use cases. I personally would not be lobbying on here for this if it wasn't for the great work that you guys have done already.

The work that was done years ago with the Broadcom SOC turned out to be an excellent platform. I am sure you are aware that no competitors comes close to the capabilities and low cost of the BCM GPU. Nano pi, Beagle etc... And, most don't even have a MIPI interface.

It would be really awesome if the image sensors provided by RPIF could match the performance of the GPU.

Just because I'd be interested in what you think about this, how many cameras do you think could be sold in this market, per year? I won't say how many we currently sell, as that might influence your numbers.

If you are asking for my estimate for how many RPI cameras could potentially be sold annually for UAV drone, Robotic applications each year above and beyond what is currently sold? Probably not a significant number by itself.

However, if lets say 1-2 million camera modules are sold each year currently, I think it's fair to assume that a significant percentage of combined past sales of cameras would buy an updated/improved Pi camera "V3" in order to upgrade their current application or use case.

Additionally, the Drone + fpv market is a relatively new billion-dollar industry that is continuing to grow. (If you search "FPV Cameras" I think you will see that there's a significant market for that application and, most of those are still analog).

And, as far as I am aware, the Raspberry Pi based digital long-range low latency video transmission system is the only feesable DIY alternative to commercial products like DJI lightbridge.

[6by9]

> Please read the page, you will see that it implements a userland driver. This does not allow access to the full Raspivid controls.
>
The Arducam driver is raspiraw based because any kernel driver would run into GPL problems:
https://github.com/ArduCAM/MIPI_Camera

GPL is not a problem if you do it right. Arducam didn't as they reused significant amounts of GPLv2 code - https://github.com/ArduCAM/RaspberryPi/issues/4. If you're protectionist over your drivers, then the Linux kernel is not the place to play.

Most sensor manufacturers are now becoming happier to have drivers for their sensors in the mainline kernel (and hence GPLv2), but it does require asking and potentially working with them on what is released.
You may still need to add a userland SDK to take the raw frames from V4L2, but that is the cleaner way of doing things.

> You can only use 1080p 30fps. Or a couple framerates.
>
You said you want 1-3MP, right?
Then the color rolling shutter cameras are not right (13MP/16MP/18MP).
I got samples of 0.3MP/1MP/2MP monochrome global shutter cameras from Arducam.
The 2MP module will be available as color model as well
"list_formats" tells you the available formats, I did run that on ov9281 1MP camera stereo module two days ago:
https://www.raspberrypi.org/forums/view ... 3#p1551503
There is no 1080p, available formats are 1280x800/1280x720/640x400/320x200/160x100 for the 1MP module.
I can run list_formats for the 2MP camera when back home tomorrow evening.

> Also, the latency is approx 50ms higher .
>
Where do you have that information from?
I did not look at latency, but the 1MP camera did capture [email protected] when I tested it first (static scene).
They found a way to pipe the stream of frames received from CSI-2 through GPU for fast .h264 encoding (MMAL?).

Latency will be higher.
The firmware will stream the frame into the ISP as sufficient lines become available. The firmware can then generally have completed the frame within a few ms of the end of the frame being received.
rawcam will only deliver the buffer when the complete frame has been received, and then it gets submitted to the ISP for processing. For a 1080P frame you're looking at around 16ms for the processing (based on 120MPix/s), so around 12ms worse off.
The latency through the rest of the pipeline should be identical though, so a difference of 50ms seems a little extreme and indicates something wrong

raspivid is not magic, it just plumbs components together.

[htcohio]

> Please read the page, you will see that it implements a userland driver. This does not allow access to the full Raspivid controls.
>
The Arducam driver is raspiraw based because any kernel driver would run into GPL problems:
https://github.com/ArduCAM/MIPI_Camera

GPL is not a problem if you do it right. Arducam didn't as they reused significant amounts of GPLv2 code - https://github.com/ArduCAM/RaspberryPi/issues/4. If you're protectionist over your drivers, then the Linux kernel is not the place to play.

Most sensor manufacturers are now becoming happier to have drivers for their sensors in the mainline kernel (and hence GPLv2), but it does require asking and potentially working with them on what is released.
You may still need to add a userland SDK to take the raw frames from V4L2, but that is the cleaner way of doing things.

> You can only use 1080p 30fps. Or a couple framerates.
>
You said you want 1-3MP, right?
Then the color rolling shutter cameras are not right (13MP/16MP/18MP).
I got samples of 0.3MP/1MP/2MP monochrome global shutter cameras from Arducam.
The 2MP module will be available as color model as well
"list_formats" tells you the available formats, I did run that on ov9281 1MP camera stereo module two days ago:
https://www.raspberrypi.org/forums/view ... 3#p1551503
There is no 1080p, available formats are 1280x800/1280x720/640x400/320x200/160x100 for the 1MP module.
I can run list_formats for the 2MP camera when back home tomorrow evening.

> Also, the latency is approx 50ms higher .
>
Where do you have that information from?
I did not look at latency, but the 1MP camera did capture [email protected] when I tested it first (static scene).
They found a way to pipe the stream of frames received from CSI-2 through GPU for fast .h264 encoding (MMAL?).

Latency will be higher.
The firmware will stream the frame into the ISP as sufficient lines become available. The firmware can then generally have completed the frame within a few ms of the end of the frame being received.
rawcam will only deliver the buffer when the complete frame has been received, and then it gets submitted to the ISP for processing. For a 1080P frame you're looking at around 16ms for the processing (based on 120MPix/s), so around 12ms worse off.
The latency through the rest of the pipeline should be identical though, so a difference of 50ms seems a little extreme and indicates something wrong

raspivid is not magic, it just plumbs components together.

Hey, I apologize, I was thinking of the latency difference with the HDMI input card (B101)



Also,didn't clarify that I meant Glass-to-glass latency with h.264 bytestream compression ... (-Gst Launch pipeline between 2 Wi-Fi cards).

Below is a video comparing pi cam V2 and innomaker Veye IMX290 (limited to only 1080p 30fps)
*Latency test towards the end.

I also had the same measurement with the Arducam Imx135 as I believe that uses the same type of driver.

*Latency comparison starts around 5:00 on video.
https://youtu.be/0sOMc_12pRA

25-30ms might not seem like a lot but, with UAVs, that 30ms difference really starts to become noticeable.

Also, with Raspivid running 60fps or 90fps glass to glass latency is 100-120ms.

[jamesh]

The work that was done years ago with the Broadcom SOC turned out to be an excellent platform. I am sure you are aware that no competitors comes close to the capabilities and low cost of the BCM GPU. Nano pi, Beagle etc... And, most don't even have a MIPI interface.

It would be really awesome if the image sensors provided by RPIF could match the performance of the GPU.

Actually, they do get close. For example, with only two lane CSI we already hit the bandwidth limitations getting data off the sensor i.e. the sensor is faster than the Pi. Changing to four lane would require new Pi boards, connectors etc, or you could use the Compute Module which exposes the second CSI port which is four lane. There is also a total number of pixels the ISP can handle - it's about 300MPixels/s on the pi4 (which has a faster GPU clock due smaller silicon), lower on the older models ie anything prior to the 4. So whatever the sensor, we can only stuff that many pixels through the pipeline - that is the real ISP limitation.

So irrespective of the sensor, the latency is going to be the same at similar resolutions.

[htcohio]

The work that was done years ago with the Broadcom SOC turned out to be an excellent platform. I am sure you are aware that no competitors comes close to the capabilities and low cost of the BCM GPU. Nano pi, Beagle etc... And, most don't even have a MIPI interface.

It would be really awesome if the image sensors provided by RPIF could match the performance of the GPU.

Actually, they do get close. For example, with only two lane CSI we already hit the bandwidth limitations getting data off the sensor i.e. the sensor is faster than the Pi. Changing to four lane would require new Pi boards, connectors etc, or you could use the Compute Module which exposes the second CSI port which is four lane. There is also a total number of pixels the ISP can handle - it's about 300MPixels/s on the pi4 (which has a faster GPU clock due smaller silicon), lower on the older models ie anything prior to the 4. So whatever the sensor, we can only stuff that many pixels through the pipeline - that is the real ISP limitation.

So irrespective of the sensor, the latency is going to be the same at similar resolutions.

Hi,

We are actually not looking for more megapixels... In fact, fewer (e.g 1MP-3MP) with a larger sensor.

The Sony Starvis IMX290 and others are an example of what is commonly used in webcams, IP Security Cams, Dash Cameras ADAS vehicle driver assistance etc... Because with fewer pixels combined with a larger sensor, each pixel is able to essentially capture more photons therefore improving wide dynamic range, ability to reduce exposure time while maintaining vivid colors and clarity...

Generally, 1MP=720P and 2MP=1080p.

For most streaming, security or most any video application will not benefit from more pixels.

Here is a Starvis demo video. (Imx290).

https://youtu.be/6gwt7mFOxBs

[6by9]

We are actually not looking for more megapixels... In fact, fewer (e.g 1MP-3MP) with a larger sensor.

The Sony Starvis IMX290 and others are an example of what is commonly used in webcams, IP Security Cams, Dash Cameras ADAS vehicle driver assistance etc... Because with fewer pixels combined with a larger sensor, each pixel is able to essentially capture more photons therefore improving wide dynamic range, ability to reduce exposure time while maintaining vivid colors and clarity...

Generally, 1MP=720P and 2MP=1080p.

For most streaming, security or most any video application will not benefit from more pixels.

Here is a Starvis demo video. (Imx290).

https://youtu.be/6gwt7mFOxBs

A driver for IMX290 is in the process of being upstreamed - https://lkml.org/lkml/2019/10/4/586
There is the bcm2835-unicam driver that should connect to that just with a suitable DT overlay.
You'll need a compute module as that driver only supports 4 lanes of CSI whilst the Pi only exposes 2. One of the registers in the register set will switch it down to 2 lanes, but without documentation you'll struggle to find it.
Whether the required 37.125MHz clock setup matches with the Arducam one is also an unknown.

You have access to the ISP processing path, but need to provide your own control algorithms.
The Broadcom ISP doesn't have support for HDR or other weird multiple exposure in a single frames, therefore they are of limited use.

So whilst it isn't handed to you on a plate, you can hook the IMX290 up and do useful stuff with it. https://vcmipi-modules.com/ even list IMX290 (mono only) as one of their products, therefore you could put your money where your mouth is.

[htcohio]

We are actually not looking for more megapixels... In fact, fewer (e.g 1MP-3MP) with a larger sensor.

The Sony Starvis IMX290 and others are an example of what is commonly used in webcams, IP Security Cams, Dash Cameras ADAS vehicle driver assistance etc... Because with fewer pixels combined with a larger sensor, each pixel is able to essentially capture more photons therefore improving wide dynamic range, ability to reduce exposure time while maintaining vivid colors and clarity...

Generally, 1MP=720P and 2MP=1080p.

For most streaming, security or most any video application will not benefit from more pixels.

Here is a Starvis demo video. (Imx290).

https://youtu.be/6gwt7mFOxBs

A driver for IMX290 is in the process of being upstreamed - https://lkml.org/lkml/2019/10/4/586
There is the bcm2835-unicam driver that should connect to that just with a suitable DT overlay.
You'll need a compute module as that driver only supports 4 lanes of CSI whilst the Pi only exposes 2. One of the registers in the register set will switch it down to 2 lanes, but without documentation you'll struggle to find it.
Whether the required 37.125MHz clock setup matches with the Arducam one is also an unknown.

You have access to the ISP processing path, but need to provide your own control algorithms.
The Broadcom ISP doesn't have support for HDR or other weird multiple exposure in a single frames, therefore they are of limited use.

So whilst it isn't handed to you on a plate, you can hook the IMX290 up and do useful stuff with it. https://vcmipi-modules.com/ even list IMX290 (mono only) as one of their products, therefore you could put your money where your mouth is.

Correct me if I'm wrong but isn't that exactly what the Innomaker IMX290 is using in my video?

It has i2c commands for WDR white balance etc...

Also, Raspivid has "-drc" (dynamic range compensation). Is this a different parameter compared to wide dynamic range?

https://youtu.be/a2c4s9dirSQ

http://www.inno-maker.com/product/mipi-cam-290/

It sounds like you are letting myself and others know that it's possible to get a third party camera working on the MIPI CSI-2 port.... If so, I am fully aware that there are options. I have tried them and got them working I'll be at with some drawbacks regarding latency, limited frame rates/resolutions etc...

As I mentioned, Openhd & wifibroadcast works best with Raspivid driver for various reasons not all mentioned to here.

I guess what I'm trying to determine is;

1. Are you able to say or disclose if there is or will be any official RPI cameras in the near future?
(I realize that you never announce new Pi boards I'm just not sure if that applies to the other accessories as well?)

Or, is the V1 V2 camera all we should expect for the foreseeable future as a relates to the Raspivid driver?

Thank you again for the quick responses

[fruitoftheloom]

We are actually not looking for more megapixels... In fact, fewer (e.g 1MP-3MP) with a larger sensor.

The Sony Starvis IMX290 and others are an example of what is commonly used in webcams, IP Security Cams, Dash Cameras ADAS vehicle driver assistance etc... Because with fewer pixels combined with a larger sensor, each pixel is able to essentially capture more photons therefore improving wide dynamic range, ability to reduce exposure time while maintaining vivid colors and clarity...

Generally, 1MP=720P and 2MP=1080p.

For most streaming, security or most any video application will not benefit from more pixels.

Here is a Starvis demo video. (Imx290).

https://youtu.be/6gwt7mFOxBs

A driver for IMX290 is in the process of being upstreamed - https://lkml.org/lkml/2019/10/4/586
There is the bcm2835-unicam driver that should connect to that just with a suitable DT overlay.
You'll need a compute module as that driver only supports 4 lanes of CSI whilst the Pi only exposes 2. One of the registers in the register set will switch it down to 2 lanes, but without documentation you'll struggle to find it.
Whether the required 37.125MHz clock setup matches with the Arducam one is also an unknown.

You have access to the ISP processing path, but need to provide your own control algorithms.
The Broadcom ISP doesn't have support for HDR or other weird multiple exposure in a single frames, therefore they are of limited use.

So whilst it isn't handed to you on a plate, you can hook the IMX290 up and do useful stuff with it. https://vcmipi-modules.com/ even list IMX290 (mono only) as one of their products, therefore you could put your money where your mouth is.

Correct me if I'm wrong but isn't that exactly what the Innomaker IMX290 is using in my video?

It has i2c commands for WDR white balance etc...

Also, Raspivid has "-drc" (dynamic range compensation). Is this a different parameter compared to wide dynamic range?

https://youtu.be/a2c4s9dirSQ

http://www.inno-maker.com/product/mipi-cam-290/

It sounds like you are letting myself and others know that it's possible to get a third party camera working on the MIPI CSI-2 port.... If so, I am fully aware that there are options. I have tried them and got them working I'll be at with some drawbacks regarding latency, limited frame rates/resolutions etc...

As I mentioned, Openhd & wifibroadcast works best with Raspivid driver for various reasons not all mentioned to here.

I guess what I'm trying to determine is;

1. Are you able to say or disclose if there is or will be any official RPI cameras in the near future?
(I realize that you never announce new Pi boards I'm just not sure if that applies to the other accessories as well?)

Or, is the V1 V2 camera all we should expect for the foreseeable future as a relates to the Raspivid driver?

Thank you again for the quick responses

Still at a loss why you will not develop your own product, despite your negativity, it seems feasible especially if it is based around a Compute Module.