UPDATE: Prototype and website
 

Time to show the first -rough- prototype of the APERTUS based on this design
This is of course based on my own DIY microwax 35mm adapter, but it should be pretty universal. Besides 35mm adapters, it can also be used for bigger c-mount TV lenses if needed. I'll post some tests with different setups in the future.

There is still some work to do on this prototype before I can test it.

Another thing we forgot to announce here is the new APERTUS website:
Home page | Apertus Open Source Cinema
It's in the early stages, undergoing a theme change, so it's a bit off here and there. Thanks to Philippe Jadin for setting this thing up!

I thought my current 35mm wax adapter looks too bulky.
So I decided to adapt a macro bellow for 35mm cameras for the wax adapter. The focus mechanism (although not very subtle) can be used as follow focus.
I also want to try to integrate a sort of relay lens into the adapter.
I've discussed this with Andrey Filippov, he suggested: "A trick we did (that was to transfer 1:1) - take 2 identical lenses and put them face-to-face.
In your case you need ~1:5 transfer, so you need the second lens 5x the focal length.
I.e C-mount with f=8mm and a 35-mm with f=40 mm"

I've done a quick test and it seems to be working! Anyone got more input on this?

hi oscar cool work
seem exaclty as the render
one question about your test how does it manage the light loss and the spherical aberration
did you need also a condenser/aspherical-condenser between the 5x lens reversed and the GG?

Matteo, the wax screen is sandwiched between two condensers.
The light loss on my waxscreen is about 1 stop I guess but it depends a lot on the lenses (also the c-mount) I have to test this (and the spherical aberration) further.

In the future I want to test different 35mm adapters on the APERTUS.

hey what do you guys think of this: if the camara gets more light by pixel binning, then why not make two processes, first the normal image ("un-binned") you get a "low luminosity" image and save it, then the pixel-binning processed image "high luminosity", and compare the burned parts of the "high" image to the "low"

obiously both "low" and "high" should be extracted form the same raw frame (to make sure that both images come form the same original stream and have the same exact features minus the exposure diference)

wouldn't this gave more dynamic range to the final image? maybe the camera can't do this in a workable framewrate, but this could be a begginning, no? what do you think?


------------------

i have to admit, i love Apertus! how is wobble effect in the elphel?

@Biel
I think that something is in development
JP4 HDR - ElphelWiki

and also in hardware:
info from the aptina data sheet
Pixel dynamic range 70.1dB (full resolution),
76dB (2 x 2 binning)

Matteo i've seen this, but my idea isn't exactly this, the idea is to use the same info coming form the ccd before any pixel binning is done, the idea is to use the original image and the "pixel-binned" one and merge them to get a little nit more of dynamic range (only if by pixel-binning on gets more light, otherwise this porcess would be futile)

anyway if this porcess is not futile and also the Process Matteo said one could get an awesome dynamic range gain from the same camera, what do you guys think?

Interesting idea.

In theory it should be possible to gather higher dynamic range data with this.

But I see some potential trouble:

-) As you mentioned this will not be possible at full fps. Changing binning mode will require at least one if not multiple frames to execute.

-) Binning is a CMOS on-chip feature rather than a post-processing step so it is not possible to get the data "before" it happens. You can only take 2 shots one after the other, one with binning on (2x2 for example) and one without binning.

Binning does not only mean more dynamic range but also more light sensitivity. 4 pixels are brighter than one.

Even if it is not possible to do it at a usable FPS it would be interesting to do it as a proof of concept no?so when chips get more fast it will be prooven no?

is there a way to get the info from the chip in order to pixel-bin, but do it as a post process? like getting the image from a non-pixel-binned process and pixel-bin it when its not al already done, i mean do a porcess in post (than means after the chip has got the image (not "post-pro")) from a non-pixel-binned iimage:


lens - chip - stream data - pixel-binning - stream data + pixel-binning - raw enconding - file

here pixel-binning and the operation joining the two diferent streams would be a postprocess before the raw encoding of the file
instead of:

lens - chip - pixel-binning - stream data - raw encoding - file

or does pixel.binning actually means that the chip uses 16 photosites instead of the normal 4 for a final pixel? if that is pixel binning then maybe its not possible...

Exactly that is binning!

Instead of a single photosite the sensor can add up the charges of blocks of 2x2, 3x3, 4x4, 5x5, etc. photosites.

Anything regarding resolution reduction after the sensor is "resizing".

well then...
damit i loved that idea because it's simplicty! :(

Hi Biel,

I don't know if it's really impossible, but I guess it's not simple. Anyway, we where just talking about the Elphel's FPGA features, here's part of the discussion:

Over a year ago Andrey wrote: "For the viewfinder mode it will be
rather easy to make FPGA to provide 1/8 (or even 1/16) resolution (so
1/64 or 1/256 number of pixels) of uncompressed data in parallel to
the video, virtually without using additional resources (so not
slowing down the recording)."

"Anyone know if this still true?
....is this also one of the goals for the Elphel Vision interface?
... the 7" tablet PC has a lot of trouble with the high resolution stream. I don't think it'll ever show real time HD video.
A horrible blocky image is even preferred if it's real time above a beautiful HD image that is one second behind.
Especially if we have the focus aid.

(Oscar)

"...apparently this has never been implemented. But as I also recently
learned is the FPGA only filled 40%. That means there are plenty of
resources. If we find someone who is a skilled verilog developer it
might be possible to have the feature added.
....After all I also think its the only way to enable us using something
like the beagleboard as viewfinder."
(Sebastian)

Regards,

Oscar

i don't get it Oscar, what are you triying to say? does resizing have the same benefit of the pixel-binning? can luminosity (ore even chroma component) of 16 pixels combine and form a brighter (and maybe a more color-correct) 4 pixels?

and then combine that image with another resized (16 to 4 without the post-pixelbinning process)

and get a similar latitude as the process i wanted to do?

Very first alpha version of ElphelVision Java Applet is ready!

This is still in a very rough and early condition but it should work and maybe already be kinda useful.

It lets you view the video live stream, shows camera infos and record video files to camera internal HDD.

Detailed instructions on how to setup and use are included as README.txt
Currently only works under windows.
Final version should be platform independent as long as your platform can run Java and has an mplayer build.


Please let me know if it worked, how it worked, etc.

http://community.elphel.com/Apertus/...on_Alpha01.zip

hey Sebastian, that's good news! I'll try to test it right now, or first ting tomorrow (just came back from a trip to Holland) No problem it's only Windows, I just installed Windows 7 (test version) on the tablet PC. I guess using Windows for the end user makes it a lot more attractive for lots of people.

Sorry if I'm confusing things :-) I'm not a programmer, but I was trying to follow your idea: I thought it might be relevant to mention that we were talking about two 'streams' parallel.