If you record sound externally there should at least be a way to electronically sync audio and video so we don't have to go back and use a clap for every single recorded clip.

Adding this sync signal is most likely more work than actually recording audio and with the USB option I think it's a very flexible solution.



Here is the camera concept I promised some posts ago:

It's a very modular design which "wraps" around the basic Elphel camera case with HDD.
Still missing is the LCD, Battery Pack and I/O Panel.

What do you think so far?

very good and I do like the concept
I do have Ardour running on Linux with an RME card, no fan and dead quit.
Doing recording and film the sync would be THE solution for me
regardless the USB option, very good for interview and news,,

Here is the camera concept I promised some posts ago:

It's a very modular design which "wraps" around the basic Elphel camera case with HDD.
Still missing is the LCD, Battery Pack and I/O Panel.

What do you think so far?

It looks very good... the red circle on the back reminds me of.... hmm can't remember :)
It's only a bit different from my own ideas for the rod supports. I'll post something soon.
In your setup, where would you plan the PC to be mounted (assuming you want it to be a PC of some 'small' kind) ?

By the way, I was reading about the elphel power consumption (http://www3.elphel.com/importwiki?title=10349#Power_consumption_in_different_configurations) on the wiki, which is around 6W at full load, am I right ?

If I still remember my electronics lessons correctly, that would be around 125mA at 48v.... in which case this 12v to 48v converter should do quite nicely :
12 Volt to 48 Volt DC/DC Boost Converter (Regulator) - PC12480.8 (http://www.hyperlinktech.com/item.aspx?id=899)

That's a good suggestion Steven. I was looking for something like this. I've asked Andrey about it and he also thinks it would work fine. I'll try to find a store where I can order one in my country, otherwise I'll order the one you've posted and test it out.
Let you know when I do.

I've been testing the camogmgui (http://wiki.elphel.com/index.php?title=Camogmgui) (developed by Sebastian) last couple of days and it works great. Really great job so far!
Sebastian, I have some suggestions on how things could improve, maybe you've thought about this too..

Because we would be using a small as possible PC, possibly somthing with toughscreen like I've bought recently.. maybe we could avoid typing as much as possible by making everything (that normally would need to be filled in by hand) in drop-down menus . I'm thinking of the title for the recorded footage and folder names etc.
For instance: when you start a session, you could select from a menu the scene number (scene 1 - scene 2 - etc. etc. )and from a different menu the take number.. or better: every take could be automatically numbered (like scene-3-take002,...scene-3-take003) And you could still prompt the user to rename the file when you hit STOP.


One other important thing to make the camera much more user friendly would be to integrate the necessary parts of the camvc to the camogmgui. As I understand... you need to set the camera up (exposure framesize color setting etc.) in the camvc before going to the camogmgui. (for people who don't know what I'm talking about: camvc (http://wiki.elphel.com/index.php?title=Image:Elphel_camvc.jpg) and camogmgui (http://wiki.elphel.com/index.php?title=Camogmgui) )
Would this be possible? (maybe in frames if it makes things easier?)
We only need basic things: frame sizes (only video and film sizes I'd say) exposure - brightness or gain and color settings. Color setting can also be basic presets like: warm - cool - neutral - B/W etc. (maybe mimic some film types)
On the format tab we could use the compression quality setting.

These are just suggestions, but I think useful. I wish I could help programming though, but I'm afraid it goes beyond my knowledge (only some HTML coding). What software do you use anyway?

Onther thing: can you delete the recorded files from within the gui?

Thanks for the feedback.

Automatic naming schemes are a great idea and also easy to implement.

You could work with camogmgui and camvc in 2 browser tabs, but I agree we need an user interface that does everything needed for filmmaking in a single application.

But in my opinion a website is in general not the primary choice for a filmmaker who is used to real time previews and that sort of stuff.


I recently tested some things in Java (real time histograms from the camera) and was quite happy with the results.

Java is nice because it's working on all platforms and can be run in a browser as applet or as a standalone app.

Maybe this could be a possible way to go for a realtime remote control application (with live video, not just image reloads).

What about using USB input device channels to trigger specific events, such as image formats?

If someone were to hack a USB controller, such as multibutton mouse, so that a rotary switch were wired into the various switch circuits, we could use the mouse click on states to tell the software which mode the camera was in.

This would be a very high level modification. Other more graphical changes, such as luma and color settings, would likely need to be more dynamic, as the camera operator would need to be able to respond to the needs of the moment. Maybe a choice-based approach based on a SETUP command that let you set white and black points? I would think that we would want to leave any deep color decisions until post production.

One other important thing to make the camera much more user friendly would be to integrate the necessary parts of the camvc to the camogmgui. As I understand... you need to set the camera up (exposure framesize color setting etc.) in the camvc before going to the camogmgui. (for people who don't know what I'm talking about: camvc (http://wiki.elphel.com/index.php?title=Image:Elphel_camvc.jpg) and camogmgui (http://wiki.elphel.com/index.php?title=Camogmgui) )
Would this be possible? (maybe in frames if it makes things easier?)
We only need basic things: frame sizes (only video and film sizes I'd say) exposure - brightness or gain and color settings. Color setting can also be basic presets like: warm - cool - neutral - B/W etc. (maybe mimic some film types)
On the format tab we could use the compression quality setting.


Oscar,

I believe we'll improve/restore camvc - originally it had "DVR" capabilities with VCR like control buttons - we'll make something similar with the HDD. I spent some time recently on camvc in 8.0 software, it is now much more stable and the controls have ability to hide (screen shot shows live video through mozilla-plugin with the overlaid controls. I also made some cleanup there, split the code into more files to simplify future modifications.

Spectr is working now on improving the video streamer, including making it friendly to the camogm when used as preview tool - reduce its fps if the CPU resources needed fro continuous recording to HDD are running low. In the next plans fro the streamer - make it capable of streaming recorded files (providing timestamp-based search), so youi can watch them as on a camcorder (including FF play capability, play while recording).

http://community.elphel.com/screenshots/camvc_mplayerplugin.jpeg

The second screenshot shows development environment for the software - it is KDevelop

http://community.elphel.com/screenshots/camvc_mplayer_kdevelop_80.jpeg

Hello Everyone.

I've been redesigning my 35mm adapter. Because the size got a bit bigger than I wanted, I'd like to keep the distance between the Elphel and the projected 35mm image as small as possible, like 20 mm from the front of a small lens. This should not decrease the quality of course..

How can we choose the right lens for this purpose? The Elphel uses a 1/2.5" sensor (correct me if I'm wrong)... but not all the sensor is used. So that leaves us with 4mm (?) width sensor. Using this (http://www.laborimpex.be/lenzen.html) example, I would come up with an FL= 23mm lens. (4mm sensor x 20mm distance / 35mm image)

Am I correct on this one?
Now what options do we have in this range of (small) c-mount lenses?

My last post didn't seem to make much sense when I compare it to this (http://www.matrix-vision.com/info/calculator.php?lang=en) page.
I'd get a FL 2.41 lens (or at 30mm distance a FL 4 lens)

I also remembered this (http://www.dvinfo.net/conf/alternative-imaging-methods/104870-sumix-2-3-1920x1080-cmos-7.html#post805627) post some time ago. So we should best be looking for an affordable machine vision prime.

Oscar, I understand that that would increase the size but I would still recommend you to use a pair of lenses to translate image from the "ground glass" plane to the sensor. The one closest to the sensor is a good quality short focal length C-mount lens - you may even consider 12mm mount ones - they are small, high resolution but low power. The second lens - 35mm one turned backwards, with focal length proportionally (~ 5-6 times) longer that the one attached to the camera. That lens does not to be anything super - F-number used will be proportionally higher than that of the first lens (only center part will be used), so some simple lens with small number of components should do the job.

Such two-lens configuration is normally used when you need high quality image translation without a special lens.

Ah, now I remember you mentioned this before. I'll experiment with this tomorrow!

I've made a lot of progress lately (actually been working every day on the camera this month)
The rods support has now a mount for the netbook. This is the first step to make this whole thing portable. Tomorrow I'll post some pictures.

Here are two pics of the rods with the tablet PC mount and the 35mm adapter.
It's not a designed thing... just a rough setup.

Andrey, I've done some experimenting, but I can't really figure out what you mean with the 35mm lens turned backwards. Is there an example of this setup somewhere on the web?

Wow that's a decent piece of equipment!

How exactly does the new 35mm adapter work compared to the old microwax static groundglass one?

Sebastian, the 35mm adapter is adapted from a photo-enlarger. It has a focusing mechanism on the side like a follow focus. Much too imprecise to be really usable, but I can easily put some gears in between the original and a new focusing knob to make it work like a FF.

....The one closest to the sensor is a good quality short focal length C-mount lens - you may even consider 12mm mount ones -

Does anyone have experience with the quality of machine vision lenses? How about this one? (http://www.pentaxcctvus.com/explore/lens_details.asp?ID=20)

Oscar, I meant M12 lenses like these:
Miniature CCD/CMOS lens for 1/2" or larger format imager (http://www.optics-online.com/dsl_half.asp)
1/2” Megapixel Fixed Lenses (http://www.videologyinc.com/lenses/megapixel-lenses.htm)
TECHSPEC Megapixel Finite Conjugate µ-Video Imaging Lenses - Edmund Optics (http://www.edmundoptics.com/onlinecatalog/displayproduct.cfm?productID=2660)

or just

http://www.google.com/search?q=M12+megapixel+1%2F2"+lens

Hi everyone,

For those who don't know; the camogm2 camera software can record audio ( see wiki (http://wiki.elphel.com/index.php?title=Camogm#Camogm2) )

One audio USB device I came across that I'm considering to buy is this USB Dual Pre. (http://www.tascam.de/art/en/artcess/preamp/usbdualpre.html)

It doesn't need additional drivers and I've read that it runs perfectly on Linux. It has direct monitoring headphone output and two XLR mic inputs with phantom power option.

Any thoughts?

Tascam US-122 is a classic, very good quality for the value.
I personally own the next model, the US-122L which is very nice & 24bits/96Khz but with poor drivers, and definitely no linux drivers :/ (Hope ? (http://www.pps.jussieu.fr/~smimram/tascam/))

You should look for Class Audio Usb device as they are part of the usb standard and as such, supported by linux.

Digigram UAX220Mic professional USB Audio interface for broadcast and other demanding pro audio applications featuring 2/2 balanced analog high-quality I/Os (http://www.floridamusicco.com/proddetail~prod~digigram_uax220_mic_VB173100201.htm)
please take a look, maybe a bit $$$$ but it works smooth with Linux.
I 'm digging for a cheaper alternative, there should be one
maybe even a kit

Ha found it in the disk nirvana on my Linux companion

Waoooooh
have a look, that looks cool, and is what we need
small and idiot proof in the field
no drivers no hassle
Plug XLR Mics Direct to USB - Kompoz.com (http://www.kompoz.com/compose-collaborate/p-Plug_XLR_Mics_Direct_to_USB/storyId-941/view.story.blog)

enjoy and good recording

ah and maybe the best one
BEHRINGER: UCA202 (http://www.behringer.com/EN/Products/UCA202.aspx)
has A/D has SPDIF out, works with audacity, should be fine with Linux
a firewire version is also available

I'll receive the ART dual pre next week. I've chosen this one because it's exactly what we need (and not more than we need): a mic pre amp with phantom power and direct monitoring output. It's a lot like the Tascam US-122, but smaller.
Of course it doesn't really matter what it looks like, but I think it would integrate very nice on the camera. Could be made detachable when you're using a sound operator.

I'll let you people know when I have it and if it works as good on linux as I've read.

Small update:

I've finished a follow focus system for the 35mm adapter. The follow focus moves the whole lens mount, so you don't need to change anything (accept focus marks) when you change a lens. You can also change the whole lens mount (thanks to Sebastian's idea for the Elphel lens mount)
You can see the (big) gear sticking out underneath the focus knob. That was necessary to get subtle focus adjustments. One whole turn is a little more than the whole focus range. (sorry for the bad photos)

EDIT: I noticed Sebastian's notes on the wiki (http://wiki.elphel.com/index.php?title=App_bar) Great idea!

once again, i want to say "nice work" oscar (and others).
I wish I could contribute more, but you guys have taken this discussion well out of my league. I understand enough to be impressed.
Thanks for innovating.
Daniel

Elphel camera under the hood: from Verilog to PHP (http://linuxdevices.com/articles/AT4187053130.html)

Sebastian mentioned working on a preset manager for the Elphel control software (camvc)
I've got a suggestion to integrate the camvc into the live preview window of the camogmgui ( see the wiki (http://wiki.elphel.com/index.php?title=Camogmgui) )

Using D-SLR camera's a lot, I've come to the conclusion that: although you can set white balance manually, most of the times you just end up using one of the presets.
Symbols like a sun, clouds, light bulb etc.
I think when it comes to the Elphel camera interface, such symbols would be sufficient and preferable in real situations.

I've attached a quick example of how I think the interface could look like. Other suggestions are welcome ...unless Sebastian turns pale right now :) ... it's his software after all.

With the color temerpature calculation we got quite a thing started.
I am afraid the math is not that simple:
Planckian locus - Wikipedia, the free encyclopedia (http://en.wikipedia.org/wiki/Planckian_locus)

Konstantin Kim helped simplifying this a lot, see attachment:
the T:= Matrix holds the target color temperatures and the following two matrices the R and B coefficients for a 5500°K initial color temperature.

So all we need now is the inital color temperature that the image has when coming directly from the sensor.

Andrey suggested to film a known color temperature image and see how the coefficients after autowhitebalance behave to calculate the resulting initial color temperature.

Maybe we will soon solve this mystery :)


Between I released a new version of the harddisk recording tool camogmgui: Camogmgui - ElphelWiki (http://wiki.elphel.com/index.php?title=Camogmgui)

It now supports simple creation of film like Naming schemes with fields for Scene, Shot, Take, etc.

Sebastian, for calibration using the automatic white balance in the camera you should use some white object. Do you know how that automatic balance works?

This balancing assumes that the most bright object in the frame has white color. So it cuts a little on the color histograms. Both fraction of the pixels above the level and the absolute pixel level can be specified in the parameters - if the number of pixels for the brightest color above specified level is smaller than specified, the level is reduced until the number of pixels condition is met.

After finding level/fraction pair for the "brightest" color component same number of pixels is cut from the right side (high level) of the histograms for the other color components, and the corresponding levels are measured. Then the gains in the channels are changed accordingly to equalize those "white" levels. The current 8.0 software allows additionally to add tint so the "white" object in the frame will have predefined color different from white (camvc allows that using control sliders).

When adjusting gains in the color channels two mechanisms are used (there are user parameters that can impose additional limits). First the analog gain settings of the sensor are used (analog gain is often considered as "ISO" in the digital cameras). But those gain stops are rather far apart (sensor we use has 12.5% steps in some gain range and 25% in the other) so camera uses digital scaling (17 bit multiplication) to "fill" those (12.5-25%) gain gaps. By default the camera uses "theoretical" analog gain values for each gain setting, but it can use a table of measured values so it is possible to write a script that will change analog gain (and simultaneously digital scaling and/or exposure) to calibrate each analog gain actual value.

I will try to get a color temperature meter to make this calibration a real calibration instead of just assuming temperature from a certain light source.

I made a calibration test shot today.

Konstantin please use these values to calculate the original temperature:

T = 2810°K

R = 148106 / 65536 = 2,259918212890625

G = 131072 / 65536 = 2

B = 288552 / 65536 = 4,4029541015625

What do we do with the GAINGB in this scenario?

I made a calibration test shot today.

What do we do with the GAINGB in this scenario?

There is no high-level (in camvc) support for it yet, I just tried everywhere (in the drivers, autoexposure/white balance daemon) to make it possible to use for "jp4hdr" mode (high gain while GAING, GAINR and GAINB are at lower end). So in normal mode GAINGB==GAING, in jp4hdr GAINGB should be 8..15.75 independent of the other 3 gains

Hi everyone.

I'm really impressed of the quality of this project. I myself, being an indie filmmaker I'll like to make the move and try to build my own digital film camera with DOF hability, but I think that right now building it from the elphel (if you don't have the technicals skills required) it's out of my reach.

But anyway, just checking this footage from the 333 model, with a 35mm dof adapter looks fantastic (apart the artifacts at the edges):
http://community.elphel.com/videos/RomainFULL.avi

Maybe it's an idiot question that has already been rised here, but, it's not possible to have film DOF on this chips without the dof adapter?

What's the entry level minimal cost right now to build such a setup?

What could be the quality of the image that we can get compared to other cameras? RED, scarlett, hvx + 35mm adapter, etc...

Regards.

Maybe it's an idiot question that has already been rised here, but, it's not possible to have film DOF on this chips without the dof adapter?

Right now, it's not possible to have film DOF without the adapter. Because DOF is directly related to the size of the film/sensor. The sensor on the Elphel is 1/2". Using a 35mm lens without the adapter would simply project a 35mm image on a 1/2" screen, making it a huge telephoto lens.
So the only alternative is a bigger sensor. That's something of the future, although they already exist of course (Red, Canon 5D mrkII, Nikon D90 etc.)
We would have to wait for the costs to come down for such sensors... or we have to order a large quantity to get the price down.

EDIT: Interesting sensors are noted here (http://wiki.elphel.com/index.php?title=CCD_table#Useful_CCD_sensors)
The Dynamax35 is by far the most promising so far.

What's the entry level minimal cost right now to build such a setup?

What could be the quality of the image that we can get compared to other cameras? RED, scarlett, hvx + 35mm adapter, etc...

I guess the costs for the camera are on the Elphel website. You would need a controller PC or mobile device that runs Linux and has an ethernet connection. A cheap EEPC would do, but still a bit big perhaps. But note that everything is still under development.

I don't know yet how the image is compared to other cameras. I'd like to see a test like this with the Elphel one day : Zacuto's Great Camera Shootout! 2008 | Indy Mogul - DIY filmmaking (http://www.indymogul.com/post/10769/zacutos-great-camera-shootout-2008)

Right now, it's not possible to have film DOF without the adapter. Because DOF is directly related to the size of the film/sensor. The sensor on the Elphel is 1/2". Using a 35mm lens without the adapter would simply project a 35mm image on a 1/2" screen, making it a huge telephoto lens.
So the only alternative is a bigger sensor. That's something of the future, although they already exist of course (Red, Canon 5D mrkII, Nikon D90 etc.)
We would have to wait for the costs to come down for such sensors... or we have to order a large quantity to get the price down.

EDIT: Interesting sensors are noted here (http://wiki.elphel.com/index.php?title=CCD_table#Useful_CCD_sensors)
The Dynamax35 is by far the most promising so far.

I understand about the sensor size, thanks a lot for the info. The best alternative should be that elphel use in the future one of those larger sensors. The Dynamax35 looks really great but I guess it's really expensive. Having these sensor into a working elphel system, and a DNG output format seems like a perfect setup.

I guess the costs for the camera are on the Elphel website. You would need a controller PC or mobile device that runs Linux and has an ethernet connection. A cheap EEPC would do, but still a bit big perhaps. But note that everything is still under development.

I've checked their price. A whole system should be around 1000$. Then you need a controller PC and a DOF adapter if you want that kind of look.

I don't know yet how the image is compared to other cameras. I'd like to see a test like this with the Elphel one day : Zacuto's Great Camera Shootout! 2008 | Indy Mogul - DIY filmmaking (http://www.indymogul.com/post/10769/zacutos-great-camera-shootout-2008)

This shootout is great, it let you see what the different setup looks side by side.

Is there any possibility in a not so distant future of having a more or less simple camera head, maybe Gigabit ethernet, with Internal Dirac Pro (adapted to RAW bayer) compression and some kind of control protocol?

Yes, we do plan both. GigE will come first (and USB2, faster CPU and FPGA) - that project is under development right now. After hardware upgrade Dirac is likely too.

Seeing the time frames for this kind of development, I'd rather suggest going directly for USB3, by that time it would be more or less common (1 year ahead I guess).

Anyway if you think I can help just send me an email.I would be glad to receive it :D

OK, here is a new approach to the 35mm adapter + Elphel camera + PC

If you take a look at the camera parts (http://wiki.elphel.com/index.php?title=Image:10353-10369-assy_blowup.jpeg), there is a flexible connection between the sensor board and the main board. This makes it easy to put the camera body at a 45° angle to the sensor/lens.

I'm working on rod support now... I'll post some stuff later.
All comments are welcome.

Here is a better explained image with a basic rod support setup. I haven't figured out how to mount the camera and PC yet. Tripod support would be somewhere in the middle.

Wow, this look great. I've tried to search this conversation to see what PC are you going to plug into this, and what software are you using to control the camera, sorry if you've already post this, but could you please give some details?

Hi Ivan,

It's just a simple 7" tablet-PC version of a netbook. Every EEPC that runs on Ubuntu/Linux is also suitable, but the tablet and touchscreen function on this netbook is pretty desirable.
I have a French version ( WeSurf (http://www.wedigital.fr/index.php?page=fiche_produit&produit=we_surf) ) of the Clevo (http://www.clevo.com.tw/en/products/prodinfo.asp?productid=164) running on Ubuntu.

Come to think of it.... this PC has also a Portrait / Landscape function, that auto-rotates the monitor image 90°.
It'll probably save more space when I put the laptop on it's side. I'll try it in the 3d model.

UPDATE: Added rod support and PC in "portrait position"
All comments welcome again... :)

Wow, great progress Oscar.

I think 4 rods are definitely the way to go as you can easily attach microphones, etc on the top rods.

Would it be possible with your setup to also shoot from the shoulder and have the laptop mounted at a side?

It's just a simple 7" tablet-PC version of a netbook. Every EEPC that runs on Ubuntu/Linux is also suitable, but the tablet and touchscreen function on this netbook is pretty desirable.
I have a French version ( WeSurf (http://www.wedigital.fr/index.php?page=fiche_produit&produit=we_surf) ) of the Clevo (http://www.clevo.com.tw/en/products/prodinfo.asp?productid=164) running on Ubuntu.

Thanks a lot for the info.

But according to DP advises, when shooting in HD and using a 35mm adapter, focus is really critical. I wonder if the max resolution of your touchscreen (800x480) is enough for that or it'll be better to have a higher resolution screen (720p or something).

About your rod support it looks great but I'm looking for your 3d model for a typical shoulder mount position...

I don't think that a full resolution monitor is required to judge the image (sharpness).

Sony (and maybe others as well) does something called "peaking" to visualize image areas that are in perfect focus.

This basically looks like colored lines around sharp objects:
http://scubavideo.de/wp-content/uploads/2008/09/peaking_on.jpg

This is done with image areas of high frequency information. Luckily this frequency information is available inside Elphel cameras as it is a byproduct of mjpeg compression. Now we just need to overlay this on a live image somehow.

Sony (and maybe others as well) does something called "peaking" to visualize image areas that are in perfect focus.
...
This is done with image areas of high frequency information. Luckily this frequency information is available inside Elphel cameras as it is a byproduct of mjpeg compression. Now we just need to overlay this on a live image somehow.

This is the way to go. Those EEEPC's are relatively slow and real time preview is not yet evident on a slow PC. So we will possibly end up framing on a small (but live) image on the PC and focusing with the "peaking" method. That's why I'm going with the PC on its side now.

About your rod support it looks great but I'm looking for your 3d model for a typical shoulder mount position...

I think we should take this step by step. Right now, the camera has a rolling shutter artifact that makes handheld shooting difficult. I'm not saying it's impossible though, but I'd think about a steadycam setup more than a shoulder mount.

But I'll look at the dimensions in the 3d model and see where the shoulder mount should be. Probably still behind the PC, so we don't need to put the PC on the side (which would makes it hard to balance)

what about migrating to a Spartan-6 architecture with a soft core, microblaze or the like?

Spartan 6, yes, but in the current camera the CPU is a bottleneck. So upgrading FPGA will need upgrading CPU also. So I want it to be much faster than softcore and have all of the peripherals I need too.

That's the idea, using the Spartan to receive and send the image data, bypassing the CPU as much as possible, leaving the softcore (microblaze or better yet some open source one) to manage the strictly necessary, like passing settings to the CMOS sensor, etc,etc.

Updated the wiki: HD cinema camera Development FAQ - ElphelWiki (http://wiki.elphel.com/index.php?title=HD_cinema_camera_Development_FAQ#Designs_for_rod_support)

I started working on the cameras screen interface concept.

The nice thing is that this does not require any additional hardware, just some webprogramming and will run directly inside fullscreen firefox.


Here is how other folks do it:

http://www.hdforindies.com/uploaded_images/SiliconDVR_Interface_Main-782743.jpg
http://provideocoalition.com/images/uploads/DSC_0639.jpg
http://www.thehighwaymanmovie.com/img/redmonitor1850.jpg

Detailed plans how I want to technically approach this:
-) the main video window is running gecko media player (a firefox plugin that embedds mplayer)
-) the interface around it are 4 java applets (good for realtime drawing)


VLC could also be used for the video window (cross platform compatible) but so far I was not able to overlay anything on top of a VLC video and I was not able to turn off caching in VLC which results in a short delay in the live video stream.


The concept for the layout implies that you (the camera operator) use your right hand to move the tripod handle and your left hand to operate the touchscreen. Thats why the controls are on the left handside of the screen.


Now please find me more images of other manufacturers screen designs and give feedback!

This is really starting to look 'ideal' Sebastian!
I hope a slower PC can stream real time/full screen... what do you think?
One note: The design I'm making now uses the tablet PC on it's side (portrait) Would your interface be auto-scalable when you have a low res screen? Maybe it's an idea to have the HDD file browser bellow the controls, so you see them when you use a PC in portrait mode.
Tomorrow I'll make an example of what I mean.

Great work!