nanoFlash is Now Shipping
 

Dear Friends,

I am pleased to announce that we started shipping production units of the nanoFlash last night, Friday, July 10, 2009.

These were our limited, initial, shipments; volume shipments will start the middle of next week, around July 15th.

We expect to have shipped all of our priority pre-orders by July 31. Between now and then we will be building, and shipping, the nanoFlash as fast as possible.

We cannot predict demand, but our goal is to have the nanoFlashes in stock for immediate delivery.

Since NAB, we added the following to the nanoFlash: audio inputs, mic and line; headphone out; 140 Mbps and 160 Mbps Long-GOP, and 220 Mbps I-Frame Only; and a Pre-Record Buffer. We also redesigned the case, the keypad and two circuit boards since NAB.

We have more features yet to come. We will be adding over and under-cranking and other features that are in progress. These will come as free firmware updates, just as we have been adding more functionality to the Flash XDR over time.

(Our ASI support is an extra cost item as this is a very specialized feature.)

Very kewl. Congrats. I thought over/under cranking was a feature of the camera? Are you adding a software algorithm to do this for you in the devices, as you can't feed it more frames than the camera puts out.

Is there going to be a more CineForm compression possibility eventually? I know the video looks outstanding, but I'd want to see something like CineForm or REDCODE to have even better source material to work with when moved to the computer.

Again, congrats.

Dear Kevin,

Yes, over and under-cranking is typically done in the camera.

But, since we are doing the recording for the camera, we can add this feature to cameras that do not have over and under-cranking.

We, however, do not create more frames than what is sent to us.

In the example of 720p60, we will do over and under-cranking from 1 to 60 frames per second.

For 1080p30, we will do 1 to 30 frames per second.

Our nanoFlash is not setup to record Cineform internally. But there are many ways for you to still use Cineform, if desired, in your post processing.

Just remember, that if you use our 100 Mbps Long GOP or better, one can not tell visually between live uncompressed and our playback; or your using our files in post (of course, this is dependant on your post workflow).

Hi Dan,

Great news that everything is coming together; congratulations. I have a favor to ask, as well as a question.

(The favor) Now that you're getting into shipping mode for the Nano, could you put together a specification "sheet" of exactly what it (the firmware and hardware) does? I've been reading (and waiting with baited breath) for months, but I no longer have a clear picture of what the shipping units actually do. If I've somehow missed it, and there's a posting somewhere that is current, a pointer to that would be great. If there's a current user manual, I'd love to be able to download it.

(The question) I remember a while ago that there was an XDR failure mode when the input signal was interrupted. I also remember that you came up with a fix, but that the fix only applied if the interruption was long term. (Or something like that). What I don't remember is whether you implemented a fix that deals with momentary (e.g., intermittent connection) interruptions.

Thanks!

Billy

Dear Billy,

We just created an "up to the minute" brochure on the nanoFlash a few hours ago.

We will try to post it on our website on Monday. In the meantime, if you send me a private message, I will send you the brochure. I do not think it would be right to post the brochure here.

We can also post the current nanoFlash user's manual on Monday.

Yes, there was a failure mode if the HD-SDI signal was interrupted.

We now close the current file, stop recording, and then restart recording when we have another good HD-SDI input stream. So yes, we do handle, gracefully, interrmittent conditions.

But, if we have a glitch in the HD-SDI, it takes us a few seconds to do the above, but when the signal is stable again, we will lock on to it and restart recording.

Under normal circumstances, one should not have glitches in the HD-SDI signal.

Thanks Dan,

I also check your main site as well as this one, and if you plan on posting the spec sheet - brochure on your main site, I can just grab it there when I grab the manual you're planning on uploading there; thanks.

Delighted to hear that you deal with interruptions to the SDI input now, that's pretty important to me. (And yes, I realize that the feed shouldn't be intermittent, but I shoot so many "only happens once" things that I tend to prefer equipment that deals well with unexpected circumstance). :)

Billy

Dan,

The AJA Ki is getting the headlines, but you guys smoke that as far as I am concerned. I've seen your ads in HDVideoPro. Nice. But, you should rework it into a 2-column deal, splash of color, and put it in ASC. You've got the goods, go collect your prize.

Great ...
 

Delighted to hear ... I await with pleasure!

you guys are cool ...
 

Just one thing because you could probably do it ... figure out a firmware update that deals with the banding on burst light flashes. Panasonic has done it for their cameras. I just wonder if that's something you can add. I'd expect to pay for it as an added expense but think about all the CMOS camera people that will buy you beers in any joint and any city in the world !!!

In regard to SONY XDCAM PDW800 and PDWF355, can nanoflash record the 1080 60 half resolution they output?

Dear Emmanuel,

One the PDW-800 modes allows for 48p. We do not currently support this, but this is more of having a camera to test and the time to develop the support for this mode.

I feel that we would have to add code to recognize the special half-vertical resolution mode of the PDW-800 camera also.

Since we will need to research these features and disucss it with our engineers, this is not a promise to support this at this time.

It is my goal to fully support this camera if at all possible.

Dear Dean,

I think that is a great idea.

How does this sound:

...What if we detected the bad frame, then duplicated the previous frame, a frame which should not have the problem?

...Would this be good enough, or would we need to check each horizontal row for problems and then replace just one row (scan line)?

...I feel that replacing the entire frame with the previous frame would be best, as this could correct for all defects, those that we can detect, and those that we can not detect.

...This is assuming that there is some image characteristic that we can detect. I feel that there is.

I will check with our engineers. We have recently added a special feature to overcome a problem with a high-end camera. I will be reporting on this soon, maybe this week.

Note: This is a discussion at this time, not a promise. Personally, I think this is a great idea!

it certainly would be interesting ...
 

Panasonic ... as I understand it ... simply took the light that banded across the imagine and applied it to the whole image. I've seen examples of this and it's pretty good. You still see the flash but it's even across the imagine ... it doesn't seem to destroy the imagine either.
I suppose there are other ways to tackle this ... per your suggestion that one sample the frame prior to the flash and see how that plays with the overall imagine. Could be interesting !!

Hey Dan,

Glad you guys are reaching your next milestone.

The repeated frame for the strobe banding sounds like an easy fix.

My only concern is shooting at a lower framerate like 24p might be slow enough that this could be noticeable?

60p would probably have no issues.

It is crazy to think the frames can be analized and corrected whizzing by in HD!

How would the XDR know when to add the correction?

Seems like that parameter would need to be pretty narrow as you wouldn't want that shot of a bride for example with a white dress being confused by the XDR as a white band area and start repeating frames...

Hi Dean-
Can you send (or post) sample images?

Best-