Device...
 

I agree - opera rocks!

One question though, Andrey - would it be possible to create a VGA out + make a simple gui using the camera computer?

If so...one of these 1024x768 touchscreen display's could be used:
http://www.lilliputweb.net/ts629.html
http://www.lilliputweb.net/ts619.html

..connecting to VGA and USB.
Eliminating the hassle of a laptop/PDA.

What do you think?

//O.

..........

Instead of relying on the existing web-based UI, it seems to me that a UI built into the streaming video would be best. For example, generate a native N800-resolution (800x480) stream with UI elements alongside the "viewfinder" image. (See attachment.)

While the touchscreen could be used for input, I was thinking more along the lines of using a wireless/wired USB input device such as a mini-keypad or Speedpad N52 which provide tactile feedback and could be used quickly without having to move your eyes from the viewfinder to any UI buttons.

I don't think it is a really good idea - it will be too expensive to develop such system (you can not spread development cost over high volume) and VGA - isn't it going obsolete?

I think it is better to use inexpensive off-the shelf devices connected with existent interface(s)

I don't like this idea too much either - it is not a modern approach :-)

Developing and implementing such user interface from scratch can again be prohibitively expensive with low-volume production. If it is all inside the camera you'll have to make sure that interface functions will not compete over the resources with the streamer causing drop-outs.

Using power of web browser simplifies development and improves portability of the solution. Portability is important as the hardware (including 3-rd party like tablets) become obsolete rather soon

Gui...
 

You are right Andrey...keeping the camera non specific and putting all the GUI and display mechanisms in an external device makes sense. Good point about spreading development costs over volume.

So far the Nokia devices seem most likely to work.
More info about the N800: (successor to Nokia 770)
http://www.engadget.com/2007/01/05/n...ablet-unboxed/
http://www.flickr.com/photos/5th_ave...7594461870146/
http://www.flickr.com/photo_zoom.gne...57594461870146

Ok...so now I just have to be really patient until April...

I REALLY look forward to harddisk recording :)

//O.

I understand -- at the same time, it would be nice to be able to include overlays directly in the video stream.

Out of curiosity, here is that Pocket Samsung UMPC phone, with 1Ghz processor:

http://www.carrypad.com/products/product.php?id=51

Here is an replacement for the 9500 keyboard phone, lucky I didn't get the old model on ebay. I hope there will be an replacement for the tablet phone too:

http://www.engadget.com/photos/nokia...t-pics/156093/
http://www.engadget.com/photos/nokia...t-pics/156092/

sorry for interrupting but i couln't undestand the reason why you are not using a hd webcam sensor that is ready to connect by usb2 and a laptop to capture directly?

sorry about that if you mentioned the answer before but my english is not very good and i might have missed it...

353 - got first images
 

Finally - got first images from the 353

Because the camera is an networked security camera, designed to be shared over an network, primarily. USB2 is not capable of the multiplexed extension Ethernet is, so you would be limited. Secondly, the chips incorporated don't support it. USB2 is also an notorious processor Hog, as it is designed to be looked after by the processor (more brilliance that slows PC's). At the rates USB2 can work at, it can seriously tax a portable PC device (dropped frames etc).

thanks for the detailed expenation :)

wow! when you can, post a link
many thanks
Matteo

Yes!
 

..I second that! :)

Thanks!!

//O.

Images are really ugly (so I do not want to post camera IP here :-) ) - the only sensor 5MPix board left I had has a malfunctioning sensor (probably not all he sensor chip pins were hand-soldered nicely) and I did not yet finish porting of all the software (some parts are still missing - like setting the gamma tables).
My goal was to test hardware before going to larger batch, especially interface to the new CPU - PIO, interrupts, DMA. I even had to solve some problems with the new Spartan 3E (vs. Spartan 3) FPGAs to make them work as needed.
So this part works and being built as they are tested so far 10353 can do at least what 333 could. There are some features not tested yet (IDE, USB, fast system bus acquisition) - but that will be done later - in parallel with the camera manufacturing.

PHP in 353
 

I hope it can make development of the camera interface easier - PHP now works in the 353

cool I tink is possible to use it to make a database to save the setting
and to load preset ....did you suggest some more spec that can be used with this new capability (php rocks)?

