Jump to content

Time To Play Stump David Mullen!!


Guest dpforum1968

Recommended Posts

  • Replies 51
  • Created
  • Last Reply

Top Posters In This Topic

  • Premium Member

Do you mean uncompressed and not color sub-sampled? Do you mean 1920 x 1080 pixels, 4:4:4 HD like the Viper sends out in Film Stream mode?

 

I forgot, but I seem recall it was in the 270 Mb/sec range?

 

The intermediate duplicating stock is a neg-pos stock -- i.e. not a reversal process -- so it makes the opposite to whatever is photographed onto it, just as a print stock does. So a negative printed onto the intermediate stock is a low-contrast positive image (with the orange color mask, unlike print stock) called an interpositive. But when an interpositive is printed onto the same stock, it becomes a negative image (an internegative or "dupe negative"). And if you printed that internegative onto the same stock, you'd get another interpositive, and so on.

Link to comment
Share on other sites

  • Premium Member

Hey David, What is the air-speed velocity of an unladen swallow? ;)

 

Just kidding, umm, I think the datarate of ucompressed HD is much higher. I remember hearing that HDCAM SR is 880 Mb/s. So I would guess that uncompressed would be higher than that.

Link to comment
Share on other sites

  • Premium Member

Making interpositives and duplicate negatives:

 

http://www.kodak.com/US/en/motion/products...1.4.6.4.4&lc=en

 

http://www.kodak.com/US/en/motion/support/h1/printing.shtml

 

http://www.kodak.com/US/en/motion/support/....4.11.8.6&lc=en

 

http://www.acvl.org/manual.htm

 

Always a good idea to make your interpositive(s) as soon as you have the final approved answer print. Usually done on a wet gate contact printer.

 

With Digital Intermediate, you have the option of recording out to an interpositive or a duplicate negative:

 

http://www.cinesite.com/?123

 

http://www.cinesite.com/img/Cinesite/Holly...ng/di_chart.pdf

Link to comment
Share on other sites

  • Premium Member

Bit rate is all simple arithmetic you can do yourself.

 

Suppose we go with 1920 x 1080 pixels. Just multiply -- always you multiply. That's 2,073,600 pixels per frame. Suppose we do that at 24 frames per second. Just multiply again and you get 49,766,400 pixels per second. Now if we use 4:4:4 and ten bits per color, that's 30 bits per pixel, giving us 1,492,992,000 bits per second. That's about 1.5 Giga-bits per second. Eight bits per color would give us about 1.2 Giga-bits per second (1,194,393,600).

 

Now for 4:2:2 and 4:2:0.

 

With 4:2:2, each pair of pixels side by side uses only one set of color differences, but each pixel has its own luminance data. So for two pixels, you have two luminance samples and one each for luminance minus red and luminance minus blue. That's four samples for two pixels, or two apiece. In ten bit video, you'd have 20 bits per pixel in 4:2:2. For eight bit, each pixel has 16 bits. So, 4:2:2 ten bit would be only about 1.0 Gbits/sec, while 4:4:4 is 1.5 Gbits/sec.

 

In 4:2:0, each two by two group of four pixels uses one set of color differences, but has separate luminance data for each pixel. So, your four pixels have a total of six samples, four luminance, and two color difference. You'd have 15 bits per pixel at 10 bit depth, and 12 bits per pixel at 8 bit depth. With 4:2:0, you use exactly half as many bits as 4:4:4 would. Eight bit 4:2:0 1920 x 1080 would be about 0.6 Giga-bits per second.

 

 

 

 

-- J.S.

Link to comment
Share on other sites

  • Premium Member

Hi,

 

Divide by eight, so 0.15Gb, or 150Mbyte. That's why uncompressed and unsubsampled HD (as in a Viper) generally requires dual link SDI - full 2K 10bit images require around 300Mbyte/sec ay 24fps, which is difficult to achieve.

 

Phil

Link to comment
Share on other sites

IP=Intellectual Property

That's the one I had in mind - Zekthedeadcow wins, (Wendell's answer was good , and the book mention was excellent (thanks), but I can't be bribed :rolleyes: !). No prize for Zek..... either, just the glory.

 

For David, and anyone else

 

1000 bytes = 1kilobyte

1000kB = 1 Megabyte

1000MB = I Gigabyte

1000GB = 1 Terabyte

1000TB = 1 Pedabyte

 

1 byte = 8 bits (usually 1 word)

 

usually data rates are measured in bits per second (bps - small 'b') because it's a measure how fast you can get a string of 0s or 1s (bits) through the system.

 

memory, file size etc is measured in Bytes (or Megabytes etc) (MB with a capital 'B').

Link to comment
Share on other sites

