<< return to Pixycam.com

320 x 200 resolution inside Pixy

Pixy Software
#1

Hello,

For my application, the down-sampled image in PixyMon rejects false positives much better than the full-resolution processing running internally in the Pixy.

Is there a simple way to change the firmware to internally process the same down-sampled image that is sent to PixyMon?

Thanks in advance!

#2

Hello NullPointerException,
The short answer is unfortunately no. But there are a couple things that might help you.

  1. You may be getting better accuracy with lower resolution because of lower noise in the lower-resolution image, assuming you’re averaging pixels when downscaling. The new firmware version 3.0.11 has a “minimum frames per second” slider that allows Pixy2 to reduce the frames per second in the interest of getting lower noise for a given amount of light. This slider is in the “Camera” tab:

https://docs.pixycam.com/wiki/doku.php?id=wiki:v2:pixymon_index#camera-tab

  1. You can increase the “block filtering” in the “expert” tab to reduce the false positives. Increasing the block filtering will eliminate spurious detections.

https://docs.pixycam.com/wiki/doku.php?id=wiki:v2:pixymon_index#color-connected-components-expert-tab

  1. You can increase the “min block area” (also in the Expert tab) so Pixy2 will ignore smaller objects, which will also tend to go away in a reduced resolution image.

Hope this helps!

Edward

1 Like
#3

I’m actually using the Pixy v1, sorry if I posted in the wrong place…

Anyway, The Pixy v1 doesn’t have either of the first two options you mentioned. As for the “min block area”, yeah I’ve already tried playing with that. I’m 99% sure the reason that it works better in PixyMon Cooked mode is because of the higher SNR.

Ok so, you say it’s not easily possible to change the firmware to downscale… but is it possible? I’m not afraid to tinker with the firmware, as a matter of fact I’ve already added my own I2C protocol because I was unable to use the default one due to the limitations of the device the Pixy is interfacing with.

#4

It’s possible, but I don’t know what’s entailed. It may require getting into the M0 assembly code. :open_mouth:

Feel free to ask questions through. :grinning:

#5

Hmm, so looking at the code, I see this function in camera.cpp:

int32_t cam_setMode(const uint8_t &mode)
{
	if (mode!=g_mode)
	{
		if (mode==0)
		{
			cam_setRegs(g_mode0Regs, sizeof(g_mode0Regs));
			g_mode = 0;
		}
		else if (mode==1)
		{
			cam_setRegs(g_mode1Regs, sizeof(g_mode1Regs));
			g_mode = 1;
		}
		else 
			return -1;
	}
	return 0;
}

And in cameravals.h I see:

#define CAM_MODE0               0x00
#define CAM_MODE1               0x01
...
#define CAM_RES0                0x00 
#define CAM_RES1                0x01
#define CAM_RES2                0x02
#define CAM_RES0_WIDTH          1280
#define CAM_RES0_HEIGHT         800
#define CAM_RES1_WIDTH          640
#define CAM_RES1_HEIGHT         400
#define CAM_RES2_WIDTH          320
#define CAM_RES2_HEIGHT         200

So it looks like I need to do #define CAM_MODE2 0x03 and modify cam_setMode() with another else statement for that, and I need to find the proper register map to pass to cam_setRegs()

Any ideas on how to get that register map?

#6

The image sensor doesn’t have a resolution smaller than 640x400, so changing the register setting is probably not the right approach. The registers are documented in the Omnivision datasheet, but it requires an NDA agreement with Omnivision. :frowning: I would assume that you will need to process the frame by downsampling more than Pixy already does. I believe this is currently done in the M0 assembly code.

Edward