Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

ATOMOS Samurai Blade review

Bjoern I cant speak for the pix but the LCD on the Atomos is excellent, it is definitely on par with the RED LCD and the edge detect works very well and is super responsive.
so it would be a great little focus monitor. the only thing I noticed is that the blade seems a little less bright than the RED LCD when compared on both full settings.
 
Dominik Muench said:
Bjoern I cant speak for the pix but the LCD on the Atomos is excellent, it is definitely on par with the RED LCD and the edge detect works very well and is super responsive.
so it would be a great little focus monitor. the only thing I noticed is that the blade seems a little less bright than the RED LCD when compared on both full settings.
Click to expand...

Thanks for that info.
The colors I do not care much about. Usually I put's the screens in raw or BW just to end the discussion of color accurate screens. It's odd, no DP was requesting the video tap to look like the final graded image when we where shooting film. Now when things are digital they expect to "see the true image" when they shoot which to me is impossible as that is like asking to have the colorist on set doing all their stuff between monitor and camera. As the picture is raw, it's no real reason to calibrate screens before grade. But good sharpens / edge detect is really handy.
 
Posted before, but, thinking of installing the Atomos Blade in my u/w housing, does anyone have the time to measure the unit, with and without battery installed? Thanks in advance.

Tom
 
Dominik Muench said:
Is anyone of you guys working in a 25fps timebase ?

for some reason even though my epic is set to a 25fps timebase project...my blade receives a 1080p24 signal....is that the only way the epic can output ? or can it do 25p over HD/SDI too ?
Click to expand...

The Epic can do 25p over HD-SDI. It's a separate menu setting from the timebase. The factory default is 1080p24.
 
Björn, I saw you mentioned the Ninja. It's only the new samurai Blade that has the really good screen.
I have the previous Samurai and the screen is no good for focus
 
I received the blade and have a few gotchas that haven't been publicized much in the write ups and videos I have seen.

1) While it's cheap for what it does, it definitely does feel cheap. Plastic everywhere. The only metal bits are the BNC connectors and pins for the battery. I feel like it would shatter if it took a fall on pavement. Also not included is the sun hood which was mentioned on major retail sites as part of the pre-order kit. It will be tough to see outdoors without it.

2) XML export only supports FCP X XML. I don't work in FCP X, so you'll have to purchase a $50 app to utilize any in blade adjustments (i/o points, favorite/reject flags, etc.) if you aren't cutting in FCP X

3) I would much rather have a permanent wall wart adapter w/ short BNC and custom D-Tap cable than a mess of interchangeable plug heads. It doesn't make sense to me why there would be a D Tap adapter with a female lead without the male to male D Tap cable that must be custom made. At least give us 2X D Taps or a D Tap w/ flying lead if anything.
 
Yep...the blade is just a samurai with better screen and standard size BNC's...something it should have had from the beginning. I have owned a Ninja then Samurai from day dot, it has it's downsides but all in all is a pretty good tool and mostly reliable but not 100%...although like a lot of new gear out there it's as the saying goes...you get what you pay for! Dual record is fine but by itself, your not very smart if you make that choice. I have about a 1/6 record of it stopping itself mid take, missing entire clips or just decides to stop accepting SDI triggers. I for one will be instantly selling it when RED ships the proxy module.
 
Brigham Edgar said:
I have about a 1/6 record of it stopping itself mid take, missing entire clips or just decides to stop accepting SDI triggers. I for one will be instantly selling it when RED ships the proxy module.
Click to expand...

I have faced this same issue with my Samurai.Then Atomos people help me out with RMA.they gave me a new unit.Next project I will use with new Samurai.

Sunil Prem
 
A heads up reagarding the latest update for the Blade:

NEW FIXES:
• Fixed very infrequent problem with incorrect mov file header with some cameras resulting in some video incorrectly displayed.
• Fixed difficulty with setting year if date is completely reset. Year setting now starts at 2013.
• Improved drive size calculation to ensure recordings will not attempt to start when the drive is full.
• Recording now uses default file names when Red file naming is enabled, but camera is not a Red camera.
• Red file naming has dropped the _Txxx suffix. Filename is now exactly the same as internal camera name.
To get an exact match with the Red filename:
  • The camera must be set to TOD.
  • Red camera trigger must be used. Set this in the timecode page.
  • The record button on the Red camera must be used to start and stop all recordings.
 