Matteo, there is no database (yet) - just php itself to simplify server(camera)-side interface software. I'm thinking of a number of smaller binaries (instead iof the ccam.cgi) for low-level hardware-related functions with the interface level implemented in PHP.

Php...
 

Andrey,

PHP in-camera - very cool...

..would it be possible to start a in-camera timer that executes a PHP script say every 5minutes or something...taking a photo or doing something else?

Just curious

//O.

I believe there are some light Linux distros which can be installed and run from a USB memory stick. Compared to running the OS from a live CD, this would be a way to save camera settings. I imagine though there are a number of reasons why this is not suitable for the job in hand...

Yes, we have one on a 4GB USB stick. The problem is - not all the computers yet boot from the USB stick.

Andrey, how did you install the knoppix to the USB stick?

Hi Andrey have you seen that in april will be released the new version of ubuntu (Feisty Fawn project) and also in the same period april will be relesed ubuntu studio http://ubuntustudio.org/
" Ubuntu Studio. A multimedia creation derivative of Ubuntu.

Ubuntu Studio is aimed at the linux audio, video and graphic enthusiast as well as professional."

maybe we can start make a new version of the live cd starting from this distro ....it is more motion picure oriented!

Spectr (spectr) and Dmitry (d.belimov) - both at our company did that - you may email them directly. I'll ask them to post to wiki.

Yes, we are considering using Ubuntu and actually our partners in Switzerland already tried that. We are eager to donate some hardware and sponsor such development by Ubuntu community.

If you guys are still looking for a viewfinder solution you might think about going old-school.

http://www.imagehosting.com/out.php/...1_Picture4.png

http://www.imagehosting.com/out.php/...0_Picture3.png

I've loosely followed this thread and enjoyed it. Take Care, Chuck.

very interesting lens but are very expensive and you lose a lot of light with them and for this type of adapter we need as much light as we can!
if you use it directly with the camera cause the sensor is much smaller than a 16 mm film you will get a tele lens starting from a wide one
so it depend of what you want to do!

So, if this is a network camera, will it work with wireless ethernet?

WiFi connection to the camera
 

http://www.google.com/search?q=wl330g. It is ~4W, can work as a client, not only AP. Unfortunately it does not have an external antenna connector so I had to add it. And a small hack in the camera - it should be activated from the wired connection (like a simple ping to it's IP) before it will start responding to the wireless.
With dish antennas I connected over some 3km

Andrey

Andrey,

I've been thinking about the best way to utility a 333/353 camera for filmmaking using an IDE hard drive. Storing the raw data -- even compressed -- seems like a long shot.

A while back, Wayne mentioned the possibility of using 16-bit grayscale JPEG to compress each of the bayer "channels" separately, thus preserving the high-bit-depth and (hopefully) introducing very little noise.

What do you think of that idea? Would it be possible to adapt the existing JPEG FPGA code to support 16-bit grayscale?

Thanks,
Rob

I had the older 313 working over wireless to XP & the VLC player/recorder but streaming video is limited with the lower bandwidth.

More compression ideas, re-edit hdmi storage.
 

$@%%$^ Crashed during my post, 756323847 Opera.

What are people currently working on, maybe we should wait. But for now, why not test the quality of saving RAW Bayer frames as Gray scale Jpegs, no modification needed. Though scaling the red and blue pixels to equivalent green values before grey scale might improve quality a lot, they can be restored to bayer post production. These are the things we can do simply now.

