jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26833
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Thu May 09, 2013 7:46 pm

Hardware_man wrote:First positive thing that I have heard!

Hardware_man
Except what Gordon said is pretty much what I've been saying from the start of the thread....but with added interns to do the job.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

Hardware_man
Posts: 94
Joined: Tue Dec 04, 2012 6:28 pm
Contact: Website

Re: Camera Interface Specs

Fri May 10, 2013 12:33 pm

All along you have been saying that there is nobody to do the job. The information necessary to to the job is proprietary so no one on the outside can do the job and any body who has access to the necessary information is too busy to do the job.

Gordon said he will have summer interns who possibly could do it.

This is different to what you have been saying from the beginning.

Hardware_man

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26833
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Fri May 10, 2013 1:28 pm

Hardware_man wrote:All along you have been saying that there is nobody to do the job. The information necessary to to the job is proprietary so no one on the outside can do the job and any body who has access to the necessary information is too busy to do the job.

Gordon said he will have summer interns who possibly could do it.

This is different to what you have been saying from the beginning.

Hardware_man
So the difference is that now there may be people who can take on the job - as I said. It's always been bout manpower (and skill set). Although I am personally doubtful whether the job is as simple as Gordon makes out...!
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

dtic
Posts: 9
Joined: Fri May 10, 2013 7:45 pm

Re: Camera Interface Specs

Fri May 10, 2013 7:59 pm

Hi, the camera module might prove useful for DIY book scanning of the kind investigated at http://diybookscanner.org and other places. Currently many such setups use Canon point and shoot cameras with the custom CHDK firmware.

Could someone with access to a camera module please do this quick test: Take one maximum resolution photo of a text page in any book. Do it from a distance of around around 40 centimeters from the page, in a very well lit area and with the camera module stabilized (on a tripod or taped to something or...). Then post a link to the page. Thanks!

rainer fritz
Posts: 5
Joined: Sat May 25, 2013 2:47 pm

Re: Camera Interface Specs

Sat May 25, 2013 7:18 pm

Didn't wrote the hole thread, but I'm also very interested in video applications on the raspi. A DVR sounds awsome. So probably this guys can help you, because they built ASI and SDI interface boards as encoder boards and so on:
http://sr-systems.de/content.php?show=P ... &style=std

Don't know if it helps, but this guys doing for long time such video work...

best,
Rainer

gkreidl
Posts: 6347
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

Re: Camera Interface Specs

Sat May 25, 2013 10:44 pm

dtic wrote:Hi, the camera module might prove useful for DIY book scanning of the kind investigated at http://diybookscanner.org and other places. Currently many such setups use Canon point and shoot cameras with the custom CHDK firmware.

Could someone with access to a camera module please do this quick test: Take one maximum resolution photo of a text page in any book. Do it from a distance of around around 40 centimeters from the page, in a very well lit area and with the camera module stabilized (on a tripod or taped to something or...). Then post a link to the page. Thanks!
I'm planning to use it for a book scanner (if the quality ist good enough, at least after applying some further procdessing), but I won't have a camera before August. But one thing is already sure: you need an additional near lens in front of the camera; there's a whole thread discussing the details.
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

dtic
Posts: 9
Joined: Fri May 10, 2013 7:45 pm

Re: Camera Interface Specs

Sun May 26, 2013 1:10 pm

gkreidl wrote:I'm planning to use it for a book scanner (if the quality ist good enough, at least after applying some further procdessing), but I won't have a camera before August. But one thing is already sure: you need an additional near lens in front of the camera; there's a whole thread discussing the details.
I now have a raspi and the camera module. I have tried various settings but so far has found no mode that gives photos feasible for book scanning. I even removed the glue (like MEEP did) and fiddled with manual focus changes. Here is a cropped output sample, taken from ~40 cm distance.
raspi.png
raspi.png (15.74 KiB) Viewed 4900 times

gkreidl
Posts: 6347
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

Re: Camera Interface Specs

Sun May 26, 2013 1:48 pm

Well, I cannot really say much before I've got a camera myself. But:

1) Your original image is not sharp. "Fiddling around" with the lens may not be sufficient. I'll definitely try a near lens to get sharper images from near distance.

