Did you recieve any special discounts? Because the $2.000 I heard earlier would be roughly 1.270 Euros...

Gottfried, The discounts given to Jose and Daniel reflect the true value of the product, as the product is new and there is risks of unknown bugs. We are sold out for now and we can not extent this extra discount to others

When will the cam be back in Stock and what will be the price of it?

According to Farhad, in a week they'll receive new sensors and cameras will be ready to ship within 5-8 weeks.

I supose the price will be the same as always, that is $2,000 for filmmakers.

Gottfried, Price Will be the same. We try to be consistent. It will be first places order first served with priority going to our existing customers and distributors.

Gottfried, Price Will be the same. We try to be consistent. It will be first places order first served with priority going to our existing customers and distributors.

Good morning
so many good news amazing.

I'm still favoring my poor but reliable staedicam approach.
India is no low tech anymore, changing the buckles
and some padding Voila.

PC vice , hm, there are dead quiet CPU ventilations, heat pipes
and this stuff. Solid state disks are still not cheap,
but neither horrible expensive.
Think of 16 mm reals. Think of the last Aaton.
A beauty, but i do have swapping all 20 minutes,
and the processing ruins my bank account.

Swapping the Solid disks all 20 minutes around
and pumping them into a
Laptop on steroids is no rocket science at all.

There are some glitches, I'm sure Sumix will help us to navigate around.

My Aaton is best in a staedicam set up,
quite portable, battery pack, optics, rails, Filters Compendium
monitor out, decent screen will turn you Robocop like,
for the on shoulder version, trust in me.



to blow the trumpet
I'm the same in some kind
Intersexuell,
new passport and files, New look,
rebuild,
the brains
are not changing radically.
Still film making, maybe different approach,,
not so Robokop like, LOL

Have fun

Some screencaps from what I shot today with my mobile prototype.

The focus may be off and motion blur would also be a problem in thies shots. The lens is SD, can't see anything on the lcd outside(glare), and shooting things at near macro/telephoto violently shaking in the wind.

Shot at F/5.6 - F/8 with the camera at 50Mhz. Maximum exposure, 0 gain.
http://www.dreamstonestudios.com/per...imgs/April-06/
(70% compressed jpg)

Did some post on one of the images:
http://www.dreamstonestudios.com/per...ME_58-POST.jpg

(41 is shot indoors, ~50w tungsten light, no white balance. 36Mhz, max exposure, max gain)

Ok, so it looks like we need a Core2Quad miniPC to record CineformHD using streampix. That's going to make everything a bit harder... and more expensive.

I sent this in an email but it may be of benefit to others. A quad core pc should cost more than a pc with an expensive mobile processor. A T7200 is $300 and a much faster Q6600 is $234


I think they can be put together without spending too much.

Quad core mini-itx motherboard $350
http://www.portwell.com/products/det...HAR1=WADE-8656

Core 2 Quad Q6600 quad core processor $234
http://www.newegg.com/Product/Produc...82E16819115018

Quad core cpu cooler $29
http://www.newegg.com/Product/Produc...82E16835114074

4GB 800 DDR2 memory $79.99
http://www.newegg.com/Product/Produc...82E16820231122

Total: $693

+ $150 for a mini-itx case (~$80) and the rest for a power supply.

Are there any hardware solutions available for encoding CineForm?

I notice that CineForm was working on a mock-up of DTD recorder, that got me wondering if there are any companies out there that have built (or are building) a device to encode to CineForm, perhaps in the form of a PCIe card.

CineForm DTD mock-up: http://www.cineform.com/products/CineFormRecorder.htm

Just for clarification... Daniel, are you able to record video to your current setup using the Sumix software (but not StreamPix/CineForm)?

Yes it works perfect. CPU is only under 50% load to preview/record. But too slow for realtime CineForm.

You have to have a quad core. The links and specs I posted above should meet requirements.

One, only one stupid remark
vented in the Ephel thread a million time..fois
Linux all Debian types, knoppix, dynebolic even Ubuntu
you can configure dammed small, dammed fast.
XP or Vista is a monster, eating on idle
too much ......good morning.

I do have no idea guys
but a Red or SI, specially the SI
are already portable for the real world.

Real work is on scene, outside etc.
Crying loud, Indie Film is no
studio with a power station
or a cam with a generator in a van.

It has to be quick and dirty that is
our power and imagination
and the low budget dictates
how to work.

This can be a fantastic
force to drive imagination
as we have no bank, financing and
smart controllers. We are not mind controlled.

Blowing the trumpet for some
Steadicam version even with
the India clone and some TLC
I do, as I do know, it is fast
reliable and with somebody
for the sound, maybe a third person
carrying all stuff needed, lenses, laptop, cell phone, script, etc
you are the smallest real world production unit.