1000 bytes = 1kilobyte

 

And actually...

 

8 bits = 1 byte

1024 bytes = 1 kilobyte

1024 kilobytes = 1 megabyte

1024 megabytes = 1 gigabyte

1024 gigabytes = 1 terabyte

1024 terabytes = 1 petabyte

 

 

I have a friend who has shot some print stock. I haven't seen it, but he said it was extremely saturated.

Edited by Nate Yolles
Link to comment
Share on other sites

1024 bytes = 1 kilobyte

Kilo is the SI prefix for 1,000. Engineers have always used it as such.

 

Computer engineers took the shortcut that 1024 (2^10) was close to 1000, so decreed that in terms of computer memory, 1 kilobyte was 1024 bytes.

 

(Computer and storage salesmen weren't always so consistent, as memory seems larger if you quote it in 1000-units not 1024-units. )

 

Sometimes the difference is important (if you are working out if you can fit your program onto a disk for example). In general I find it easier to work with 1000s.

 

But thanks for drawing attention to the difference.

Link to comment
Share on other sites

  • Premium Member

I worked the majority of my adult life as a network security analyist and administrator (CCNA and CCNP and was studying for the CCIE before I went to work for Abel). There was/is a concerted effort to use those prefixes in that sector of the industry.

 

It's not wide spread, but it is a better nomenclature. Much like the metric system in the U.S. it will probably not take hold.

 

It's a shame. Precision is what you need when you're defining a measurement.

 

1024 =! 1000...

Link to comment
Share on other sites

f/4.8 or f/5

 

Isn't this the industry that prefers the more accurate t-Stops over the more abstract f-Stops.

 

True. Yet, even when you tell your AC to set the lens at T2 and a 2/3rds, there's no marking for 2/3rds, its only an approximation. Likewise setting focus when your lens says "3 5 10" and you need 9 ft, not to mention the actor hitting his mark exactly. My only point (and it's a mute point) is that there's plenty of rounding off and "closeness" in cinematography and it all works perfectly. So sometimes such precision doesn't actually benefit you. Although I do agree with you, it is nice to be accurate and it is important to know that 1/50th is actually 1/48 and that 1000 is actually 1024.

Edited by Nate Yolles
Link to comment
Share on other sites

  • Premium Member
Hi,

 

Me either.

 

Phil

Nor have I ever heard before of Mebi or Kibi bytes or bits. Kibibits does sort of remind me of a dog food commercial, though. ;-)

 

Actually this isn't as bad as shop vac horsepower, consumer amplifier power, extension ladder lengths, or two by fours that are actually one and a half by three and a half's.

 

A byte is very well standardized at eight bits now. A word is the size of a computer's memory locations and the width of its data buss. For instance, the Z80 was an eight bit chip. the 80286 was 16 bits, so each word was two bytes. Today I think we're using 64 bit machines, but I could be wrong. Pentium 4 or 5 or whatever the latest chip is....

 

 

 

-- J.S.

Link to comment
Share on other sites

  • Premium Member

Hi,

 

Current MPUs such as the Pentium 4 and AMD Athlon XP series, which are approximately equivalent in performance, use 32-bit busses throughout. The largest number of which they can conceive is 4,294,967,296, or 2^32. Larger numbers require several consecutive operations and a combined result (C programmers may blast on about Double or Long ints, but that's emulated by the arithmetic unit).

 

You can buy an AMD Athlon 64 or Opteron FX series processor, or an Intel Itanium (which is somewhat more obscure) and they have 64-bit data and address busses. The principal advantage of current 64bit MPUs is that they tend to have very fast memory interfaces, which is critical to media applications where you're constantly fetching things like image data from memory. Contrary to popular belief, doubling the width of the data bus does not make a processor twice as fast (just like multithreading doesn't make a Pentium 4 equivalent to a dual-CPU system.) 64bit MPUs can process calculations to twice the precision of an 32bit device in the same amount of time, so it will tend to be faster for applications where you require very accurate mathematics. Discrete cosine transform encoding (used in many video codecs) and certain types of image processing might be candidates for this, although most current DCT implementations wouldn't be, and these things might get faster because you can do in one cycle (or more than one per cycle) what previously took more than one floating-point arithmetic operation and a logical combine. These applications will get faster in proportion to the amount of high precision mathematics they do, but there is no other intrinsic benefit.

 

Phil

Edited by Phil Rhodes
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Forum Sponsors

Visual Products

Film Gears

BOKEH RENTALS

CineLab

CINELEASE

Gamma Ray Digital Inc

Broadcast Solutions Inc

Metropolis Post

New Pro Video - New and Used Equipment

Cinematography Books and Gear



×
×
  • Create New...