2) I'm not sure, what you did with scantailor, but it made the image even worse. Try different settings. But without a good image fed into it your results won't be usable.

Did you install the latest camera software that really gives you the full sensor resolution?
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

dtic
Posts: 9
Joined: Fri May 10, 2013 7:45 pm

Re: Camera Interface Specs

Sun May 26, 2013 2:47 pm

1) the image is the sharpest I got from manual tweaking of the focus. The original fixed focus gave me worse results. The image is from before latest firmware update (using rpi-update). I found it tricky to get rid of all the glue (maybe a sewing pin isn't the optimal operating tool? :lol:). The lens is still a bit hard to move. That means I have to dismount and disable the camera for each small manual focus adjustment.
I just spent some time getting the cam back into the default "eternity focus" and don't have more time today to test manual focus settings after the firmware update.

2) Scan Tailor among other things binarizes the images as a pre process before pdf/djvu creation and OCR. Changing settings won't help given the bad input image.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26833
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Sun May 26, 2013 3:05 pm

Did you try setting the sharpness to maximum? Not great for photo's but might make text easier to scan.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

gkreidl
Posts: 6347
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

Re: Camera Interface Specs

Sun May 26, 2013 3:25 pm

dtic wrote: 2) Scan Tailor among other things binarizes the images as a pre process before pdf/djvu creation and OCR. Changing settings won't help given the bad input image.
You don't have to binarize the image (you can use gray scale/color), but if you do so, you can adapt "thickness". It's also a good idea to double the resolution when binarizing it.

The sharpest possible image that the cheap lens can provide has to be used (I'll go for a near lens in front of it), and then a lot of things can be tried to get better results - good light, setting contrast/brightness (a gradation curve would be better but I won't ask James for it) and there also seems to be a kind of sharpening effect ...
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

dtic
Posts: 9
Joined: Fri May 10, 2013 7:45 pm

Re: Camera Interface Specs

Sun May 26, 2013 7:39 pm

gkreidl wrote:You don't have to binarize the image (you can use gray scale/color), but if you do so, you can adapt "thickness". It's also a good idea to double the resolution when binarizing it.
I am quite familiar with the Scan Tailor settings. Outputting grayscale/color, and so on, does not improve the output with this kind of input file when your end target is a pdf/djvu with an OCR text layer.
Last edited by dtic on Sun May 26, 2013 7:46 pm, edited 3 times in total.

dtic
Posts: 9
Joined: Fri May 10, 2013 7:45 pm

Re: Camera Interface Specs

Sun May 26, 2013 7:45 pm

jamesh wrote:Did you try setting the sharpness to maximum? Not great for photo's but might make text easier to scan.
I tried that in fixed focus mode and it didn't help IIRC. But I haven't tested that in combination with a manual focus change yet though.

Hardware_man
Posts: 94
Joined: Tue Dec 04, 2012 6:28 pm
Contact: Website

Re: Camera Interface Specs

Wed May 29, 2013 2:27 pm

If it turns out that the Pi camera is not a good camera for book page scanning, then this would be another application for a universal video input. Then someone could choose a camera that is optimized for book page scanning and use the Pi for compression.

Just like today’s home page article that people are using the Pi in applications that no one even considered. I would think that people would use a universal video input for applications that no one even considered.

Hardware_man

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26833
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Wed May 29, 2013 2:33 pm

Hardware_man wrote:If it turns out that the Pi camera is not a good camera for book page scanning, then this would be another application for a universal video input. Then someone could choose a camera that is optimized for book page scanning and use the Pi for compression.

Just like today’s home page article that people are using the Pi in applications that no one even considered. I would think that people would use a universal video input for applications that no one even considered.

Hardware_man
Not sure anyone has said it's a bad idea, just time and manpower - just like everything else!

Although the camera should be fine for book scanning - probably just needs some tweaking.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

AlexKordic
Posts: 9
Joined: Sun Jun 02, 2013 12:46 am

Re: Camera Interface Specs

Sun Jun 02, 2013 7:16 am

gsh wrote:Interesting that I haven't heard about this conversation since if anyone is the right person to ask its me!