A blown up van with a quiet generator and a tethered
cam may work for reportage. One guy does it with a
1 million van and a viper cam in the States.

It is no Drama in any sense of the word.
have fun

I didn't think a quad core was required, im sure that in my past conversations with cineform the spec for recording a single stream was a lot less, perhaps a duo. I don't know what SI is using, they would know for sure.

Maybe there are some other bottlenecks in the system?

I believe that the best way to do it is to store log 10 bit or 12 bit and turn the camera into something that just dumps data fast. You can still encode to cineform afterwards if that's your workflow or even something else. Keeping the camera doing the least amount as possible seemed to me to be the best bet. Especially if the cpu will be needed for view finder tasks. I would think getting it to preview and focus with the minimum delay would take precedence over live encoding, the dumping of data is a bandwidth issue not a CPU one.

A hardware based solution would be neat though, but i think they're all based on recording HD-SDI or HDMI. This is not RAW and so the cameras would be debayering on board which is back to square one...

There is development work to do between the cineform RAW encoder and the specific sensor to get the best out. I believe this is an area that SI have spent a lot of time refining and it's the area that streampix is important. Each sensors characteristics need to be taken into account by the RAW encoder to get the best out of it. (Please correct me if im wrong, these are based on conversations with cineform a while ago and things do change...)

cheers
paul

Strange, when I was talking to Farhad some time ago, I told him exactly the same about why not using a 10 bit log LUT inside the camera, and letting the user load his own LUT if required.There is no need to tell you they never paid attention to my suggestions.

SI is using a Core 2 Duo if I'm not wrong, and that was one of the delays the had, waiting for more powerfull sensors at the time.

That is the main reason why I still insist that SI had a "clear view" of what to do.

BTW, Paul, are you a friend of Pol Turrents?

Nope! I assume you mean the DP? Sounds like an interesting guy though.

For all of these cameras 10 bit log is plenty of range. 70MB/s would get you 30fps uncompressed (back of an envelope calculation though). To be honest you'd probably find 8 bit log plenty as well.

I think sumix are implementing or have said they can get 2:1 lossless compression within the head. So that would be even better.

cheers
paul

Juan,

I think 10 bit LUT (user defined) already implemented in new firmware. Sorry that we did not give you the credit for it yet. It is a great feature.

I agree that original recording must be as raw as possible. later you can do post processing in CineForm Codec for editing and distribution. Raw data can be used later to improve things. There is always a 14 bit video hidden in the belly of a 12 bit video depending on how fast things are moving.

I just checked with firmware engineer. 10 bit LUT, with lossless compression 1.8 to 1, and running at max frequency for minimum rolling shutter and adding pauses to get desired frame rate (like 24fps) all are implemented and will be available with new application software, hopefully the same time as the new batch of cameras will be shipping. Estimated time, late May

I was told by the people at Norpix quad core was what we should use in an email. Here are some benchmarks:

· 640x480 8-bit color, 150 fps, 95% cpu load (Intel dual-core T7400)

· 640x480 12-bit color, 140 fps, 44% cpu load (Intel quad-core Q6600)

· 1920x1080 8-bit color, 31 fps, 30% cpu load (Intel quad-core Q6600)

· 1920 x1080 12-bit color, 29 fps, 85% cpu load (Intel quad-core Q6600)

· 1920 x1080 12-bit color pixel pack, 95% cpu load ( Intel dual core T7700)

· 1920 x1080 12-bit color pixel pack, 75% cpu load ( Intel dual core T7700, Low Quality)


I don't like the idea of using a quad core processor because the system is going to use 3 times more power if not more. Instead of a 30w chip, having to go to 95w.

I would love to find a solution that would allow us to use mobile Core 2 Duos. Encoding to cineform in post was an idea, and I would rather do that then sacrifice so much battery life. But I'm told that recording uncompressed (60 MB/s) is out of the question for the T7200 computer I bought.

Farhead, are you planning to add RAW recording soon? You mentioned some new software earlier. Is it the version that will be shipping in May?

The best thing would be the RAW data lossless compressed in a container that also stores the settings used while recording as metadata.

I would like to do all the debayering and encoding in post. That way a core 2 duo should be sufficient for recording.

The best way to find out what will be the system requirements for realtime encoding is to just wait for them to release Streampix 3 with cineform and test it out.

The benchmarks done are not on the Sumix camera, but another one so it may be possible that its different.

As soon as Streampix is available Jose and I will run tests and post results. Hopefully I wont have to return this computer after all.

Farhad, thanks for the credit but anyway I wasn't looking for that.I don't think I'm the only one asking for it.

BTW, if you tell your engineers to search the endless posts from around 2004 till today from several people, I guess you will find lots of information and useful resources, from camera features to compression techniques.
I'm mostly interested in getting a "usable" camera.

