Hi Adam

Not sure if this is correct place to post but the new Nikon Astro camera looks interesting, what are the chances of being able to set up the Axion gamma to emulate this type of photography: Nikon’s Newly Announced D810A DSLR is The Camera For Astrophotographers.

This might be the ultimate solution : https://github.com/mofarrell/p2pvc
:-)

at the moment "the Real machine" comes in shape that's for me most important. there are a lot of work to do hardware and software side. when that is done we can go one step forward and build the fantastic camera.

The MOX is open source open format and I know Brendan Knows about the Axiom and I think Sebastian et al have been in contact with him about maybe using it. As I understand it, however, MOX is essentially a flexible wrapper - it could be used as a production format, you just need to include an (open source) compression codec in the wrapper.

Hello,
First let me apologize for joining this conversation this late. For starters, my opinion is that working with 3 HDMIs shouldn't be an option. Cables are not solid for long distances, connections even golden ones are not secure, and transferring that amount of data would be a real headache. I've worked as DATA manager and DIT in several production in Spain and Mexico, and SDI is the most reliable cable you can get at the moment. I know it requires implement soft and hard, but in my opinion, 3 HDMIs sounds scary.

@allan
You have right, a Mini-ITX PC is very heavy and makes some noise, if it has fans.

We are in touch with Christophe and just purchased this board from him.

Answer from Christophe

His name is Christophe Carpentier and he has one available for 200USD. Go on the page http://opencores.org/acc,view,chipmaker78. His email address is there.
I gave him the address of the apertus web site and I and investigating how get the board.

Nice! Please investigate how we can get our hands on such a board for testing (in exchange for 200 USD of course).

I found ton opencores.org a project of a PCIe board with Sata connector. (http://opencores.org/project,spartan6_pcie).
External interfaces are not the correct one but the developer seems open to discussion. Board cost 200USD (got feedback from developer)

Obviously no compression is the easiest to manage in camera in terms of processing required (i.e. none) but further down the image pipeline no compression becomes a problem.

Staying within the realms that make for what the axiom beta is, i dont think the recorder solution should be too heavy or loud to handle along with it.

And please someone care to explain what kind of benefits, "No compression image" gives compared to say, lossless compression to half the size.

Yes the size and all the problems caused by the size. Transcoding times, the power of the machines for DI. Cost goes upwards.
I dint mean apertus should use RC ofcourse. Compatibility with the softwares will not be a problem in long run, everything eventually catches up.
\

What's the problem with the BM 4k camera format? The big size? Or not supported by the program? I think the implemented file format should be open, free, and widely supported, compressed or not. The Redcode format is not usable here, it's protected by patents etc. and if you implement an own format, it won't be compatible with the existing softwares...

The no compression solution breaks my heart as well. In a recent shoot, we had to shoot with a Black magic 4k camera (despite my initial choice being red scarlet/one-mx, producers went for BM 4k due to cheap rental prices) . BM 4k data is nightmare to manage, the post production costs multifolded. This made us take a decision to go with my initial choice, a Red scarlet after a schedule.

Compression doesn't really help the lossless path, as you have to plan for the worst case, which is no compression at all.

Fair enough. I was just raising the question as to whether or not own form of lossless compression could be implemented - even if it requires significant post processing to unpack the data afterwards.

@sebastian
Yes, it is also a possible solution. It is very similar to the idea of this HD-PLEX case with passive cooling, maybe he customized it.
For me the layout isn't good, it's too flat.

As usual, the question of using lossy or lossless compression will split the community into (at least) two groups :)

I thought of 2 ways of doing things without reinventing the wheel:

My contribution and I hope I haven’t missed the point.

I am not sure its possible to combine the two use cases:
-) recording footage
-) editing footage (workstation)
together without them contradicting themselves.

Off-topic for Mini-ITX but...

And if at all possible, bypass the need for a "conventional" (x86) cpu and find a way to provide filesystem and sata protocol support from an fpga / arm system for lower power consumption. Pipe dream ?

I will stay on topic.
But I think that if you compare it with the Odyssey and Atomos Shogun, your solution cannot be compared to those soltutions
Shogun :196mm x 110mm x 47mm and 645g 6.8W-11W
Odyssey : 200mmx155mmx25mm, 560g 8W

