ATI Driver for Touch Pro

[fr4nk1yn]

I converted a DVD with too high a bitrate.
I tried this, Tried the stock D3D Pro driver and then went back to the Omnia.

I benchmarked the video with Core. While non of them were great these drivers were slower, by 5%, than stock and the Omnia was much faster.

[jmorton10]

Originally Posted by jason559

My slingplayer viewing is HORRIBLE. Went through every post in this thread and tried adjusting the encoding settings, nothing helped it.

I'm working on a fix for this, my SlingMobile works but it has never worked anywhere near as well as it did in my old Titan's running all the exact same network connections/router etc etc

I couldn't wait to try SM in the TouchPro thinking it would really work well, I can't tell you how disappointing this has been, & out of all the MANY MANY apps I have installed SM is the only one that doesn't work perfectly.

~John

[msvakos4589]

I recently installed this CAB and did not notice any difference. However, my device is acting very funny now. When someone calls me it rings once, then goes to VM now. I uninstalled the CAB, soft reset and still the same thing. Anyone else having this problem. If there something in the registry i can edit to make sure it uninstalled correctly. Thanks.

[gljvd]

I don't agree with your post at all. The camera has many over lays and is also capable of recording video. The 3d chip in the phone is capable of accelerating all that. Now if this driver actually helps do that is another matter

Originally Posted by GoodThings2Life

Maybe I'm wrong, but discussion of photography has NOTHING to do with the ATI Driver for Touch Pro.

I think it's been established by several that any impact on camera performance is nothing but placebo effect, and indeed there is nothing but foolish reason to think it would or could have an effect, so it's a good idea to get back on topic before the mods have to do some housecleaning or worse-- lock a perfectly good thread.

[cornelious2]

http://focus.ti.com/lit/wp/spry105/spry105.pdf This goes into huge and gritty detail on how the sensor and processor works in a digital camera. If anyone wants to continue this argument just read this and lets be done with this issue. (or at least start up an off topic thread) it is an on topic issue technically but its done nothing but railroad against the real issue. and yes that means I am admitting to being one of the stuborn *******s in the party.

[dr g]

Originally Posted by cornelious2

http://focus.ti.com/lit/wp/spry105/spry105.pdf This goes into huge and gritty detail on how the sensor and processor works in a digital camera. If anyone wants to continue this argument just read this and lets be done with this issue. (or at least start up an off topic thread) it is an on topic issue technically but its done nothing but railroad against the real issue. and yes that means I am admitting to being one of the stuborn *******s in the party.

Unfortunately everything in the paper is irrelevant to the discussion because it happens AFTER the exposure is done and the data is read out and placed into the pipeline. The data pipeline should NEVER affect exposure time in a properly functioning camera. Precise control of exposure time is critical to photography in general.

[Aleki]

Originally Posted by dr g

The data pipeline should NEVER affect exposure time in a properly functioning camera. Precise control of exposure time is critical to photography in general.

i feel part of the problem is what i underlined
im not saying i know how cameras should work, but i do know how a computer should run. a simple syntax error could make the difference between complete hardware integration, to poor communication.

most people claim the camera handles auto adjusts alot better. if thats the case, i could definately see how a simple software tweak could make a worlds difference in hardware integration.

to computers, atleast, running a game without proper video drivers can make the difference between an enjoyable experience or barely playable pile of crap. just as these "driver tweaks" could decrease the load from the processor so it can do a better job at taking the pictures instead of trying to draw what you see before you click capture

[cornelious2]

Originally Posted by dr g

Unfortunately everything in the paper is irrelevant to the discussion because it happens AFTER the exposure is done and the data is read out and placed into the pipeline. The data pipeline should NEVER affect exposure time in a properly functioning camera. Precise control of exposure time is critical to photography in general.

all I need to say is A.) you obviously don't have the ability to read at a comprehension level above the 2nd grade. YES the processing happens after the sensor because it has to. think of the data like water draining out of a sink a blockage in the pipe can make the water exit the sink slower regardless as to how much or little water you spray into it.

and B.) just drop it as much as you don't want to admit it you are wrong. Just stop arguing with everyone and drop it.

[dr g]

Originally Posted by cornelious2

all I need to say is A.) you obviously don't have the ability to read at a comprehension level above the 2nd grade. YES the processing happens after the sensor because it has to. think of the data like water draining out of a sink a blockage in the pipe can make the water exit the sink slower regardless as to how much or little water you spray into it.

and B.) just drop it as much as you don't want to admit it you are wrong. Just stop arguing with everyone and drop it.

Sorry, you're just plain wrong and these drivers fix nothing about the camera's exposuring whatsoever, nor would they. Digital camera sensors like the one in our phones utilize electronic shutters to control exposuring and light collection. CMOS sensors control exposure precisely by pushing data from the light-collecting pixels into the readout pipeline, when this happens, the exposure time is effectively over. Now, there is a native maximum speed of this readout for the sensor. That could possibly be an issue with our cameras, HOWEVER this is a property of the hardware itself and would not be affected by a Direct3D driver. (EDIT: I am actually now thinking the hardware read speed limit very well could be a significant issue, but there is no way to fix that short of replacing the sensor with a better one. If we could find the sensor specifications, we'd know for sure.).

There is no conceivable way the Direct3D driver could affect the exposure time of the camera.

[dr g]

Originally Posted by Aleki

i feel part of the problem is what i underlined
im not saying i know how cameras should work, but i do know how a computer should run. a simple syntax error could make the difference between complete hardware integration, to poor communication.

most people claim the camera handles auto adjusts alot better. if thats the case, i could definately see how a simple software tweak could make a worlds difference in hardware integration.

This is not a software tweak, or at least not a relevant software tweak. It's a different direct3D driver. Nothing changes about the camera software, which is what would have to change to fix the problems with the camera's exposuring.

Originally Posted by Aleki

to computers, atleast, running a game without proper video drivers can make the difference between an enjoyable experience or barely playable pile of crap. just as these "driver tweaks" could decrease the load from the processor so it can do a better job at taking the pictures instead of trying to draw what you see before you click capture

We aren't talking about video here. We're talking about single-frame photographic captures, and the issue is not with image processing but camera control. The Direct3D driver might possibly affect processing, but it would not affect camera control. The camera software affects that.