Anyway concerning HDMI -> CSI

So there is the possibility of doing this, but it'll have to take a back seat behind and number of other projects. Of course it would be a very useful project for one of our summer interns and I might keep it in mind for then.

As to handling the software etc. Actually that's rather easy, I just get BRCM to add the CSI hardware to the 2835 peripheral spec (which isn't difficult at all) and then leave it up to a couple of interns to handle the software.

Will keep it in my notes for suitable intern projects

Gordon (Raspberry Pi - Director of Engineering)
Hi Gordon,

Can I apply for that intern position ?

Best Regards,
Alex

davidoccam
Posts: 6
Joined: Mon Aug 27, 2012 5:53 pm

Re: Camera Interface Specs

Sun Jun 09, 2013 6:13 pm

scenario

Davidoccam: methinks Andreas speaks much sense, as does Hardware_man ( or CAN-DO man as I call him)!
in the background Gordon (Raspberry Pi - Director of Engineering) wants to help but it is mightily complex.
The red-herring of HDMI and HDCP is raised. Nobody wants it anyway as it is a poisoned chalice.
The other poisoned chalice of USB also raised its ugly head,

Hardware_man: I want to use the Pi board to run a high profile H.264 encoder to get data rates down to the write speed of the SD card for a high end DVR implementation.
I am a hardware engineer. I already expected to have to do an "adapter" board. The Sony outputs HD digital on 4 7 bit LVDS channels. I noticed the camera connector only brings two I think LVDS data inputs and an LVDS clock input out. And I expect impossible to tack solder wires onto the Broadcom chip as the BGA pins are probably buried deep under the chip.
So I would do an adapter board to convert the Sony LVDS to parallel and then convert again to two LVDS channels and a clock LVDS channel to drive the camera connector.
But I would need to know stuff like data format, MSB first or LSB first, number of bits for LVDS channel, clock speed etc.
But I don’t know much about writing drivers. I guess this would be a “generic” driver as it would be for a camera that is already “tuned”
Now, If I used the analog high definition component video from the Sony and put a 3 channel video A/D converter on my adaptor board, this would then become a much more “universal” design as any high definition “tuned” camera that had analog component video out could just “plug and play” without regard to exact data formats of the camera’s digital output.

If I agree to give this adapter board schematic to the foundation, then would the foundation argee to writing the universal driver?
He offers to make a board that will look EXACTLY like the chosen camera ( which has no HDMI and no 'main issue is HDMI in that it needs all sorts of nasty DRM' and has nothing to do with HDMI or HDCP- red herring).
He writes,
Dear Pi Foundation,

I’ll go back to my earlier proposal, except with a CSI-2 output.

I design the circuit and lay out a PCB to take analog component video in and output CSI-2. I will “sweeten” the deal: I will give the Foundation both the schematic and Gerber files. I’ll even throw in the BOM. The Foundation is free to do what ever they want with this, keep it proprietary, manufacture it, and / or post it all.

In exchange, the foundation will provide the firmware and / or software to take this “through” to the H.264 encoder and the software to use this as a DVR recording to the SD card. Again, the Foundation may keep this proprietary or include it in your normal firmware distribution.

What do you think?

Davidoccam: I think you speak much sense, and I think Andreas agrees with me, He has a good suggestion which I will try to paraphrase..

If Hardware_man created a FPGA or a hardware board that emulated exactly the important necessary and sufficient parts of the EXISTING PROPOSED CAMERA, then NO DRIVER MODIFICATIONS AT ALL would be required. A path into the GPU would exactly follow the existing paths. Expensive Driver man who is so busy (and Broadcom ), would have to do nothing.
I think Hardware_man could be told enough about the now redundant camera control niceties that his FPGA would give all the right answers to the driver that EXISTING PROPOSED CAMERA would give.

Thus a path exists. Politics is the art of the possible.

If I were at sea in a naval analogy , in a fierce battle in a fierce gale and this HAD to be done. I would want Hardware_man and Andreas on the ship with me repairing the camera system.
Gordon meanwhile, back in the Admiralty, issues the order to signal the requisite interface details to the ship immediately and forgets about possible interns and huge bills and complex politico-legal barnacles on the ship of progress.

