When manually booting with bootm 0x3000000 - 0x2A00000 it boots up to a certain point where it simply resets.

Sorry for the delay, I was busy with Xmas.

Could be useful - but equally tricky to programme I would have thought since the camera has to work out where that is. I suppose, once you have peaking working okay (ie highlighting of high contrast pixels) you tell it to jump to work out a general centre for those areas.

Indeed, in addition to having image stabilization, having data for camera tracking sounds awesome; huge!

How about an option that makes the magnification preview automatically appear in the center of where the focus is? This might be specifically useful when focusing on people/people's face/people's eyes because it's very annoying to have to move the focus preview through buttons(like on Canon EOS cameras) when you're on a situation that you have to catch focus fast.
Just an idea that popped up in my head right now.

It would be greatly appreciated if someone could take a peak if the following image will work on a vanilla MicroZed.

@sebastian: maybe, it would for sure put a certain load on the memory controller (limited resource) and probably reading every 8th pixel would also give a very strange preview while not really reducing the memory load that much (access is 64-128bit).

@sebastian: maybe, it would for sure put a certain load on the memory controller (limited resource) and probably reading every 8th pixel would also give a very strange preview while not really reducing the memory load that much (access is 64-128bit).

This feature came from me with the idea of using the Axiom with Dragonframe stop motion software.

the entire raw image is already present in memory

Would a viable path to generate this real-time preview be that a software/driver running on the ARM core reads pixel data just from every 8th pixel address and wraps it into a new image/device? Then no FPGA processing would be required at all and the load on the CPU is also minimal as no image resampling/processing is required.

Note that this should happen at a specific stage that allows to have a separate magnified version sent to one output, and the normal (not zoomed) version sent to another.

@philippej: if you check the image pipeline the AXIOM Alpha uses, you will see that the entire raw image is already present in memory so it can be accessed from the arm cores. It is very likely that the "normal" operation will be similar on the Beta.

A 512x288 image is insufficient for ensuring correct focus, especially at 4K - in my opinion. I'd also say that line skipping or scaling seems like a lot of extra processor work to me. I was thinking that having a simple black and white image would be the easiest solution: simple conversion of the raw pixel values straight to luma data.

I think Sebastian meant pixel skip. (every 4 line, every 4 column or something like that)

I have asked Sven if we could directly migrate to the Elphel bootloader code, he was investigating it. But I haven't heard from him, so I contacted him on Sunday about it. Obviously I can upgrade the existing image to something like a 2GB partition and go with that, but I was hoping for "more".

skipping pixels (keep 1, skip 7 in my example) should be a very resource friendly way of scaling down no?

Low resolution means scaling the high resolution version down.
This is a very expensive (resource wise) and power hungry task.
Compressing the data with e.g. JPEG or similar is also very intensive.
While doable, I'm not sure we actually want that for the Beta.

Any news on this?

Another huge wish for the future: an entry level model with a cheaper sensor and a lower price tag.

Your suggestion is a new idea/wish and would deserve its own lab task! I am very curious to learn how many folks would be interested in cheaper entry level option.

That's great to hear! Another huge wish for the future: an entry level model with a cheaper sensor and a lower price tag.

We are planning to put 3D magnetometer and 3D gyroscope sensors (9DOF-IMU e.g. for image stabilization) directly behind/next to the sensor. Great to see this is something people care about!

Ok, enough information. I'll make an all in one image.

Forgot to mention, behaviour is the same on the 7020 MicroZed.

something strange is going on.

My suggestion was to take the ArchLinux ZedBoard image, and add our bootpart for the 7010 board. I guess given I see a kernel booting. We don't have any problems with the 7020 :-)

I presume I should put a rootfs on partition 2, yes?

after adjusting the uImage to uImage.bin, this gives:

fatload mmc 0 0x3000000 uImage
fatload mmc 0 0x2A00000 devicetree.dtb
setenv bootargs console=ttyPS0,115200n8 root=/dev/mmcblk0p2 rw rootdelay=2 init=/usr/lib/systemd/systemd
bootm 0x3000000 - 0x2A00000

After a long search for a _working_ SD card reader/writer (I have now three non working adapters) I'm now finally ready to do some testing.

gave him commit access and reminded him to make the commit.

Thanks for all the info, I think its definitely interesting but far too early to actually start working on anything, moved to wishlist.

freeing this task to invite other people to participate here as well

Reassigning to Herbert for testing:
http://stefan.konink.de/contrib/apertus/

will test on the 7020 MicroZed ASAP.

yes.

A working boot image (SD card and TFTP) would be very useful in the near future (let's say 1-2 weeks).

@Bertl Do you have a 7020?

@edits, this is exactly the kind of contribution we are after, so no worries :-)

Avid was very slow in implementing its 4k version of DNXHD, and whilst ProRes has gained a lot of support it is as proprietory as DNXHD (or Cineform for that matter).

Comment from Marcus Meissner (mastermind of gphoto) on gphoto-devel group:

If "The Avid source code found on {Avid} website is for End User use only. This is not intended for commercial use or distribution."
Could a End User embed it by him self, when compiling the firmware from the source code?

Welcome Laszlo, we are glad to get your support!

Hello, I'm new here. By a request from Sebastian Pichelhofer, this is the copy of my last email:

I think gphoto(2) support might be interesting, although it seems to me that it is pretty much Linux only (which isn't a problem for me at all).

There has to be a protocol for setting camera parameters from outside the camera (dictator, mobile phone...).
Is there already a protocol implemented? ptp / gphoto could be an option for this...
Every (supported) parameter of a digital camera can be read/set with this protocol.
The picture transfer itself is the not so important part.

from gphoto.org / en.wikipedia.org/wiki/GPhoto

can you explain a bit what such support could mean and what gphoto does exactly?

The initial framework is done: http://files.apertus.org/controller-simulator/

Color LCD with resolution in the 320x240 pixel range around 2-3" diameter. Touchscreen optional (maybe enabled later on)

Other side of the problem :

I don't want to run java(script) on the governator.

If you want to run java(script) on the Governator, then you need to plan for more CPU resources, more power, etc.
Doable but not sure it is worth the efford. I.e. it might be simpler/better to use an existing embedded system with
LCD for this (e.g. a Raspberry PI or similar)

If we can find ways how to avoid duplicating the code I am all for it.

If we decide to use the PIC32MZ for the "Governator", we might be better off to extend an existing simulator to cover the hardware (LCD, Button) and avoid duplicating the code.

Can't we simply give him the necessary commit rights and let him commit the latest version himself?

no rush here.

Feel free to assign yourself this task to speed things up, since currently time is precious, and very limited for everyone :-)