-10bit RAW 1.8:1 lossless compressed recording with selectable framerate.
-Color chart based automatic callibration with improved white balance.
-Record everything you want as long as you have enough RAM.

If you add future lossless compressed recording to HDD, I prefer Sumix software instead of StreamPix.

Is there a way to change that 1.8:1 ratio to say 3:1 or even 4:1 and still record lossless?

Jose, We understand importance of higher compression ratios. Some form of lossy compression must be acceptable also. When image from 3D world is reflected on the little sensor you already have a tremendous loss of information. Further, silicon in sensor is not perfect and produces more aberrations and loss. logically a little bit more loss should not harm anyone. But in practice at this last stage any little loss may cause big grief. The reason is that traditional lossy compressions do not respect the subtle visual clues in the image used by human eyes to reconstruct 3D, motion, edge, and other important features. Eye must again compress data perhaps 1000:1 or more, if our compression and decompression is not compatible with eye's early vision then human being is annoyed and gets tired of watching.
So, in order not to negatively surprise you later we are not going not make any promise here. Also for you not to be pleasantly surprised we agree that this is a main issue and we would cooperate with our customers in experimenting.
By the way, in our business any surprise must be as much avoided, even good surprise has bad aspects for our customers and our business.

Juan, for you to get a useful camera, consider nothing sacred except continue telling us what you need.

Consering lossless compression one shouldn't except a ratio of more than 3:1.
Actually, some ration between 2:1 and 2,5:1 is realistic:

http://compression.ru/video/ls-codec/index_en.html

Yes, in fact getting to more than 2:1 requires so much computational power that it doesn't make sense for this type of application.

On the other side I don't see how lossy compression could be a bad thing, despite what Farhad may have said. If that were the case SI's camera and RED ONE would be crap, because they are heavily compressing the Bayer Pattern ranging from 5:1 to something around 20:1.
I understand that for some Industrial/Scientific application that could be a bad thing, but not in our case. We need images to look NICE, not CORRECT :)

The secret is in the details, so you need to know HOW to do it right, you can't just throw your RAW to any compression available and expect good results.I'm saying this because a couple years ago, I coded myself a compression (lossy) for the Bayer Mosaic, which was quite good at the testing stage.

BTW, Juan, in the latest versions of CineForm RAW it's now 3.5:1 compression :)

Ohh, sorry, so I need to correct myself. Starting from 3.5 to anything. Is it Mathematically lossless?

there exists more redundancy in pre-debayered
raw data than with debayered yuv or rgb
data. You'd expect better compression with
raw data. Cineform is great though. :)

No, not yet, although practically speaking when you get that low with compression ratios, you are on the verge of being "mathematically lossless".

I think for true mathematical lossless compression you would need to be below 3:1, i.e., 2.8, 2.7, etc. It would also be quite a beast processing-wise because you would basically be compressing redundant noise information and reduplicating the noise signal in the image rather than further rendering any "real" image data itself.

So for instance, right now, with the SI-2K, at 2048x1080/10-bit/24P we're hovering around 18.5-20MB/s at 0db gain.

i do recall SI mentioning they were using core2duo mobile processors to record cineform RAW from SI2k. The cutoff was somewhere around 2GHz+ for realtime encoding and preview a year or so ago i think... so im sure a number of the new 45nm Core2duo mobile cpus ought to be up to the task. is it possible those numbers from norpix for quad core encoding are for Cineform RGB rather than RAW? i imagine jason can verify some of this.

as for compression, mathamatically or visually lossless, even a bit lossy would be fine with me as long as it means a real, usable camera solution comes out of it. ram-only recording wont go far, nor will quad core encoding boxes, although i would love to have an excuse to try to find a way to get a new q9300 quad core cpu into a portable computer.

Norpix should have something out soon, possibly even this week.

I just hope all this talk about compression and data loss won't lead to compromises that would leave us with a product no better then whats already available cheaper on the shelf.

Please correct me if im wrong but even if its visually lossless it could still cause problems in post with chroma keying or color correction. Also leaving behind artifacts in certain conditions.

The ideal solution for me, and it seems like for others here would be to preserve bayer. Debayer and encode to whatever you want in post. This way there is no data lost and we would have the full benefit of the sensor. But I'm not sure if that's a practical or possible option at all.


However, looking at the Wikipedia page for the RED One has some interesting data:

"Redcode RAW is a variable bitrate wavelet codec which allows raw sensor data at resolutions of up to 4096x2304 to be compressed sufficiently for practical on-camera recording. Two variants are offered, one with a maximum data rate of 28MB/s (224 megabits), and one with a maximum data rate of 36 MB/s (288 megabits). Compared with the uncompressed data captured by the sensor, these bitrates represent compression ratios of about 12:1 and 9:1, respectively.

