This is really impressive...
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Apr 30 2017
Apr 27 2017
Apr 20 2017
Apr 13 2017
Apr 11 2017
Apr 10 2017
It's very confusing to me why people tread on eggshells where copyright is concerned in this area. The Greek alphabet is removed from copyright restrictions in the same way that letters of the alphabet are. 'Slide to unlock' is a patent, letters can't be patented.
Apr 8 2017
I'm not keen on quite a few of the fonts, tbh. They fall into novelty genre (Republika, Omikron, Oloron, Enahnced Dot Digtal).
Great, thanks!
Apr 6 2017
OLPF section added to wiki: https://wiki.apertus.org/index.php/AXIOM_Beta/AXIOM_Beta_Hardware#Optical_Low-pass_Filter_.28OLPF.29
Apr 5 2017
Apr 2 2017
Four day poll on OLPF demand - https://twitter.com/apertususer/status/848584997388812289
Mar 29 2017
It is unlikely that the lens system manufacturers will disclose the information about their lenses, but of course, it is worth a try contacting and asking them.
I figured out that camera lenses are using 16bit addressing system and SPI protocol. We need to send and retrieve 16bit data from lenses. And then we need to decode that data stream to human readable. Unfortunately, the data that can be sent and retrieve to lenses is different for every model of the same lens manufacturer. Camera manufacturers include all the information(focus length, aperture range) in their firmware through camera lens ID code. Either we need to get data stream information and observe that by oscilloscope and function generator and translate that to lens information but we've to perform that for every lens model on the planet or else we can ask the camera manufacturers about their own SPI system (what bytes for what).
Every manufacturer has different protocol for their lenses.
Clarify me whether the communication system between cameras( of different manufacturers) and lens is same or do we need to implement different communication protocols for different camera manufacturers? Do all lens systems from various manufacturers follow same communication protocol to their cameras?
Mar 28 2017
Sebastian, if there's need at some point in time then i can translate the article natively, if machine translation is not clear enough.
Is it something like this (http://www.ixbt.com/digimage/canonautosonyl.shtml) that you want to implement ??
Hi,
Is it something like this (http://www.ixbt.com/digimage/canonautosonyl.shtml) that you want to implement ??
Mar 24 2017
Mar 23 2017
Mar 22 2017
The test footage looks amazing.
Mar 10 2017
True, and we could make them ours (have them designed to deviate away from the standard)... In the above image [edited] I just went for the standards.
You've got to realise I've been through about 10,000 fonts at this point, that's getting exhausting and not much seems to work. As a result I keep coming back to the symbol.
You've got to realise I've been through about 10,000 fonts at this point, that's getting exhausting and not much seems to work. As a result I keep coming back to the symbol. As per:
https://fonts.google.com/ has a pretty good selection.
As I went into in chat, two sets of all caps (Line and marque) both with wide spacing. All caps AXIOM we can get away with but ideally you want the sub-category being small case and preferably with a capital B. All caps on both is too off-putting for the subconscious. It might look ok to begin with but I question its staying power.
Mar 8 2017
Yeah, there's something about it that's not right. Things in the CI can be changed surely.
Please elaborate what you find off. Sure we can change the CI but only with good reason, after all we had a pro graphics designer draft this up.
Yeah, there's something about it that's not right. Things in the CI can be changed surely.
We need a new flyer to print very soon and the logo should be on it.
Mar 7 2017
Mar 3 2017
Mar 1 2017
I'd want to know if we're sticking with 'AXIOM' as it stands
The current AXIOM logo is established and approved, no changes.
Very constructive comment RexOr!
Feb 28 2017
Sony would struggle to get apertus on the Greek alphabet. Copyright typically has a shelf-life of 70 years and there are stipulations set-up in the legal world that prevent people from copyrighting base characters. Legality takes into account the circumstantial in a case like this - so for instance if we had a red alpha symbol in italics (followed by corresponding numbers certainly) there'd be room for claim. To my knowledge Sony has only ever produced an Alpha. We produced an Alpha but it's discontinued. The Sony Alpha was introduced in June 2006... before the Axiom... However, had the AXIOM Alpha been brainstormed prior to 2006? I don't know. That would all be about proving what's on paper.
In T744#10885, @sebastian wrote:So my vote would be for simple/clean/elegant/robust.
In T744#10882, @MichaelH wrote:Im not sure but somebody alerdy mentioned in the IRC that we could possibly have some trouble using greek alphabet. We would do basicaly the same like Sony with their "Alpha".
To the Font question: maybe it would better to decide about our target group First. Do we want something elegant, something "geeky", something clean and simple? What does transport the message of Axiom best? I think this is the main question we should answer first.
In T744#10883, @BAndiT1983 wrote:I've mentioned it, because of Sony. Their cameras are marked wit Alpha, not sure if other letters are used too.
http://static.trustedreviews.com/94/00002ab06/e416_orh400w630/alpha-a5000.jpg
I've mentioned it, because of Sony. Their cameras are marked wit Alpha, not sure if other letters are used too.
Im not sure but somebody alerdy mentioned in the IRC that we could possibly have some trouble using greek alphabet. We would do basicaly the same like Sony with their "Alpha".
Is this task a potential duplicate from T741?
We could do away with text all together and employ the Greek alphabet symbol?
"I am not convinced we need this grip bevel element here."
Feb 27 2017
Well I think Thunderbolt is too proprietary. I didn't knew this previously. If there is an open source design that I can find I can probably inform this thread to everyone. What about DisplayPort to send digital signal? SDI (3G-6G and 12G) is obvious. Do we need it? I think.
Feb 23 2017
Feb 20 2017
Feb 9 2017
Jan 22 2017
Dec 2 2016
Oct 30 2016
Oct 27 2016
Why not. After all, the IMU is currently 'solder-on' so we can try different ones without changing the entire design.
With a little trick (connecting the solder-on boards with small pins) they can also be easily swapped.
All that is required is a tiny PCB with the proper connections.
What about this guy?
Other candidates are:
What is the price?
I'm not sure of what the desirable specifications are for an IMU, but the invensense mpu9250 is pretty easy to use and rather inexpensive. It has a sample rate of up to 32kHz.
Oct 10 2016
Maybe this is the right time and place to suggest NixOS.
It is not used primarily in embedded devices and is also not very enduser friendly right now, but has some advantages like atomic updates (what would help here to easily roll back updates) and declarative configuration.
It is build around the Nix package manager, that can be also used on other Linux distributions and even OS X (theoretically also on Windows, but no one is working on that). They are working on reprodicible builds.
The community is very active and helpful! I use NixOS on most servers at home.
You can find my OS configurations here: https://github.com/davidak/nixos-config
Oct 9 2016
Do you have any open source stacks/designs for handling thunderbolt?
If so, please share with us.
The problem is simple:
- we have 12 LVDS lanes with up the 1.5Gbit of encoded data (officially 1.0Gbit per lane).
- SATA requires 3+ Gbit to be useful, i.e. we would need MGTs to handle that.
- UHS-II can be done with a cheap FPGA
Didn't know that BM decided to make the PCC FOSS/OH ...
We need to record metadata anyway, for example to keep information about exposure time, sensor register settings, etc.
If we decide to do it in a separate file/stream then we need very precise timestamps (or frame numbers) to go with.
Well actually a low priced camera like BMPCC can record 1080p RAW at 30fps which is budget and good enough.
GoPro is a good example. However, 4K at 120 fps, will need a really big amount of money to be able to make an interface fast enough to write to an M.2 SSD, and a fast enough CPU to take the input and store it as RAW file. About $3000 MFT camera like DJI Zenmuse X5R can record in Lossless RAW 4K at max 2.4 Gbps, but it is not open source and for professional use, it would not perform really well in low-light.
Well, an acceleromter info for a camera is a great idea, actually. But the problem is how can it be included in the metadata? Should it be stored in an another format like .aclmif (Accelerometer Info) which contains a very precise tracking of the accelerometer over time. You should include timecode info too so you can parse the information of the accelerometer over time. And the program which can render .aclmif is only Open Cine, with Premiere Pro adding support in 2021? Well but it is not a wrong idea to add a new format and it should not be in this section - it should be in the software section.
What I think is that it would not be practical if we use UHS-II cards because this device is mainly for video production and RAW recording. So if you use a RAID Array of a bunch of UHS-II cards you can get what you want, namely RAW recording enabled. The problem is that a bunch of UHS-II cards would not be practical because you need to bring a bunch of SD Card Reader and hubs to be able to read all the data. If you provide UHS-II cards their price is more than $1/GB now, so it would not be practical for use because SATA SSDs are cheaper and faster, with larger size. With 1 UHS-II card, however, you can record in ProRes 4K or maybe Cineform, I haven't checked for Cineform.
Well what I think is that cooling a camera is not easy. And we need a super conductive material (e.g. Diamond, which does not conduct electricity very well but conducts heat at best, or silver which is cheaper, which conducts both electricity (electric charge) at best and heat really well (2nd place). So really, aluminium is the cheapest option. But we need something cold so we can conduct the heat out of the camera. So I think we should have some sort of heat spreader in which is directly from the CPU, and the heat is conducted out with water, like water cooling so it will definitely evaporate some water and the heat is lost by the water, which is not a good idea, because it is just inefficient. We need to be able to spread the heat, but the handle and the base of the camera and all the buttons of course should not be hot because the camera user will click on them, and the LCDs should not be hot too. So we should be able to spread the heat fast enough that the camera itself is cool enough.
Oct 5 2016
indeed very interesting!
Oct 3 2016
good to hear some news :)
Oct 1 2016
Hi we had speak about to make our own customized handle
Jun 8 2016
May 22 2016
And I think we all agree that its important to clearly version releases and label everything accordingly so any release can be tracked/reproduced.
With rsync we can just have a "latest" repo plus repos with increasing version numbers in case anyone wants to try a specific version or downgrade to test/compare something.
All our plugin modules have an EEPROM on the I2C bus.
Recent Power Boards feature en EEPROM on the I2C bus as well.
The Main Board can be uniquely identified via PICs and MachXO2s.
The fact that the task is sitting there for a year now means that probably nobody is interested enough to work on it.
As you are very interested, maybe you could start working on the conversion.
We now think we know how UHS-II works and where the challenges are.
No hardware tests have been concluded so far because we still need to write software to utilize UHS-II.
I'd be interested to know how you went with UHS-II stuff?
On the topic of firmware management, as you have multiple different images parts and versions, it is really important that you embed as much version information into each part as possible.
I'm very interested in getting a KiCad version of your HDMI beta module. Maybe you could start with attempting to do that?
You might want to take a look at http://libcec.pulse-eight.com/
May 21 2016
Actually (nitpicking here :) the IMU doesn't record the motion, it tracks it with several sensors.
May 20 2016
The IMU just records the motion of the camera (3D rotation, acceleration, etc.) what you do with that kind of information then in post production is up to the user/software.
So i don't understand exactly how it work for the IMU data recording in the beta.
You can take data from IMU and use it directly in postprod for a better stabilization ?
May 15 2016
Specifically test/enable CEC and HPD as well as DDC
there is another one application: realtime track could be very useful for green screen previsualisation of live human in 3d environment or the other side with real environment and vfx character like the troll in lord of the ring (this was made with motioncapture system but today it's sould be possible to do this with camera motion tracking)
For camera stabilisation it could be very cool somebody make an extension card to drive directly the brushless motor.
Maybe information to easily find optical center and find the offset between IMU and optical center could be usefull too