Exact file naming is big win making this a way more useful gadget. I asked the engineers about the Blade at a trade fair and whether it would start and end its recording on the exact same frames as the R3D file and they could not guarantee it. So a question to experienced post people. If the Pro res files from the Blade differed by a frame or two in length from the R3D files and assuming timecode was exact and file names were exact would there be any issues when matching back to the R3D via an EDL or XML when it came to colour grading?
 
Tom Gleeson said:
Exact file naming is big win making this a way more useful gadget. I asked the engineers about the Blade at a trade fair and whether it would start and end its recording on the exact same frames as the R3D file and they could not guarantee it. So a question to experienced post people. If the Pro res files from the Blade differed by a frame or two in length from the R3D files and assuming timecode was exact and file names were exact would there be any issues when matching back to the R3D via an EDL or XML when it came to colour grading?
Click to expand...

+1 on that
 
Tom Gleeson said:
Exact file naming is big win making this a way more useful gadget. I asked the engineers about the Blade at a trade fair and whether it would start and end its recording on the exact same frames as the R3D file and they could not guarantee it. So a question to experienced post people. If the Pro res files from the Blade differed by a frame or two in length from the R3D files and assuming timecode was exact and file names were exact would there be any issues when matching back to the R3D via an EDL or XML when it came to colour grading?
Click to expand...

A frame of is a frame off.. so you would have to eye ball it. The simple way to do so is to have timecode in picture for the feed to the Atmos. Then the offline editor can check so that the "in picture TC" match the TC for the atmos files. if not, then he has to offset the tc to match the in picture TC since thats the one that does not lie.

Then if thats checked and done you should be able to conform in resolve or such and have no issues... as long as you did no shoot anything off framerate or such.
 
Would anyone be interested in an focusing diopter for the Samurai Blade? The one in the photo is the Carbonite Scope, but it would be similar. Hit me up at jason@CinemaOxide.com

CM8A8754.jpg
 
Jason, while you are at it.

What I want:

A carbon fixture that holds the Blade together with a teradek bolt reciver and that is powered by a XL volt... No cables sticking out or such, think as far away as possible from something gaffered together. Think of a solid thing that I can give to directors and others and just know they can not brake it even if they drop it on the floor.

Size is not to important to rather have a carbon shell and the monitor, battery and other things inserted into foam and or some sort of cage system. Add your scope to it and I will buy two :)
 
Björn Benckert said:
Jason, while you are at it.

What I want:

A carbon fixture that holds the Blade together with a teradek bolt reciver and that is powered by a XL volt... No cables sticking out or such, think as far away as possible from something gaffered together. Think of a solid thing that I can give to directors and others and just know they can not brake it even if they drop it on the floor.

Size is not to important to rather have a carbon shell and the monitor, battery and other things inserted into foam and or some sort of cage system. Add your scope to it and I will buy two :)
Click to expand...

+ 1

I will buy one too!
 
Björn Benckert said:
A frame of is a frame off.. so you would have to eye ball it. The simple way to do so is to have timecode in picture for the feed to the Atmos. Then the offline editor can check so that the "in picture TC" match the TC for the atmos files. if not, then he has to offset the tc to match the in picture TC since thats the one that does not lie.

Then if thats checked and done you should be able to conform in resolve or such and have no issues... as long as you did no shoot anything off framerate or such.
Click to expand...

A frame or two off is due to the Samurai having to detect the SDI record on/off flag before going into Record - this is the same with any camera triggered external recorder. However the embedded timecode should still be frame accurate, and therefore able to be used to conform back to Red R3D files, as long as the editors know not to use the few frames at top or tail of the offline files in their edit.

However, according to Red's own documentation the in picture GUI timecode is not frame accurate and should only be used as a guide to the actual embedded timecode. So it's the embedded timecode that does not lie.
 
ericyoung said:
A frame or two off is due to the Samurai having to detect the SDI record on/off flag before going into Record - this is the same with any camera triggered external recorder. However the embedded timecode should still be frame accurate, and therefore able to be used to conform back to Red R3D files, as long as the editors know not to use the few frames at top or tail of the offline files in their edit.

However, according to Red's own documentation the in picture GUI timecode is not frame accurate and should only be used as a guide to the actual embedded timecode. So it's the embedded timecode that does not lie.
Click to expand...

Thanks, Did not know that. I think I never had an instance where the in frame TC has been off. But if it's in the manual then I guess that could happen.
 
You must log in or register to reply here.
Back
Top