Domain: digitalcontentproducer.com
Stories and comments across the archive that link to digitalcontentproducer.com.
Comments · 8
-
Re:Why rush to use all the cores?
Where can I by these Xserve blades? Sound really useful, I wish they'd market them more than their 1RU jobs without a replaceable power supply.
Pixar's operation uses mostly Intel Xeon/Linux rigs in the farm.
-
Combine with VR Cave!
Combine Second Life and Second Skin with virtual reality "cave" technology and you have a low rent holodeck. Use it to interpret gestures like the Wii does, and yes, you have a revolution in cybersex and interactive pr0n.
I say it's a buy! Someone is going to make many millions on this. (Especially if they invent a Bluetooth API for optional teledildonics.)
-
Re:The EU is just bashing an American company
Take Silverlight for instance, you do NOT have to use it, there are other alternatives. Look at Flash, you can develop Flash with whatever code, even Adobe's, but makes sure it will play with the FREE Gnash Flash movie player [slashdot.org], not just the Adobe player.
Yes, but you can do the same with Silverlight and Moonlight. What makes Flash better?
Most people when they refer to Flash are talking about Adobe Flash and Adobe Flash reader only. I am not. I am suggesting that create Flash content with whatever software tools that you want, but on your website, DO NOT offer an "Adobe" specific version as the first or only choice.
If how ever you encode it allows it to be opened with Gnash or Flash Player, great.
If how ever you encode it, lets say you use an Adobe specific library and/or function that only can be understood by Adobe Flash Player, so that Gnash or other non-Adobe- specific-Flash players can NOT open it, not good at all. Best to avoid problems due to lock in.
Personally I do not think either Flash or Silverlight either one are superior to a an encoded H.264 CODEC enabled video. Though admittedly it depends on the settings used by the person who encodes the video. It is telling that to get close, not equivalent to, H.264 quality with other CODECs you have to increase the resolution and the FPS. Per this evaluation of video codecs (H.264, VC-6, and VC-1) In all comparisons, H.264 exhibited the best still frame quality. . They analyzed individual still frames of various videos looking for problems with the images and side effects by inferior encoding and compression methods, not just still pictures. H.264 encoded Videos were better of higher quality and better to the eye to watch. H.264 can come in either proprietary or open source coding. The open source codec is superior or equivalent to all proprietary H.264 codecs...so why make anything proprietary unless you are lazy or have alternative motives..i.e. Software or Operating System Lock In.
Therefore I might suggest the MPlayer is superior to either Silverlight or Flash. And it will work under all operating systems that most people use: Unix, Linux, MacIntosh and yes even Microsoft Windows.
Flexibility, open to all; the fact that H.264 is a superior CODEC than what is standard for Adobe Flash and/or Microsoft Media Player is icing on the cake.
As a business that wants everyone to see my content and at the highest resolution and the most effective frame rate (fps) that makes sense for the bandwidth that I have available to me.
-
Re:So which format is next DVD or BlueRay?
-
Re:Spreadsheet
Those companies render the output on Linux. The creation takes place on a Mac.
Not strictly true. Mac hardware perhaps. If you just do a name check for the apps used, you will go away with the wrong impression. Many CGI companies used Unix based systems extensively from the start. The old SGI workstations were usually running Unux, and then Linux was brought in to run on cheaper commodity hardware, and reduce the rewrites needed to do the changeover. Basic good business case scenario. Linux was a smaller move and a cheaper option than the expensive workstation grade systems they were using. Which is why Nvidia has been supporting Linux for so long. Cinepaint was a fork of an early Gimp version that was heavily customised for the movie industry. ILM even created EXR, which was open sourced so other apps could use it. It is commonly used for retouching jobs instead of Photoshop. Practically a custom app for hteis very job. Massive, the crowd control software used in movies such as Lord of the Rings and others for animating large numbers of figures also works on Linux, and according to one article I read, works better on Linux than on Windows. Ever wonder why Maya is available on Linux? could it be that the top CGI studios who have been using Unix for years, and are Maya's main user base, and have been changing to Linux wanted it. And if you read up a bit, there are plenty of articles about Linux being used in the production side. Sometimes even on Apple hardware running Linux. http://www.linuxjournal.com/article/9951 An interview with the makers of the Spiderwick chronicles. Not a great movie, but some very nice effects. Linux software for content creation running in Apple hardware. http://digitalcontentproducer.com/dcc/revfeat/video_linux_hollywood/ Basically a rundown of Linux in the high end CGI field. Particularly interesting, and shows how wrong you are. There is way more than you think happening with Linux in the CGI world. Off the shelf apps are not enough by a long shot for the movie industry. They have the money and the technical resources to make custom apps that are strictly in house, and will likely never be released to the wider world. For them, Linux works, and works well. And allows them to use the millions of lines of old code from the Unix days that they still need. So basically.. the movie industry uses whatever works, and some of the really big studios have the resources to overcome any limitations of existing software where required. It is a pity they don't release more of their code, but such is life. They don't have to. And much of it would no doubt be useless without the other tools they use for various things. Although the thought of ILM contributing code to Blender and Gimp is quite a nice one.
-
Thought it would be more, actually...
Back in the mists of time, I wrote the database for the content management system that Lucas used on Star Wars I (the Phantom Menace). For reasons I won't go into, it was called 'Cakes', but ILM rebranded it internally as Media-DB.
At the peak of filming, it was coping with 40 DTF tapes/day being ingested. A DTF held 120GB back then (I think), and they were filming for ~3 months. At the same time as ingesting, it had to stream low-res proxies of all the footage to multiple destinations (some local, some not), and deliver high-res frames across the internal network to the animators etc.
Now, I doubt it was doing 40 tapes/day solidly - it'd depend on filming, but even taking 20 tapes/day, over 3 months that comes to ~160TB (assuming a 22-working-day month).
I do have fond memories of doing the James Bond intro-sequence (The world is not enough) with Smoke & Mirrors in London. When there were thousands of frames of nearly-naked highly-attractive women having oil poured all over their bodies, the visualisation tools became... significantly more advanced at a rapid rate
:-)Simon.
-
Re:Article is based on faulty premise(dang it, here is my comment again, with the correct formatting:)
The article is wrong. The resolution of the eye is not 1/2 the normally accepted value of 1 arcminute, as the article claims, it is the normally accepted value of 1 arcminute. Experiments show that visible structures are still discernable when they are only 1 arcminute apart (see "Vision" by Pierre Buser and Michel Imbert, MIT Press, 1992, p. 120). The pixel spacing should therefore be 1 arcminute, not two.
Let's extrapolate that figure into a real-world situation: theatrical movies. SMPTE standards say you should be 2 screen heights back for an optimal viewing distance. For a 2.35:1 movie, that works out to about 60 degrees. That means given the 1 arcminute spacing rule, there should be 3600 pixels across the width of the screen. Most movies these days have digital intermediate work done at "2K" resolution, or ~2000 pixels across the width. However, some are starting to have their work done at "4K", or ~4000 pixels across the width of the screen. What do you know, in a blind test blind test, people invariably pick out 4K material as looking better (see 4th paragraph of link). That couldn't happen if the figure were 2 arcminutes.
It's really too bad this article made the front page of slashdot. People who don't know any better are going to be linking to it forever, and I'll have to keep copy/pasting this rebuttal.
-
Article is based on faulty premiseThe article is wrong. The resolution of the eye is not 1/2 the normally accepted value of 1 arcminute, as the article claims, it is the normally accepted value of 1 arcminute. Experiments show that visible structures are still discernable when they are only 1 arcminute apart (see "Vision" by Pierre Buser and Michel Imbert, MIT Press, 1992, p. 120). The pixel spacing should therefore be 1 arcminute, not two.
Let's extrapolate that figure into a real-world situation: theatrical movies. SMPTE standards say you should be 2 screen heights back for an optimal viewing distance. For a 2.35:1 movie, that works out to about 60 degrees. That means given the 1 arcminute spacing rule, there should be 3600 pixels across the width of the screen. Most movies these days have digital intermediate work done at "2K" resolution, or ~2000 pixels across the width. However, some are starting to have their work done at "4K", or ~4000 pixels across the width of the screen. What do you know, in a blind test, people invariably pick out 4K material as looking better (see 4th paragraph of link). That couldn't happen if the figure were 2 arcminutes.
It's really too bad this article made the front page of slashdot. People who don't know any better are going to be linking to it for a long time, and I'll have to keep copy/pasting this rebuttal.