Scott, that is an good idea in the longer run (but can't remember which one that was). Was it, take three separate color channels, do all the elimination stuff that Jpeg does on all values for compress green channel first, then do difference compression on the remaining color channels to the green (first scaling to green and even comparing to the average of the surrounding green (simple interpolation) preferably)? There are already people doing projects, whats are they, maybe we should wait, and do the simple grey scale experiments in the meantime. When you look at it, you could treat it like an 4:4:4 image, an full resolution interpolated green frame could be produced then RED and blue interpolated frames compressed through difference. The interpolation is already done to get Bayer to Jpeg anyway, this is an extra step.

We should not get tied up on Intra versus Intre, simple intre can give us huge gains in quality, as it allows more into the current bandwidth, which means more quality. Though what will really make an codec shine in small bandwidth, is an sensor with high Signal to noise ratio to eliminate noise, and lead to low noise in dark situations. Using an memory buffer to store the compressed frame and average out the flow, this would allow for bigger higher quality gop frames, and more space fro the gop at the start of scene changes etc. I typed this up before, but cannot remember now. The intre compression could be done between subsequent adjacent Jpeg preprocessed elimination images held in the memory buffer, to maintain even image quality. What is saved is space and the finale steps of Jpeg processing.

I have approached Andrey before about the possibility of using the main camera controller as an component and HDMI compressor storage unit, with IDE we finally have the bandwidth to do this well. I also have been in contact with tzerotech (and Analogue devices) in times past, about their UWB wireless wavelet HDMI technology as an way to record HDMI to computer, or through an direct USB version. Such an device can be ultra cheap, and hook directly to your laptop or Ultra Mobile PC, even, no brainier, saving directly to an portable hard disk enclosure. From memory, 100-200Mb/s 4:2:2 wavelet should be expected (faster is possible). Most of the work would have already been done, just an matter of interfacing USB to an reference design, and arranging the driver, if it has not been done already. The price could beat the pants off an PCIE based portable computer system, and be attachable to an camera.

Unfortunately, engineers tend to be more interested in their latest glamours projects, then these simpler faster solutions.


Thanks

Wayne.

From my own experience, the two green channels should not be combined; you would separate the four channels -- R, B, G1, G2 -- and compress each one as a separate 16-bit-deep grayscale image. No interpolation would be done at this stage; the resulting 4 mini-JPEGs would be written to disk.

Offline, you would decompress and recombine the 4 channels, resulting in a true raw image with (hopefully) just a tiny bit of noise/distortion from the JPEG compression. Then, finally, the Bayer interpolation would be done in order to end up with a high-bit-depth file such as 48-bit TIFF or OpenEXR.

Obviously, this would only work if it was possible to adapt the JPEG FPGA code to support 16-bit grayscale.

I suspected that might be the case. I think the two greens could be combined, but it might be tricky to get right mathematically, I suspect some combination where the red and blue are matched to alternative channels. The rest of my stuff is only to improve performance over the scheme you mentioned, but does not need to be done that way.

Sorry, posted before I finished.

The Jpeg compression routine might not act the same way across all four images, I think that an normalised single Gray scale image might do better. If we went the extra step to normalise the image, the existing interpolation section in the camera might handle it, by telling them to interpolate to green in an fashion that just scales the red and blue values.

Andrey has mentioned compressing the Bayer image as an gray scale Jpeg before, so I think it would be supported. Did you get an camera?

What do you think Scott?

We used compressed color images as monochrome (with Bayer processing later) in our model 323 cameras (http://elphel.cvs.sourceforge.net/el...v?view=markup). Actually we rearranged the pixels in each 16x16 macroblock to reduce high-frequency components caused by color tone - that made compression more efficient.

As for more bits per pixel - I do not see any need for it with current sensors. Micron 5MPix has about 8ke- of pixel FWC, so even with it's 12 bit output the number of the levels that can be distinguished is far less than 4096. So I believe "gamma" table (actually - optimized for noise performance table) can compress the 12bit range into 256 without sacrificing sensor data.

I think that a good quality mjpg file is more than enough ....if a jpg is a standard in digital camera why we need more than a good jpg compression for video where a picture remain only 1/24 of a second ....I prefer semplicity over big file!

I made a simple javaScript program that calculates number of bits that are needed to represent image pixels without loosing sensor data
http://www.elphel.com/actualbits.html

For simplicity, you'd be better off with a regular DV or HDV camera! :-)

But seriously, there are reasons to press for (nearly) raw images with as few compression artifacts as possible -- for example: video effects work, where reduced color space and noise will interfere with the quality of a chroma key mask.

Thanks for putting that together, Andrey, it's very instructive.

Question: How does pixel binning affect this? For example, you can configure the Micron 5MP sensor for 2x2 binning, resulting in a 1.25 MP image with less noise. How many effective bits of resolution would this image have?