The Camera is jury-rigged and the now all-seeing ship fights it's way home.
Crowds line the docks in Portsmouth cheering. yay!

DavidOccam Portsmouth UK.

Hardware_man
Posts: 94
Joined: Tue Dec 04, 2012 6:28 pm
Contact: Website

Re: Camera Interface Specs

Sun Jun 09, 2013 6:36 pm

I thank you for the vote of confidence. But this is a little like going around the block to get across the street. I would basically be taking an already “tuned” video source and intentionally detuning it exactly right so that it behaved like the unturned output of the foundation camera just so the already existing driver could tune it again back to “flat” just to save writing a new driver. CRAZY! :shock: I wasn’t planning on doing an FPGA to include video tuning capability. This would be a much bigger project than what I had offered.

Hardware_man
www.linkedin.com/pub/martin-risso/71/599/a09

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26833
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Sun Jun 09, 2013 7:49 pm

As I think I've said before, what is really needed is a HDMI to CSI-2 convertor chip - Toshiba? - and a custom driver for it on the GPU. Much the easiest way of doing it. BUT, the custom code on the GPU would need to be done by the Foundation or Broadcom (probably Broadcom as they are the ones with all the knowledge).

I don; think it would be particular feasible to build an adapter that mimicked the current camera module since there is other stuff apart from the driver that needs to be written (for example, with a camera you tell it what resolution you want - with HDMI the input defines the resolution)- unless you can mimic EXACTLY - and that would be difficult indeed.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

davidoccam
Posts: 6
Joined: Mon Aug 27, 2012 5:53 pm

Re: Camera Interface Specs

Sun Jun 09, 2013 9:07 pm

Andreas said

"If modding the driver is out of the question due to time constraints, would it still be possible for us to pay you to write a bare-bones documentation of the wire protocol used when video is being transmitted in some well-chosen video resolution?"

That is, as I understand it, to chose an arbitrary but "well chosen" fixed set of inputs from a statically defined "hypothetical camera" that form a "frame packet stream" of "raw " video data into the processes of the Graphics Processing Unit. This stream would be one of the tested modes of the existing driver. No other information would have to be disclosed. No extraneous "tuning" data is required. just how to get the stream in.
The very mention of H.D.M.I . is introducing a can of worms, or a biscuit full of weevils, but there is no reason that 1920 X 1080 should not be the size of the fixed frame of the hypothetical camera.

The purpose of the interface is to allow users own raw video data to be processed. It has nothing to do with Consumer Electronics association / Electronics Industries Alliance at all. It is a scientific educational aid, not an item of consumer entertainment. it specifically does not have anything to do with Enhanced Display Data Channel (E-DDC),

From time immemorial, the only way to stop further vendor "lock-in" is to reverse engineer or to emulate simple sub-optimal published interfaces. This is the only way to break the impasse. It should also educate people into the blocks corporations place on entry to their "closed shop".

I await the appearance of these blocks with interest.

davidoccam

All words used have their normal meaning in the English language and are not references to any technical specification or to be interpreted

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26833
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Mon Jun 10, 2013 9:10 am

davidoccam wrote:Andreas said

"If modding the driver is out of the question due to time constraints, would it still be possible for us to pay you to write a bare-bones documentation of the wire protocol used when video is being transmitted in some well-chosen video resolution?"

That is, as I understand it, to chose an arbitrary but "well chosen" fixed set of inputs from a statically defined "hypothetical camera" that form a "frame packet stream" of "raw " video data into the processes of the Graphics Processing Unit. This stream would be one of the tested modes of the existing driver. No other information would have to be disclosed. No extraneous "tuning" data is required. just how to get the stream in.
The very mention of H.D.M.I . is introducing a can of worms, or a biscuit full of weevils, but there is no reason that 1920 X 1080 should not be the size of the fixed frame of the hypothetical camera.

The purpose of the interface is to allow users own raw video data to be processed. It has nothing to do with Consumer Electronics association / Electronics Industries Alliance at all. It is a scientific educational aid, not an item of consumer entertainment. it specifically does not have anything to do with Enhanced Display Data Channel (E-DDC),

