Sending files - page 2 - Feature Requests - CHDK Forum supplierdeeply
« previous next »
Pages: 1 [2]   Go Down

Sending files

  • 19 Replies
  • 7251 Views
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Sending files
« Reply #10 on: 06 / July / 2008, 12:55:43 »
Advertisements
I'm offtopic, but we can't read the sensor data - only the viewport - either, right?
Why is that (as in the limitations with both microphone and sensor data)?
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Sending files
« Reply #11 on: 06 / July / 2008, 13:00:44 »
Quote from: RaduP on 06 / July / 2008, 12:36:23
The 'look at the other camera's LCD' method won't work, because it is unidirectional, so there is no way to do stuff such as synchronizing the transfer, ask for the data again if it is bad, and so on.

Oh that's certainly not a problem. Syncing can be done by putting the receiver into "receive" mode and then pressing "send" on the sending camera. If an error is detected, the receiving camera prints out an error and user knows the file must be resent.

And as for speed: about 256 bytes/s should be enough for uBasic scripts, it's 32 seconds plus headers for the maximum 8kB script. Easily faster than working with an SD card.
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Sending files
« Reply #12 on: 06 / July / 2008, 13:04:57 »
Quote from: LjL on 06 / July / 2008, 12:55:43
I'm offtopic, but we can't read the sensor data - only the viewport - either, right?
Why is that (as in the limitations with both microphone and sensor data)?

Well obviously we can. It's called shooting and then digging stuff out of the RAW buffer and then deleting the JPEG. :D

My point being that a file could be photographed off a computer display showing it as a huge data matrix, and then processed decoded off-line by the camera from a well exposed & focused RAW image.
Logged
*

Offline RaduP

  • *****
  • 908
Re: Sending files
« Reply #13 on: 06 / July / 2008, 13:05:27 »
Quote from: fudgey on 06 / July / 2008, 13:00:44
Oh that's certainly not a problem. Syncing can be done by putting the receiver into "receive" mode and then pressing "send" on the sending camera. If an error is detected, the receiving camera prints out an error and user knows the file must be resent.

And as for speed: about 256 bytes/s should be enough for uBasic scripts, it's 32 seconds plus headers for the maximum 8kB script. Easily faster than working with an SD card.

For transfering small files that's great, but if you want to transfer something bigger (an image, a firmware, etc, it will suck if you have to wait half an hour for the data to be sent, then the cat goes right in front of the camera and you have to do it all over again :D
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Sending files
« Reply #14 on: 06 / July / 2008, 13:07:57 »
fudgey, yes, but you'll agree that there are like a hundred potentially useful applications that require / benefit from reading the sensor data (or the microphone, for that matter) in real time...
I'm just asking why it isn't possible - or, isn't it.
Logged
*

Offline RaduP

  • *****
  • 908
Re: Sending files
« Reply #15 on: 06 / July / 2008, 13:09:56 »
You can't read the full sensor in real time, because you need a shutter (at least for the CCD sensors in most of the P&S cameras).
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Sending files
« Reply #16 on: 06 / July / 2008, 13:13:57 »
Hey, but the camera itself is reading the sensor in real time without using the shutter, precisely in order to update the viewport in real time... or have I got it completely wrong somehow?

(Sure, a shutter is by all odds a better means of taking a frame than just reading out and discharging the sensor periodically... but the latter is also what every webcam does)
Logged
*

Offline RaduP

  • *****
  • 908
Re: Sending files
« Reply #17 on: 06 / July / 2008, 13:19:06 »
The camera doesn't read the whole sensor, it reads only one set of lines.
For example, if you remove the shutter of a camera, and take a picture, you will get an image with 3 interlaced lines, all with a different exposure, because the camera can't read all 3 lines at once, so some will get more light.

That's why the movie mode looks bad.
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Sending files
« Reply #18 on: 06 / July / 2008, 13:27:39 »
Ah... I think I understand now.

Still, it would be interesting if one could at least read a small part of the sensor in full resolution, as it would finally allow having a more-than-2x focusing magnification (which would make manual focus actually useful for something!).

It might also help with accurate motion/stillness detection (especially as far as camera movement goes) if two adjacent lines could be read, even if full sensor is not.
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: Sending files
« Reply #19 on: 06 / July / 2008, 14:42:27 »
Quote from: RaduP on 06 / July / 2008, 13:05:27
Quote from: fudgey on 06 / July / 2008, 13:00:44
Oh that's certainly not a problem. Syncing can be done by putting the receiver into "receive" mode and then pressing "send" on the sending camera. If an error is detected, the receiving camera prints out an error and user knows the file must be resent.

And as for speed: about 256 bytes/s should be enough for uBasic scripts, it's 32 seconds plus headers for the maximum 8kB script. Easily faster than working with an SD card.

For transfering small files that's great, but if you want to transfer something bigger (an image, a firmware, etc, it will suck if you have to wait half an hour for the data to be sent, then the cat goes right in front of the camera and you have to do it all over again :D

*with fudgey* file sizes are so small that resending shouldn't be a problem... even better, the original data can be kept and only the missing parts have to be reread. Also, when using the proper ECC methods, it'll still work with (slightly) damaged frames.

This method was never used for large files in the first place, in my opinion. Even with my (optimistic) 1 kB/s transfer rate, it'll take up to an hour for e.g. an image to transfer. That's where cardreaders come in again.
Logged
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics