SparkFun Forums 

Where electronics enthusiasts find answers.

Have a good idea for a new product for SFE or Olimex? Let us know!
By Roxix
#105341
Hello,

In the begining of this thread someone said that in order to make a complite JPEG file I need to create and add JPEG header. So, can anyone say how does this header look like. I couldn't find it myself that it why I need your help.
Also, I read about a developers guide, but registration at Aptina got me nowhere. Can someone sent me this guide to e-mail plz.
evgeny_strife@mail.ru
By iand2010au
#112205
Hi Folks

This thread seems to have gone a bit quiet. Has anyone succeeded in getting this sensor to work reliably with jpeg ? I have yet to start work with the sensor but would love to hear if someone's made any progress. Anyone game to post a sample photo ? It still seems to be one of the best documented sensors available at relatively low cost. I'm planning to interface to a Rabbit controller, probably using the Averlogic 440b FIFO.

Regards
Ian
By EdCa22
#114273
Hello,

I would like to try and interface this sensor to a PIC or AVR and write JPEGs and if possible video at full res to an SDHC card. I'd rather not use a FIFO/SRAM, or a uProc with external RAM/Flash.. so if I have a uProc with DMA and say ~65MHz, do you think this will be fast enough? I am not sure what kind of bandwidth is required for transferring the JPEGs..

Thanks
By Aerospace
#114632
EdCa22, 65 MHz should be fast enough. I believe I've talked a little bit about the bandwidth requirements elsewhere on this thread.

iand2010au, I have gotten this sensor working reliably, here is an image:
Image
The artifact on the top left of the image is the result of a software algorithm I set up to grab a low res thumbnail along with each of my high res photos. I understand it and it is not a fault of the sensor chip or the hardware design. A lot of the development work and troubleshooting is documented on this board, and the datasheet and development guide available from micron are great resources for working with this chip. I'd recommend familiarizing yourself with all 3 before you start. Best of luck!
By iand2010au
#124946
Hi Folks
Just noticed on the Aptina website that a new datasheet for the MT9D131 has been released dated March 2011 and an updated developers guide. Looking at the latest headboard schematic it looks like the sensor has gone to a single 3.3v supply. If anyone has the latest datasheet and developers guide can you please post a copy somewhere. Or please email me a copy. Thanks in advance.
pobox2day@gmail.com
Regards
Ian
By vjcro
#124961
iand2010au wrote:Hi Folks
Just noticed on the Aptina website that a new datasheet for the MT9D131 has been released dated March 2011 and an updated developers guide. Looking at the latest headboard schematic it looks like the sensor has gone to a single 3.3v supply. If anyone has the latest datasheet and developers guide can you please post a copy somewhere. Or please email me a copy. Thanks in advance.
pobox2day@gmail.com
Regards
Ian

Hello everybody,

I would appreciate too if someone could send me the latest datasheet to:
v1a9n8a6@gmail.com

Thanks and regards!

vjcro
By iand2010au
#125695
Hi Folks
Don't know about you guys but am finding the task of interfacing to this sensor a bit tough. Good documentation but an amazing amount of registers and settings to look at and decide whether to change or not. I see some have had success which is encouraging and thanks to those who have posted register settings and initialisation code. Is anyone prepared to post or share a set of register and command values that works reliably. Preferable with JPEG output at full resolution. After looking through the guide and datasheet, it is not exactly obvious how some of these registers work or what they do. What is the advantage if any of using the spoof mode in JPG mode? Given the vast number of registers and settings that can be changed, it would be helpful to know which ones to leave at default and ignore. Then we would only have to deal with a smaller subset of registers to change depending on the output format, resolution etc. Looking at the JGP header code, wouldn't this produce the same data each time assuming the resolution, restart intervals and qfactor remains unchanged for a given data stream. If so then it could be loaded into memory as a fixed block of data and then forget about adding the header code all together. Can anyone post the header file produced by the Micron code for say full resolution at default qfactor and restart interval.
I know lots of questions and maybe I'm off track a bit here and there but I'm trying to say with the KISS principle where possible and get this sensor going. Surely I'm not the only one out there struggling with this beast !

Thanks
Ian
By iand2010au
#130010
Hi All
I've managed to capture a jpg file from the camera but seem to be having timing issues. Not sure if it's hardware or register settings. The timing looks ok but I seem to be losing the last part of the data stream that contains the length and status bytes. I am using spoof mode. Tried different restart intervals but still similar problems. Attached is an example of a corrupted image. Tried many register settings based on the Aptina Devware register wizard but no real progress. I am using a AL440B FIFO buffer and a 3 input AND gate to enable the WE pin of the FIFO based on FV, LV and an enable signal from the uP being high. Appreciate if any one has some suggestions to try.
testfile2j.jpg
You do not have the required permissions to view the files attached to this post.
By frankvh
#131473
The distinction between the vertical bands of colour should be sharp. In your image they're not - they're fuzzy and coloured. I'm fighting the exact same thing. I suspect (not yet confirmed) that it's a problem with the jpeg file header. I suspect the example source code in the aptina documentation to generate the file header isn't quite right. Are you using that same code to generate the file header?

Ideally Aerospace would still be here to give us his jpeg header generator code. But it looks like it's been a few months since he last visited.
By frankvh
#131538
There is certainly a problem with the aptina header generation code. The function DefineQuantizationTableMarker() produces incorrect results. I don't know exactly why this is, but it clearly does. Replace the function from the developer's guide with the following:
Code: Select all
// Calculate and write the quantisation tables 
// qscale is the customised scaling factor - see MT9D131 developer guide page 78
int DefineQuantizationTableMarker (unsigned char *pbuf, int qscale, int format)
{
	int i, length, temp;
	unsigned char newtbl[64];			// temporary array to store scaled zigzagged quant entries

	if (format == FORMAT_MONOCHROME)	// monochrome
		length  =  67;
	else
		length  =  132;

	*pbuf++  =  0xFF;			// define quantization table marker
	*pbuf++  =  0xDB;
	*pbuf++  =  length>>8;		// length field
	*pbuf++  =  length&0xFF;
	*pbuf++  =  0;				// quantization table precision | identifier

	
	// calculate scaled zigzagged luminance quantisation table entries
	for (i=0; i<64; i++) {
		temp = (JPEG_StdQuantTblY[i] * qscale + 16) / 32;
		// limit the values to the valid range
		if (temp <= 0) 
			temp = 1;
		if (temp > 255) 
			temp = 255; 
		newtbl[zigzag[i]] = (unsigned char) temp;
	}
	// write the resulting luminance quant table to the output buffer
	for (i=0; i<64; i++)
		*pbuf++ = newtbl[i];

	// if format is monochrome we're finished, otherwise continue on, to do chrominance quant table
	if (format == FORMAT_MONOCHROME)
		return length+2;

	*pbuf++ = 1;				// quantization table precision | identifier for chrominance

	// calculate scaled zigzagged chrominance quantisation table entries
	for (i=0; i<64; i++) {
		temp = (JPEG_StdQuantTblC[i] * qscale + 16) / 32;
		// limit the values to the valid range
		if (temp <= 0) 
			temp = 1;
		if (temp > 255) 
			temp = 255; 
		newtbl[zigzag[i]] = (unsigned char) temp;
	}
	// write the resulting chrominance quant table to the output buffer
	for (i=0; i<64; i++)
		*pbuf++ = newtbl[i];

	return (length+2);
}
To go along with the code you need the following 3 lookup tables:
Code: Select all
unsigned char JPEG_StdQuantTblY[64] = 
{
16,  11,  10,  16,  24,  40,  51,  61, 
12,  12,  14,  19,  26,  58,  60,  55,
14,  13,  16,  24,  40,  57,  69,  56,
14,  17,  22,  29,  51,  87,  80,  62,
18,  22,  37,  56,  68,  109, 103, 77,
24,  35,  55,  64,  81,  104, 113, 92,
49,  64,  78,  87, 103,  121, 120, 101,
72,  92,  95,  98, 112,  100, 103,  99
};

unsigned char JPEG_StdQuantTblC[64] = 
{
17,  18,  24,  47,  99,  99,  99,  99, 
18,  21,  26,  66,  99,  99,  99,  99,
24,  26,  56,  99,  99,  99,  99,  99,
47,  66,  99,  99,  99,  99,  99,  99,
99,  99,  99,  99,  99,  99,  99,  99,
99,  99,  99,  99,  99,  99,  99,  99,
99,  99,  99,  99,  99,  99,  99,  99,
99,  99,  99,  99,  99,  99,  99,  99
};

// this table is used for regular-position to zigzagged-position lookup
static unsigned char zigzag[64] = 
{ 
0, 1, 5, 6,14,15,27,28,
2, 4, 7,13,16,26,29,42,
3, 8,12,17,25,30,41,43,
9,11,18,24,31,40,44,53,
10,19,23,32,39,45,52,54,
20,22,33,38,46,51,55,60,
21,34,37,47,50,56,59,61,
35,36,48,49,57,58,62,63 
};
The inspiration for this code came from a user named Cristi Cuturicu at the website http://www.wotsit.org who posted some jpeg encoder / decoder code. I don't really know exactly where the aptina code is "broken", and I'm not too motivated to find out.

Using this revised function produces a far cleaner image. Take a look at the attached jpeg.

It's not perfect yet, but it's a big step forward.
You do not have the required permissions to view the files attached to this post.