Because Redcode is a wavelet codec, similar to CineForm RAW and JPEG2000, the blocking artifacts associated with other digital video compression algorithms are absent. However, sample images detailing Redcode specific artifacts have been posted on the manufacturer's forum. References to such problems existed until very recently when the message threads containing this information were removed by the Reduser.net administrators.

Redcode is a mathematically lossy codec, meaning that decompression does not fully restore the original image data captured by the camera. Red does claim the codec is "visually lossless", meaning that the information loss is not visible to the naked eye when images are viewed, however this is a subjective statement."

So, maybe compression really is a necessary evil.

No, it's not. All you need is bandwidth, storage and a powerful CPU ;)

The most problems with compression come up in post, not when you look at your recording.

In my opinion there should always be the option to get the uncompressed raw data with maximum bit depth. Mathematically lossless compression of course is a good thing.

All the stuff like lossy compression or RBG conversion with LUT can be added as a feature.

Time is on the side of less compression and lossless compression as computer technology advances. Lossy compression in combination with image enhancement must be done only in post for distribution. Placing sensors for capturing signature of vibrations can be used to remove undesired mechanical movement in video only if you have raw data.
By the way,the same way equipment and fan noise can be recorded and used to remove the parasitic noise from audio. So there must be no fear of fast HD noise, fan, etc.
If Red one is doing 9:1 compression then SMX-12A2C will start to beat it in overall quality.

Sean Hellfrisch and Isaiah Saxon just completed their Bjork 3D music video with all green-screened elements. We also have a number of green-screen elements on our website that you can play with.

While the elements on the website and what Sean and Isaiah produced with were at 5:1 compression (we didn't have the 3.5:1 update from CineForm yet), we think the results are still really good.

Also for comparison, the HDCAM-SR 444 RGB mode at 440Mb/s is more compression than 3.5:1 CineForm . . . and HDCAM-SR 444 RGB mode is very high quality. So I think for the price, you will not find anything delivering the compression quality of CineForm in any other off-the-shelf solution (that can also be edited in real-time on the same box you're recording on . . . using J2K at 3.5:1 compression is not a real-time editing solution).

If we would have SDI out
taking this
http://www.magma.com/products/pciexp...-02360-33).pdf
an SDI card in and an Apple laptop with Finalcut Pro we are ready

a bit more expensive
taking this
http://www.v3hd.com/overview.html
again an laptop Win or Apple we are ready

could it be
could be happy with 10 bit SDI

going crazy reading all the stuuf
ok took it from wiki
The Canon XL H1 Records to HDV.
However, the XLH1 does have an exciting option that none of the other prosumer HD cameras have: a pre-compression HD SDI output. This allows for the exact same signal that is being sent to the HDV codec for compression to be outputted to an HD SDI device through a BNC cable on the side of the camera. Uncompressed recording it can also be sent to a computer via an HD SDI video card such as those offered by AJA and Blackmagic and then recorded completely digitally onto a hard drive for editing or higher quality compression.



Is there any DIY project HD SDI can be send to a SDI Video card
in the magma express box and then pumped in a laptop
my preference am Ibook

Can be portable

Ok, let's concentrate on what we have and what we can do to make it better. The camera doesn't have SDI out, but Sumix will add more in-camera compression modes.

So far the only problem that we have is compression. I don't think the need to use a computer attached to the camera is a problem because SI2K Mini users all around the work do it every day.

For me, 1.8:1 10bit lossless compression sounds great. Maybe an option to record with visually lossless comp so clips are not so heavy? So the only real problem would be RAM recording with long takes, but if we're already compressing, longer takes can be recorded.

So... To make it short: I think as soon as we have the new software update from Sumix we'll be able to test this cam with a real project.

According to Farhad, we'll have to wait till May though. We'll keep on doing more tests while we wait.

here a clip form red (another clip from th peter jackson short) http://jannard.com/images/movies/crossings.mov

one can notice how whites have a red tone (no pun intended ;) ) sumix seems to have the same issue, why is that? is there a way to solve the problem?

not all the shots have the problem, but the ones where the planes are flying and there are clouds there can be seen

Biel, The red tone is just a color correction issue. The samples you have seen from Sumix camera have not been color corrected. We are experimenting with automatic color correction using a Macbeth color chart and least square matching of all colors. The results are pretty exact. We even applied the algorithm on a professional scanner and improvement in color reproduction was surprising. You would expect scanner companies do precision color matching. Some example will appear on our site this week.
I would think that because so many variables affect colors, including lens and filters, exposure, sensor temperature, deBayaring algorithms, etc. that at the end it will be up to the person doing the post processing to use some art of his own.