Maybe, maybe not. If they were thinking inside the box and shooting frame by frame, then sure, they would benefit from doing a 35mm conversion, first. But, it might have been easier to just rig up a LINE SCANNER and pull the film across that scanner slowly. Then software can convert the line scan into frames and figure out the color sync. In later talkies, the software could also convert the optical audio side tracks, too. Full line scan would include everything out to the sprocket holes which would be an aid to the software to get everything lined up. All you need is a line scanner big enough for the film in question, or a lens to re-project as needed. These things would be the best way to scan even all modern film into digital, too. Some of them have as much as 32K pixels per line. For B&W color rotated film like the subject of this article, no color filters are needed in the scanning as the software will figure that out. For modern color films, the light source can be RGB sequencing of an LED light source, and again no color filters.
If projecting three colors, even if in different time phases, you use red, green, and blue. Since those are primaries, this does give the best color saturation. But it also has the downside of reducing exposure more than secondaries (a problem that still exists even for today's digital camera through the tiny array of color filters).
But with a color filter loop film, the filter frame would have the same mechanism that holds the film still for each exposure. Just run the two like mechanisms locked together from the same crank or motor. It would require twice the force to do it.
Use the same mechanism that is used to transport the film, to transport color filters arranged in a film-like loop (multiple of 3 frames). Then interlock these mechanisms so you don't end up skipping or double shooting a color during shooting. Put color chips on the slate at the start and leave the camera rolling from slate to program. The film, of course, would be at the objective focal plane. The color filters would be out of focus just behind the lens (this would probably still handle an aperture up to f/1.0).
Projection would then need to get the right color synchronization... one of three states. A similar setup with an an unlock and rotate control for the projectionist to get the colors right could then be used in the projector.
Or a color filter that rotates in some way. One way could be a strip of filter film in a loop (of some multiple of 3 frames) the same size as being shot (35mm ?) being rotated with a mechanism similar to the film transport mechanism. It just needs to syncronize the two film mechanisms together in the camera, and expose an extra marker somewhere to show where the start is. That or someone guesses the start later on through use of standard color chips in the slate. Once that is done, then it's just a matter of getting the projector synchronized. That would be a bit harder, but not all that much harder. If it can be started in-sync between film frames and color filters, and stay that way (not slip), then someone has to do it at just the start.
So add dampening. I suggest the sliding window scheme. Trades are confined to a window of pricing. The window itself SLOWLY moves to bring average recent trade prices to its center. Long term investors look at the window and set their price according to how they believe the window will move during the day. When an HFTer is willing to trade at the LTIer price, then the LTIer is in (or out). Valuation of position is then reported from the center of the window.
The money isn't so sure against other HFTers. And long term investors can set a target price and it will either get that price or won't get in (or get out as the case may be). The real problem with HFT is the algorithms can lead to chaos, and can do it fast.
If a stock is bouncing up and down by one penny every few milliseconds, that by itself is no risk to the public, which is not trying to beat the HFT and is really just buying in for the long term. Where the great risks exist is wide price swings which can happen as an artifact of these algorithms operating so quickly.
My proposed fix for this is "price windows". Within the window, prices are allowed to move rapidly. The window is also allowed to move to accommodate a pricing direction, but only at a controlled SLOW rate, and only when needed. The window movement will SLOWLY attempt to bring its center to where the recent trade prices have been, as averaged over some defined period of time. A maximum movement rate will prevent the window from moving too fast. To the long term investor, the window is now the fuzzy price.
HFT does bring increased liquidity to the market. It just needs to be better controlled to avoid those infrequent problems.
It happened when they made the law that was poorly worded to do exactly this.
Sure, judges will sometimes be smart enough to realize the law is wrong. But consider this...
I read about a case many many years ago when PCs were just becoming common, and some internet thing was just emerging. A man had trouble with his PC not working so it takes it to the PC store to have it fixed. They find his hard drive died so they put in a replacement. Being cheap bastards they grabbed a HD known to be working from another PC (not sure why) and put it in the PC to be repaired. The man got the PC back, and there was still another issue, so he went for repairs again. This time they detected child porn on the HD that had been replaced in the previous visit, and called police (as the law required them to do). This man's life was ruined. He wife divorced him. He lost his job. He spent a few weeks in jail. His finances were wiped out by legal fees. In the end after a couple years the judge cleared him of all charges. He never even saw the child porn until a printed copy of one was shown in court. He never even accessed the files involved. He didn't even know they were there.
It is wrong to have a law that even allows this to begin to happen, since we can't have a law that makes everyone forget that it did. There are real things that are wrong enough that we do needs laws against them. But the laws need to be written by people who can thoroughly figure out all the effects. Our existing politicians aren't spending the time to even try, if even they were smart enough to do so (I'm absolutely certain 99% of them are not).
They already know it's a mess. They are just using these incompetent services because the big media companies are making that a condition of getting hosting business from the big media companies. You need to find a hoster that does the DMCA takedowns the old fashioned way, by printing them out and putting them in the INBOX of the company lawyer.
This technology was designed to find infringement.
I seriously doubt that. I think it was designed to find matching content and CLAIM it to be infringement while really having no means whatsoever to determine that.
Whether something is infringing or NOT infringing, cannot be determined by matching content alone. Anything that only looks for matching content is intrinsically and fundamentally broken. Anyone who would design it that way and claim it to be correct is a liar and a fraud.
A hammer is not expected to detect if the target happens to be a screw. Claiming something merely detects that some content matches some other content is fine. Jumping to the conclusion that because it matches, it must therefore be infringing is stretching truth beyond the breaking point. I am not impressed by it at all because it clearly is a failure to determine whether content is, or is not, actually infringing.
The people who think THESE things are so important (and there should be a LOT of such people) need to do EVERYTHING they can to be sure the system works ABSOLUTELY CORRECTLY from here on out. Otherwise the internet WILL work around the flaw of these misprogrammed incompetent bots, and then their goals of blocking things like child porn will not be able to succeed. This is the dire warning they need to heed, and join in the effort to fix the seriously broken copyright enforcement system. ANY one of them that does not shout out against the RIAA and MPAA and others that are ruining things loses any right to expect the changes in the internet to consider their needs.
So don't use Ustream for anything in the future. Boycott stupidity. Boycott founders John Ham, Brad Hunstable, and Gyula Feher. Boycott their venture capitalists Doll Capital Management, Labrador Ventures, and Band of Angels and everything these guys provide funding for.
10x is an extreme overestimate. The actual figure depends on the skill of the programmer. C can in fact increase the programming time. But that increase is also bringing in thinking about how you make the solution work. Skilled programmers that understand what is going on can get that ratio down near 1x. Sadly, many projects just don't have the skilled programmers available, and simply would never succeed with C, and must use something cool like Python or Ruby. And I have seen programmers out there working on open source projects that would not be able to even get Hello World working reliably on their own in their preferred language. And too many projects these days are ending up as "Frankenprojects" which are not much more than a bunch of other things all bolted together. Where's the KISS principle when you need it? It seems C is holding it hostage.
... mess that computers, particular PCs, are in, blame the peripheral industry. Some of this blame also belongs to Microsoft when they made it easy in DOS and BIOS for peripheral makers to effectively add drivers. But this is a very small blame because the full scope of what we could have had not even been envisioned. Flexibility was needed for new kinds of devices and peripherals. But the peripheral industry abused this by making new devices of the same class operate differently in too many cases. Access to floppies and IDE hard drives escaped a lot of this just because those were boot devices, and adding BIOS drivers increased the price. The peripheral makers could not even establish compatibility standards within their own product lines. So many new models of a device simply failed to be compatible with the previous interface (and driver) even if all you wanted to do was do the same old things of the previous model. This was not just a case of manufacturers trying to protect some kind of intellectual property or lock people in to their own product.
What was needed was a generalized model of how a CPU based host would access peripherals. A message based model would still have provided plenty of flexibility to expand the capabilities of new devices, as well as the ability to move more device drivers into user space, outside of the kernel. Ideally, all that was needed was one message bus controller interface design, and one driver to operate it to send and receive messages and status reports. Beyond that a ring of trusted device driver processes could be used. Combined with some community and market pressure to maintain compatibility over short time frames (about 8 to 10 years), devices could easily be interchangeable with minimal driver changing.
Then every once in a while, a class of device would have its standard message interface/protocol upgraded to a new version, and it would be expected that all new devices would adopt that. And this could still be done with full compatibility with the previous version via a version code in the basic standard message header. The new version would include a standard way to access features that were generally available now and had been implemented via extensions in the previous message protocol version.
Linus is not to blame. He just gets blamed sometimes because his vision of making the Linux kernel more usable for everyone sometimes means others might have to do a little more work to keep up (any vision would, but his is the one we see).
Are these gonna be cinema aspect ratio (e.g. 64x27) or just HDTV aspect ratio (e.g. 16x9) or office computer aspect ratio (e.g. 8x5) or legacy TV aspect ratio (e.g. 4x3)? I want 4096x1728.
But which of these issues do you blame Linux associated development for? Where Open Office can't do the job, then yeah, I'd blame Open Office. And that is Linux associated. But really is it to blame, or is Microsoft to blame for trying to destroy compatibility?
Writing apps for the Linux Desktop actually can make money. One the apps are there, people will use it. But you need to get the apps there, first. And even companies like Adobe just aren't even capable of writing portable code at all.
Maybe, maybe not. If they were thinking inside the box and shooting frame by frame, then sure, they would benefit from doing a 35mm conversion, first. But, it might have been easier to just rig up a LINE SCANNER and pull the film across that scanner slowly. Then software can convert the line scan into frames and figure out the color sync. In later talkies, the software could also convert the optical audio side tracks, too. Full line scan would include everything out to the sprocket holes which would be an aid to the software to get everything lined up. All you need is a line scanner big enough for the film in question, or a lens to re-project as needed. These things would be the best way to scan even all modern film into digital, too. Some of them have as much as 32K pixels per line. For B&W color rotated film like the subject of this article, no color filters are needed in the scanning as the software will figure that out. For modern color films, the light source can be RGB sequencing of an LED light source, and again no color filters.
I'm still looking for a genuine movie FILE, not some flashy thingy meant to frustrate people from saving it.
If projecting three colors, even if in different time phases, you use red, green, and blue. Since those are primaries, this does give the best color saturation. But it also has the downside of reducing exposure more than secondaries (a problem that still exists even for today's digital camera through the tiny array of color filters).
But with a color filter loop film, the filter frame would have the same mechanism that holds the film still for each exposure. Just run the two like mechanisms locked together from the same crank or motor. It would require twice the force to do it.
Use the same mechanism that is used to transport the film, to transport color filters arranged in a film-like loop (multiple of 3 frames). Then interlock these mechanisms so you don't end up skipping or double shooting a color during shooting. Put color chips on the slate at the start and leave the camera rolling from slate to program. The film, of course, would be at the objective focal plane. The color filters would be out of focus just behind the lens (this would probably still handle an aperture up to f/1.0).
Projection would then need to get the right color synchronization ... one of three states. A similar setup with an an unlock and rotate control for the projectionist to get the colors right could then be used in the projector.
Or a color filter that rotates in some way. One way could be a strip of filter film in a loop (of some multiple of 3 frames) the same size as being shot (35mm ?) being rotated with a mechanism similar to the film transport mechanism. It just needs to syncronize the two film mechanisms together in the camera, and expose an extra marker somewhere to show where the start is. That or someone guesses the start later on through use of standard color chips in the slate. Once that is done, then it's just a matter of getting the projector synchronized. That would be a bit harder, but not all that much harder. If it can be started in-sync between film frames and color filters, and stay that way (not slip), then someone has to do it at just the start.
So add dampening. I suggest the sliding window scheme. Trades are confined to a window of pricing. The window itself SLOWLY moves to bring average recent trade prices to its center. Long term investors look at the window and set their price according to how they believe the window will move during the day. When an HFTer is willing to trade at the LTIer price, then the LTIer is in (or out). Valuation of position is then reported from the center of the window.
The money isn't so sure against other HFTers. And long term investors can set a target price and it will either get that price or won't get in (or get out as the case may be). The real problem with HFT is the algorithms can lead to chaos, and can do it fast.
... Heisenberg's Uncertainty Principle. Don't observe the price too closely.
If a stock is bouncing up and down by one penny every few milliseconds, that by itself is no risk to the public, which is not trying to beat the HFT and is really just buying in for the long term. Where the great risks exist is wide price swings which can happen as an artifact of these algorithms operating so quickly.
My proposed fix for this is "price windows". Within the window, prices are allowed to move rapidly. The window is also allowed to move to accommodate a pricing direction, but only at a controlled SLOW rate, and only when needed. The window movement will SLOWLY attempt to bring its center to where the recent trade prices have been, as averaged over some defined period of time. A maximum movement rate will prevent the window from moving too fast. To the long term investor, the window is now the fuzzy price.
HFT does bring increased liquidity to the market. It just needs to be better controlled to avoid those infrequent problems.
It happened when they made the law that was poorly worded to do exactly this.
Sure, judges will sometimes be smart enough to realize the law is wrong. But consider this ...
I read about a case many many years ago when PCs were just becoming common, and some internet thing was just emerging. A man had trouble with his PC not working so it takes it to the PC store to have it fixed. They find his hard drive died so they put in a replacement. Being cheap bastards they grabbed a HD known to be working from another PC (not sure why) and put it in the PC to be repaired. The man got the PC back, and there was still another issue, so he went for repairs again. This time they detected child porn on the HD that had been replaced in the previous visit, and called police (as the law required them to do). This man's life was ruined. He wife divorced him. He lost his job. He spent a few weeks in jail. His finances were wiped out by legal fees. In the end after a couple years the judge cleared him of all charges. He never even saw the child porn until a printed copy of one was shown in court. He never even accessed the files involved. He didn't even know they were there.
It is wrong to have a law that even allows this to begin to happen, since we can't have a law that makes everyone forget that it did. There are real things that are wrong enough that we do needs laws against them. But the laws need to be written by people who can thoroughly figure out all the effects. Our existing politicians aren't spending the time to even try, if even they were smart enough to do so (I'm absolutely certain 99% of them are not).
They already know it's a mess. They are just using these incompetent services because the big media companies are making that a condition of getting hosting business from the big media companies. You need to find a hoster that does the DMCA takedowns the old fashioned way, by printing them out and putting them in the INBOX of the company lawyer.
This technology was designed to find infringement.
I seriously doubt that. I think it was designed to find matching content and CLAIM it to be infringement while really having no means whatsoever to determine that.
Whether something is infringing or NOT infringing, cannot be determined by matching content alone. Anything that only looks for matching content is intrinsically and fundamentally broken. Anyone who would design it that way and claim it to be correct is a liar and a fraud.
A hammer is not expected to detect if the target happens to be a screw. Claiming something merely detects that some content matches some other content is fine. Jumping to the conclusion that because it matches, it must therefore be infringing is stretching truth beyond the breaking point. I am not impressed by it at all because it clearly is a failure to determine whether content is, or is not, actually infringing.
The people who think THESE things are so important (and there should be a LOT of such people) need to do EVERYTHING they can to be sure the system works ABSOLUTELY CORRECTLY from here on out. Otherwise the internet WILL work around the flaw of these misprogrammed incompetent bots, and then their goals of blocking things like child porn will not be able to succeed. This is the dire warning they need to heed, and join in the effort to fix the seriously broken copyright enforcement system. ANY one of them that does not shout out against the RIAA and MPAA and others that are ruining things loses any right to expect the changes in the internet to consider their needs.
Isn't that like 18 trillion meters or something?
... I don't want either one of them.
So don't use Ustream for anything in the future. Boycott stupidity. Boycott founders John Ham, Brad Hunstable, and Gyula Feher. Boycott their venture capitalists Doll Capital Management, Labrador Ventures, and Band of Angels and everything these guys provide funding for.
10x is an extreme overestimate. The actual figure depends on the skill of the programmer. C can in fact increase the programming time. But that increase is also bringing in thinking about how you make the solution work. Skilled programmers that understand what is going on can get that ratio down near 1x. Sadly, many projects just don't have the skilled programmers available, and simply would never succeed with C, and must use something cool like Python or Ruby. And I have seen programmers out there working on open source projects that would not be able to even get Hello World working reliably on their own in their preferred language. And too many projects these days are ending up as "Frankenprojects" which are not much more than a bunch of other things all bolted together. Where's the KISS principle when you need it? It seems C is holding it hostage.
... mess that computers, particular PCs, are in, blame the peripheral industry. Some of this blame also belongs to Microsoft when they made it easy in DOS and BIOS for peripheral makers to effectively add drivers. But this is a very small blame because the full scope of what we could have had not even been envisioned. Flexibility was needed for new kinds of devices and peripherals. But the peripheral industry abused this by making new devices of the same class operate differently in too many cases. Access to floppies and IDE hard drives escaped a lot of this just because those were boot devices, and adding BIOS drivers increased the price. The peripheral makers could not even establish compatibility standards within their own product lines. So many new models of a device simply failed to be compatible with the previous interface (and driver) even if all you wanted to do was do the same old things of the previous model. This was not just a case of manufacturers trying to protect some kind of intellectual property or lock people in to their own product.
What was needed was a generalized model of how a CPU based host would access peripherals. A message based model would still have provided plenty of flexibility to expand the capabilities of new devices, as well as the ability to move more device drivers into user space, outside of the kernel. Ideally, all that was needed was one message bus controller interface design, and one driver to operate it to send and receive messages and status reports. Beyond that a ring of trusted device driver processes could be used. Combined with some community and market pressure to maintain compatibility over short time frames (about 8 to 10 years), devices could easily be interchangeable with minimal driver changing.
Then every once in a while, a class of device would have its standard message interface/protocol upgraded to a new version, and it would be expected that all new devices would adopt that. And this could still be done with full compatibility with the previous version via a version code in the basic standard message header. The new version would include a standard way to access features that were generally available now and had been implemented via extensions in the previous message protocol version.
Linus is not to blame. He just gets blamed sometimes because his vision of making the Linux kernel more usable for everyone sometimes means others might have to do a little more work to keep up (any vision would, but his is the one we see).
Idiots do. This is an app for the brainless.
Make your contact list be 1001 honeypots.
... Russian Android tablet?
Are these gonna be cinema aspect ratio (e.g. 64x27) or just HDTV aspect ratio (e.g. 16x9) or office computer aspect ratio (e.g. 8x5) or legacy TV aspect ratio (e.g. 4x3)? I want 4096x1728.
But which of these issues do you blame Linux associated development for? Where Open Office can't do the job, then yeah, I'd blame Open Office. And that is Linux associated. But really is it to blame, or is Microsoft to blame for trying to destroy compatibility?
Writing apps for the Linux Desktop actually can make money. One the apps are there, people will use it. But you need to get the apps there, first. And even companies like Adobe just aren't even capable of writing portable code at all.