So, this respected researcher has changed his mind three times in 4 months
That in itself is an interesting fact though... That a professional economist can't decide whether or not music piracy has a statistically significant effect on sales should tell you something. (even if there is a statistically significant effect, its magnitude is likely to be quite small...)
To wit, Liebowitz notes that the impact of piracy on sales is not likely to be greater than 20%. If I were a record company I would be thrilled to learn this... It means I can offer just what customers want - plaintext (DRM-free) music for sale over the internet, at various price points - which would doubtlessly offset the 20% sales impact of unlicensed uses. (keep in mind that Liebowitz' figures are based on today's large record companies, which offer virtually no legal for-pay downloads of popular/hit music)
(but the RIAA is not thrilled, which should tell you that piracy isn't what worries them - its the loss of their god-like control over promotion and distribution which the internet is bringing about...)
There is actually quite a bit of "rhyme and reason" to creating a multi-thousand-character CJK font. e.g. thousands of Chinese characters are left/right pairs, so you just have to design the few basic left halves, the few basic right halves, and then automatically generate all of the combinations. Many of the simplified characters used in the PRC can also be generated automatically from their traditional counterparts. (of course some manual tweaking is going to be required, but just know that creating a 10,000 character font isn't nearly as difficult as creating 10,000 unique designs =).
Knuth put a whole lot of effort into designing fonts for TeX, such as Computer Modern Roman and the Euler math font. Even though these would have to be converted from METAFONT to a modern encoding, I think such a conversion would still be easier than starting from scratch...
Id software is writing Doom III in C++... But yes, that's a rather tiny change after 10+ years of evolution. (there are also the various byte-code languages they've used for non-engine game logic, but most of those are still very C-like)
Always remember folks, Hollywood's goal is not to stop piracy - that's technologically impossible. They just want to ensure that every aspect of using their products is controlled and paid for.
Want to see Snow White once on your TV? That'll be $2.50. Want to watch the making-of documentary? $2.00 more. Listen to the soundtrack for up to one month? $3.50. Send a 30-second clip to five friends? $1.50. Download the movie for use in one portable player device? $5.75...
In economic terms, it's perfect price discrimination - by nickle-and-diming consumers on every use of media, the industry will reduce the consumer surplus to zero, transferring it to their producer surplus. In other words, be prepared to pay more for the media you're getting now, or plan on reducing your consumption...
And what about independent non-major studios? They'll sure have a hard time producing content when low-cost digital editing systems become illegal. And of course the encryption keys that make this whole system work will only be available to studio distributors...
There was an interesting panel on this subject at SIGGRAPH a few weeks ago. An attendee from Pixar said that their main issue now is that their scenes are so large that it's becoming impractical to keep them in memory throughout the entire render, even with a smart acceleration datastructure (Pixar's Renderman, although fundamentally a rasterizer, needs to keep at least bounding boxes for the entire scene in RAM due to its "bucketing" process). Also he noted that many of Pixar's scenes are I/O bound - it takes longer to read the geometry and textures over the network than it takes to actually render them!
The gentleman went on to describe Pixar's work on a new renderer which (if I heard correctly) goes to the extreme of keeping no scene data permanently in RAM, and just streams primitives in and splats them to the screen.
So, while most rasterizers are indeed O(n) in the number of geometric primitives, a raytracer or other retained-mode renderer could be "O(n + log(n))", if you count the I/O required to read the scene and build the in-memory representation!
Of course I've conveniently ignored the fact that Renderman and its siblings cannot handle any sort of non-local lighting computations. (true reflections, shadows, ambient illumination, etc). But all of the high-end 3D studios seem to prefer "faking" these effects (with shadow/reflection maps or separate "ambient occlusion" passes) rather than taking the extreme speed penalty of a retained-mode renderer.
(incidentally the same sort of issue came up at Digital Domain's presentation on their voxel renderer - although they started out using volume ray-marching, the render times got so long they switched to voxel splatting, and used various tricks to make up for the lower image quality)
I think the point of their process is to avoid multiple 35mm generations between the camera negative and release print. If you blow up the camera negative to 70mm and stay at 70mm throughout the print-making process, the result will look (marginally) better than a release print made from 35mm intermediates.
Of course this process isn't going to achieve the same quality as if you actually recorded 70mm film in the camera. But cutting out one or two generations of 35mm printing can help - e.g. SW:Episode II had very little grain in the film release prints, since they were all first-generation copies of ILM's digitally-recorded negatives.
By playing the music we play, we encourage those listeners to go out and buy CDs. Apparently the RIAA doesn't understand that. Somehow, allowing people to hear a SAMPLE of music the RIAA produces, encouraging people to buy a full album, is considered piracy to them.
Ah, but when people are listening to (airwave) radio, they are listening to/sampling what the RIAA wants them to hear. With internet radio, they don't have that element of control. So they'd rather shut you down than have you promoting artists who you may like but who are not on the industry's schedule of who gets to be a hit. (or, god forbid, artists who have not signed away their soul to a major studio)
Now that several companies are producing OpenGL hardware that is somewhat comparable to NVIDIA's, all it's going to take for me to switch is for one of them to have a completely open-source driver. I am tired of recompiling NVIDIA's driver manually for every kernel update, waiting for updates from them, and forget any platforms other than x86 and ia64...
Cards are so fast these days, I'd gladly sacrifice a 25-50% performance edge for the portability and reliability advantages of an open-source driver. ATI, Matrox, Trident - I'm waiting...
Thanks for pointing out Troma! No, I hadn't heard of them before. Perhaps they are the first of what will become many independent studios. (I think this transition is inevitable, it's just going to take a long time because the major players will try to stop it every step of the way).
BTW I worded my original post very carefully. I know lots of independent producers are making great films with cheap digital equipment (eg DV) - you're just not able to see them in major theatres (yet), and they have quite an uphill battle to obtain marketing dollars and distribution outlets...
I also know it's possible to author simple DVDs with e.g. Apple's iDVD, but those won't have studio-level features like a Dolby Digital soundtrack, a full menu system, etc... Both of which can be had for a modest ($2K-$10K) investment in software, but good luck trying to produce a CSS-scrambled, region-locked DVD (which distributors might demand) on your own =).
Loss of control, not piracy
on
High Definition DVD
·
· Score: 5, Interesting
Hollywood's biggest fear is not piracy... It's that someone will be able to create and distribute a popular feature film outside the studio system. That would be the beginning of the end of their monopoly on popular film and hence culture.
Like DVD, expect it to be extremely difficult to author a properly formatted and encrypted HD DVD (not ripped from an existing one)...
That may have been Pixar propaganda =). I saw Larry Gritz a few times at SIGGRAPH; he seemed to be in good spirits. (Larry was the main developer of Entropy, after creating BMRT). He certainly didn't act like someone had just taken his livelihood out from under him...
The sad part is that Pixar could probably hit a lot more renderers. Deep shadow maps aren't widely used yet, but jittered sampling (another Pixar patent) is... (this may be why the "jittered antialiasing" setting in Lightwave is still a "secret" feature =).
Does anyone have the real info on Exluna? I see now that they've discontinued Entropy and BMRT, but I thought that was mostly because of being purchased by NVIDIA. (my hunch is these products will reappear in the near future as the first hardware-accelerated Renderman renderers =)... But since the settlement with Pixar is secret, I guess we may never know?
If Apple switched to x86 chips I'm sure they would add some proprietary BIOS or something to prevent the OS from running on non-Apple PCs.
To its credit, Apple already has one successful CPU architecture shift behind them (680x0->PPC). So they have experience dealing with the compatibility issues. (though said experience included writing a 680x0 emulator for PPC; it'd be a big project to do a fast PPC emulator for x86...)
You hit the nail on the head... Current CG tools make very inefficient use of artist time. It's hard to put together an animated short (of decent quality) on any kind of constrained schedule.
I estimate that 70% of labor time on my recent NASA animations (maasdigital.com) was devoted to mindless tedium like queueing up renders, splitting scenes into different elements for compositing, shuttling video files through different editing systems, etc. The actual creative work got lost in the noise.
But solutions are coming. Maas Digital is working on much better tools; just watch us =).
GCC 3 has been very buggy recently. I tried the GCC 3.1 release in Debian testing a few weeks ago - I quit using it immediately when I discovered that G++ neglects to destroy objects on the stack after an exception is thrown. Also, starting with GCC 3, all C++ programs are required to link with libgcc (which has had binary compatibility problems)...
So, for my own C++ development work I am still stuck with Redhat's relatively stable 2.96-98 release.
FLTK is an excellent toolkit. I have used many over the years (Gtk, Qt, TK, and Win32 all quite extensively), and FLTK is my current favorite. It is dead simple (in a good way), clean, fast, and doesn't constrain your code as much as other toolkits do...
BTW Am I correct in assuming that the upcoming public release of Nuke is going to be FLTK-based?
Well there's just one extra check I'd love to see patent examiners do - use Google and do a search on each of the claims. That alone would probably weed out 70% of the obvious crap =).
I should add that some programs (e.g. Adobe Premiere 6.0) have audio sync problems dealing with very long DV files. I suspect this is because DV allows the number of audio samples per frame to vary by a tiny bit, whereas the software expects to see a fixed number of samples each frame.
I work with multi-GB DV files every day, recorded with dv1394 or encoded using the MainConcept codec. A DV file is simply a continuous stream of 120KB frames; there is no meta-data or index as with MOV and AVI, so there is no inherent length limitation.
The root of this whole 2GB mess is that old file access APIs and file formats used signed 32-bit quantities for file sizes. 64-bit file access APIs have been available for years now, and both MOV and AVI file formats have been extended to support 64-bit sizes. But sadly there is still a ton of software out there (including Quicktime!) using the old 32-bit formats...
I forgot to specify that I was using the Windows version =). I never used the Mac version of QT5 so I don't know if it had the same limitations.
My primary goal is to become independent of proprietary multimedia libraries. I like using uncompressed AVIs because I know enough about the file format to write them without help from any external libraries. If worst comes to worst I could probably find a way to write uncompressed MOVs myself too. (I know there is a free Quicktime library; but is the file format actually documented anywhere?)
Yes, the OpenDML extensions allow AVI files over 2GB, and I use them routinely. The problem is that Quicktime 5 only supports old-style (VfW) AVI files, meaning it won't find any data beyond 2GB.
A different issue is that Quicktime 5's DV stream reader also does not recognize data beyond 2GB.
Apple needs to wake up and start using 64-bit file APIs. I know they can do this because QT5 does support MOV files larger than 2GB!
(I need DV support because my own software reads/writes raw DV streams, and I need large AVIs because uncompressed AVI is my standard video format; uncompressed Quicktime is much less common in my work)
If you are going to change the format of/etc, then I think it would also be a good idea to implement something I've really been missing - transparent overlays. I'd love to have a "master" set of configuration files somewhere on the network that would provide defaults for all machines in the company. Then each individual machine would only have a very few files in/etc, to make whatever machine-specific customizations they need (eg whether or not to run a webserver). And finally each user would have his/her own set of/home/etc files to customize their environment. Programs that need configuration data would first check/home/etc, then the machine-local/etc, and finally the master/etc.
Of course you'd need a permissions system to prevent users from over-riding critical settings.
I know both GConf and Mac OSX have taken some steps in this direction; though I don't think these capabilities are widely used.
Slashdot Mirror
So, this respected researcher has changed his mind three times in 4 months
That in itself is an interesting fact though... That a professional economist can't decide whether or not music piracy has a statistically significant effect on sales should tell you something. (even if there is a statistically significant effect, its magnitude is likely to be quite small...)
To wit, Liebowitz notes that the impact of piracy on sales is not likely to be greater than 20%. If I were a record company I would be thrilled to learn this... It means I can offer just what customers want - plaintext (DRM-free) music for sale over the internet, at various price points - which would doubtlessly offset the 20% sales impact of unlicensed uses. (keep in mind that Liebowitz' figures are based on today's large record companies, which offer virtually no legal for-pay downloads of popular/hit music)
(but the RIAA is not thrilled, which should tell you that piracy isn't what worries them - its the loss of their god-like control over promotion and distribution which the internet is bringing about...)
mp3.com is pretty good. It's not P2P but I find it easier to search and download than the P2P clients I have seen. It's all legit too.
I have 3.2GB of MP3s, about half from legit online sources, half ripped from CDs. 100% of them are legit...
There is actually quite a bit of "rhyme and reason" to creating a multi-thousand-character CJK font. e.g. thousands of Chinese characters are left/right pairs, so you just have to design the few basic left halves, the few basic right halves, and then automatically generate all of the combinations. Many of the simplified characters used in the PRC can also be generated automatically from their traditional counterparts. (of course some manual tweaking is going to be required, but just know that creating a 10,000 character font isn't nearly as difficult as creating 10,000 unique designs =).
Knuth put a whole lot of effort into designing fonts for TeX, such as Computer Modern Roman and the Euler math font. Even though these would have to be converted from METAFONT to a modern encoding, I think such a conversion would still be easier than starting from scratch...
Id software is writing Doom III in C++... But yes, that's a rather tiny change after 10+ years of evolution. (there are also the various byte-code languages they've used for non-engine game logic, but most of those are still very C-like)
Always remember folks, Hollywood's goal is not to stop piracy - that's technologically impossible. They just want to ensure that every aspect of using their products is controlled and paid for.
Want to see Snow White once on your TV? That'll be $2.50. Want to watch the making-of documentary? $2.00 more. Listen to the soundtrack for up to one month? $3.50. Send a 30-second clip to five friends? $1.50. Download the movie for use in one portable player device? $5.75...
In economic terms, it's perfect price discrimination - by nickle-and-diming consumers on every use of media, the industry will reduce the consumer surplus to zero, transferring it to their producer surplus. In other words, be prepared to pay more for the media you're getting now, or plan on reducing your consumption...
And what about independent non-major studios? They'll sure have a hard time producing content when low-cost digital editing systems become illegal. And of course the encryption keys that make this whole system work will only be available to studio distributors...
There was an interesting panel on this subject at SIGGRAPH a few weeks ago. An attendee from Pixar said that their main issue now is that their scenes are so large that it's becoming impractical to keep them in memory throughout the entire render, even with a smart acceleration datastructure (Pixar's Renderman, although fundamentally a rasterizer, needs to keep at least bounding boxes for the entire scene in RAM due to its "bucketing" process). Also he noted that many of Pixar's scenes are I/O bound - it takes longer to read the geometry and textures over the network than it takes to actually render them!
The gentleman went on to describe Pixar's work on a new renderer which (if I heard correctly) goes to the extreme of keeping no scene data permanently in RAM, and just streams primitives in and splats them to the screen.
So, while most rasterizers are indeed O(n) in the number of geometric primitives, a raytracer or other retained-mode renderer could be "O(n + log(n))", if you count the I/O required to read the scene and build the in-memory representation!
Of course I've conveniently ignored the fact that Renderman and its siblings cannot handle any sort of non-local lighting computations. (true reflections, shadows, ambient illumination, etc). But all of the high-end 3D studios seem to prefer "faking" these effects (with shadow/reflection maps or separate "ambient occlusion" passes) rather than taking the extreme speed penalty of a retained-mode renderer.
(incidentally the same sort of issue came up at Digital Domain's presentation on their voxel renderer - although they started out using volume ray-marching, the render times got so long they switched to voxel splatting, and used various tricks to make up for the lower image quality)
I think the point of their process is to avoid multiple 35mm generations between the camera negative and release print. If you blow up the camera negative to 70mm and stay at 70mm throughout the print-making process, the result will look (marginally) better than a release print made from 35mm intermediates.
Of course this process isn't going to achieve the same quality as if you actually recorded 70mm film in the camera. But cutting out one or two generations of 35mm printing can help - e.g. SW:Episode II had very little grain in the film release prints, since they were all first-generation copies of ILM's digitally-recorded negatives.
By playing the music we play, we encourage those listeners to go out and buy CDs. Apparently the RIAA doesn't understand that. Somehow, allowing people to hear a SAMPLE of music the RIAA produces, encouraging people to buy a full album, is considered piracy to them.
Ah, but when people are listening to (airwave) radio, they are listening to/sampling what the RIAA wants them to hear. With internet radio, they don't have that element of control. So they'd rather shut you down than have you promoting artists who you may like but who are not on the industry's schedule of who gets to be a hit. (or, god forbid, artists who have not signed away their soul to a major studio)
Now that several companies are producing OpenGL hardware that is somewhat comparable to NVIDIA's, all it's going to take for me to switch is for one of them to have a completely open-source driver. I am tired of recompiling NVIDIA's driver manually for every kernel update, waiting for updates from them, and forget any platforms other than x86 and ia64...
Cards are so fast these days, I'd gladly sacrifice a 25-50% performance edge for the portability and reliability advantages of an open-source driver. ATI, Matrox, Trident - I'm waiting...
BTW I worded my original post very carefully. I know lots of independent producers are making great films with cheap digital equipment (eg DV) - you're just not able to see them in major theatres (yet), and they have quite an uphill battle to obtain marketing dollars and distribution outlets...
I also know it's possible to author simple DVDs with e.g. Apple's iDVD, but those won't have studio-level features like a Dolby Digital soundtrack, a full menu system, etc... Both of which can be had for a modest ($2K-$10K) investment in software, but good luck trying to produce a CSS-scrambled, region-locked DVD (which distributors might demand) on your own =).
Hollywood's biggest fear is not piracy... It's that someone will be able to create and distribute a popular feature film outside the studio system. That would be the beginning of the end of their monopoly on popular film and hence culture.
Like DVD, expect it to be extremely difficult to author a properly formatted and encrypted HD DVD (not ripped from an existing one)...
That may have been Pixar propaganda =). I saw Larry Gritz a few times at SIGGRAPH; he seemed to be in good spirits. (Larry was the main developer of Entropy, after creating BMRT). He certainly didn't act like someone had just taken his livelihood out from under him...
The sad part is that Pixar could probably hit a lot more renderers. Deep shadow maps aren't widely used yet, but jittered sampling (another Pixar patent) is... (this may be why the "jittered antialiasing" setting in Lightwave is still a "secret" feature =).
Does anyone have the real info on Exluna? I see now that they've discontinued Entropy and BMRT, but I thought that was mostly because of being purchased by NVIDIA. (my hunch is these products will reappear in the near future as the first hardware-accelerated Renderman renderers =)... But since the settlement with Pixar is secret, I guess we may never know?
If Apple switched to x86 chips I'm sure they would add some proprietary BIOS or something to prevent the OS from running on non-Apple PCs.
To its credit, Apple already has one successful CPU architecture shift behind them (680x0->PPC). So they have experience dealing with the compatibility issues. (though said experience included writing a 680x0 emulator for PPC; it'd be a big project to do a fast PPC emulator for x86...)
You hit the nail on the head... Current CG tools make very inefficient use of artist time. It's hard to put together an animated short (of decent quality) on any kind of constrained schedule.
I estimate that 70% of labor time on my recent NASA animations (maasdigital.com) was devoted to mindless tedium like queueing up renders, splitting scenes into different elements for compositing, shuttling video files through different editing systems, etc. The actual creative work got lost in the noise.
But solutions are coming. Maas Digital is working on much better tools; just watch us =).
[/shameless plug]...
GCC 3 has been very buggy recently. I tried the GCC 3.1 release in Debian testing a few weeks ago - I quit using it immediately when I discovered that G++ neglects to destroy objects on the stack after an exception is thrown. Also, starting with GCC 3, all C++ programs are required to link with libgcc (which has had binary compatibility problems)...
So, for my own C++ development work I am still stuck with Redhat's relatively stable 2.96-98 release.
Maybe Apple has fixed some of these things?
FLTK is an excellent toolkit. I have used many over the years (Gtk, Qt, TK, and Win32 all quite extensively), and FLTK is my current favorite. It is dead simple (in a good way), clean, fast, and doesn't constrain your code as much as other toolkits do...
BTW Am I correct in assuming that the upcoming public release of Nuke is going to be FLTK-based?
Well there's just one extra check I'd love to see patent examiners do - use Google and do a search on each of the claims. That alone would probably weed out 70% of the obvious crap =).
I should add that some programs (e.g. Adobe Premiere 6.0) have audio sync problems dealing with very long DV files. I suspect this is because DV allows the number of audio samples per frame to vary by a tiny bit, whereas the software expects to see a fixed number of samples each frame.
I work with multi-GB DV files every day, recorded with dv1394 or encoded using the MainConcept codec. A DV file is simply a continuous stream of 120KB frames; there is no meta-data or index as with MOV and AVI, so there is no inherent length limitation.
The root of this whole 2GB mess is that old file access APIs and file formats used signed 32-bit quantities for file sizes. 64-bit file access APIs have been available for years now, and both MOV and AVI file formats have been extended to support 64-bit sizes. But sadly there is still a ton of software out there (including Quicktime!) using the old 32-bit formats...
I forgot to specify that I was using the Windows version =). I never used the Mac version of QT5 so I don't know if it had the same limitations.
My primary goal is to become independent of proprietary multimedia libraries. I like using uncompressed AVIs because I know enough about the file format to write them without help from any external libraries. If worst comes to worst I could probably find a way to write uncompressed MOVs myself too. (I know there is a free Quicktime library; but is the file format actually documented anywhere?)
Yes, the OpenDML extensions allow AVI files over 2GB, and I use them routinely. The problem is that Quicktime 5 only supports old-style (VfW) AVI files, meaning it won't find any data beyond 2GB.
A different issue is that Quicktime 5's DV stream reader also does not recognize data beyond 2GB.
Apple needs to wake up and start using 64-bit file APIs. I know they can do this because QT5 does support MOV files larger than 2GB!
(I need DV support because my own software reads/writes raw DV streams, and I need large AVIs because uncompressed AVI is my standard video format; uncompressed Quicktime is much less common in my work)
Does anyone know if Quicktime 6 supports AVI and DV files over 2GB? Quicktime 5 cuts off all video beyond the 2GB mark on AVI and DV files.
If you are going to change the format of /etc, then I think it would also be a good idea to implement something I've really been missing - transparent overlays. I'd love to have a "master" set of configuration files somewhere on the network that would provide defaults for all machines in the company. Then each individual machine would only have a very few files in /etc, to make whatever machine-specific customizations they need (eg whether or not to run a webserver). And finally each user would have his/her own set of /home/etc files to customize their environment. Programs that need configuration data would first check /home/etc, then the machine-local /etc, and finally the master /etc.
Of course you'd need a permissions system to prevent users from over-riding critical settings.
I know both GConf and Mac OSX have taken some steps in this direction; though I don't think these capabilities are widely used.