This was my topic starting post:
"I have an idea about to build a portable Mini-ITX multifunctional PC, which could get the big amount of RAW data from the Beta, store it on HDD + maybe it could work as a system which could process/encode the files and as a workstation too.

I like the idea but I have a lot of questions and remarks.

Hi Surami,

RAW recording means RAW, so there isn't any compression, debayering, etc. just get directly the RAW data from the sensor and save it. It is very good from the point of dataamount, because there isn't any information about the color of the pixels. Let's count:

From a practical sense it's rather irrelevant that the compression is lossy. Obviously the ideal would be lossless compression but what is needed is some for of compression that is achievable in real time (no mean feat when dealing with 4K footage, especially at rates above 30fps) and makes file sizes manageable. 4K Raw or Uncompressed (which is actually worse than Raw) is a horrendous amount of data to deal with.

@colinelves: The wavelet compression is lossy and slow to decompress at the computer side. I think even Red using it as a compromise.

My preference would definitely be for SDI - HDMI connectors are so unreliable and you need a solid connection if you're going to be dealing with that much data.

The EQCO62X20 chipset is a driver/equalizer chipset that forms a bidirectional, full-duplex communication link over a single coax cable. It is designed to transport up to 6.25 Gbps over the downlink channel and to transport 21 Mbps over the uplink channel.

Potential cooperation with inviso who consider to open up their framegrabber design and create an AXIOM Beta SDI Shield.

Just for reference, there's also Livestream:
http://new.livestream.com/
http://new.livestream.com/platform/pricing

In this case, what can I add ;-)

For the EC2 setup I have a specialist at hand and it will take him no time to configure everything and prepare a ready-to-roll linux-image for us. He is very much looking forward to help us.

I'm not sure setting it all ourselves is not overkill (or too time consuming).

The simple camera variant
Start with single Logitech HD Pro Webcam C920 at first. Add more cameras over time if we see its necessary.
Question of audio video delay from webcam needs to be tested.

We will develop a custom PCIe card and if that doesn't work a PCI card to take the input signals from the Beta. No details before we actually tested anything.

I think there is no easy solution for this yet. But perhaps within a few years, there will be a fast and widely used interface. Probably the real time full 4k is not so important, it is hard to process on PC anyway. For exampe, in stop motion animation, you need only a good live preview until you capture the frame you want.

The basic idea so far is to have a metal plate covering the entire sensor PCB (front side), pressing against the sensor base (thermal connection) similar to the heat sinks used for CPUs.

Yes, we stumbled upon the inogeni converter several months ago, we even planned to get one back then but it never happened.

i think i should mention this product http://www.dexteralabs.com/inogeni/

This at some point should become a project on apertus.org, the wiki, and the lab.

I had in mind axiom <-> arduino, but it could also be used with accessories.

This can be grouped in with the Open Source Arduino Follow Focus, motor controlled auto focus using various methods, one of which included a manual calibration method of calibrating a manual focus lens or unknown lens.

i have used a Sony EX3 with Fujinon zoom optics which has autofocus and electric zoom. to that was 2 controllers attached, left and right on the handles of a sachtler tripod.

Hm, just trying to understand. Would that be for connectivity between the Axiom and the Arduino?

Sounds like a valuable addition to offer as an add-on to the external chassi of the camera. For normal use-cases the less complex passive solution favours something that doesnt add cost/weight/power use.

It might be interesting to explore the various options we have for connectivity to those accessories. Low bandwidth, simple bus could be considered.

This is possible, can this be merged with the OSArduino FF? It was a part of expanded design in the project.

Love the idea!

tested hitbox.tv today

laser triangulation, ir or ultrasonic distance measurement combined with a servo or microstepper attached to a follow focus (example http://www.philipbloom.net/wp-content/uploads/2009/06/microff_v2_15mm_lg1.jpg ) to adjust the lens focus according to distance. different lenses might need different adjustments.

Already planned, Herbert please be so kind and add a short development progress comment.

This idea needs refinement in its definition.