From time immemorial, the only way to stop further vendor "lock-in" is to reverse engineer or to emulate simple sub-optimal published interfaces. This is the only way to break the impasse. It should also educate people into the blocks corporations place on entry to their "closed shop".

I await the appearance of these blocks with interest.

davidoccam

All words used have their normal meaning in the English language and are not references to any technical specification or to be interpreted
Sorry, not sure what you are getting at. As you say, all words are in English, just not in an order I understand.

The original purpose of this thread from time immemorial was to investigate the possibility of HDMI in to the Raspi as this seems to be of interest to quite a few people.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

davidoccam
Posts: 6
Joined: Mon Aug 27, 2012 5:53 pm

Re: Camera Interface Specs

Mon Jun 10, 2013 1:13 pm

Sorry, not sure what you are getting at. As you say, all words are in English, just not in an order I understand.

yes, "I'm playing all the right notes—but not necessarily in the right order."
see http://www.youtube.com/watch?v=-zHBN45fbo8 to be sure what I am getting at Mr.Preview!
The original purpose of this thread from time immemorial was to investigate the possibility of HDMI in to the Raspi as this seems to be of interest to quite a few people.
The acronym HDMI is first introduced by jamesh » Thu Dec 06, 2012 9:45 pm in the 13'th post in this thread.
The First 12 posts do not mention it and it is factually not the "subject" of this thread.
Subject of thread is "Camera Interface Specs"

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26833
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Mon Jun 10, 2013 2:11 pm

davidoccam wrote:
Sorry, not sure what you are getting at. As you say, all words are in English, just not in an order I understand.

yes, "I'm playing all the right notes—but not necessarily in the right order."
see http://www.youtube.com/watch?v=-zHBN45fbo8 to be sure what I am getting at Mr.Preview!
The original purpose of this thread from time immemorial was to investigate the possibility of HDMI in to the Raspi as this seems to be of interest to quite a few people.
The acronym HDMI is first introduced by jamesh » Thu Dec 06, 2012 9:45 pm in the 13'th post in this thread.
The First 12 posts do not mention it and it is factually not the "subject" of this thread.
Subject of thread is "Camera Interface Specs"
hardware_man, the original poster, wanted a mechanism of getting video in to the device via the CSI-port. That's only really possible with HDMI in. Hence the thread being mostly about HDMI in.

But if you want to talk about something else, feel free. But your post will indeed need to make it clear what you are talking about, which I haven't yet got from previous epistles.

(I don't need the YouTube link - I saw the original. With great age comes great wisdom, or at least, great hairstyles)
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

Hardware_man
Posts: 94
Joined: Tue Dec 04, 2012 6:28 pm
Contact: Website

Re: Camera Interface Specs

Mon Jun 10, 2013 3:41 pm

The only reason I made reference to HDMI is to find a standard HD video interface that most people could use. Like the old days of SD video, you could plug most video source devices into most video destination devices using composite video on an RCA connector. Great quality, no. Anything works with anything, usually. You could get better quality video using newer SD video interfaces like analog component, S-Video, etc. But if your source device (say a DVD player) and your destination device (say a TV with auxiliary in) didn’t support the same higher quality interface, composite video on an RCA connector almost always worked.

So I referenced HDMI looking for the new HD “standard” interface. I also referenced analog component as another possibility. But not all modern HD source devices provide analog component outputs. But they usually do provide HDMI outputs.

For the first revision, it wouldn’t be “the end of the world” if you had to configure the Pi with some terminal program to specify resolution, FPS etc. Then, later the Foundation could write the code to get this information from the HDMI and automatically configure the Pi.

Hardware_man
www.linkedin.com/pub/martin-risso/71/599/a09

User avatar
rkinch
Posts: 72
Joined: Sun Jun 02, 2013 7:19 am
Location: Palm Beach County, Florida USA
Contact: Website

Re: Camera Interface Specs

Tue Jun 11, 2013 6:24 am

jamesh wrote:That's only really possible with HDMI in.
But HDMI-in itself is not possible. That's why there are never HDMI inputs on video recorders.

Return to “Camera board”