Protocol for sending (still) pictures over network - TCP-IP

This is a discussion on Protocol for sending (still) pictures over network - TCP-IP ; Hello group, I've developing a backend for (astronomical) CCD cameras. As the camera is connected to a PC and the pictures shold be viewed some place else, I want to have a daemon controlling the driver and a higher-level protocol ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Protocol for sending (still) pictures over network

  1. Protocol for sending (still) pictures over network

    Hello group,

    I've developing a backend for (astronomical) CCD cameras. As the camera
    is connected to a PC and the pictures shold be viewed some place else, I
    want to have a daemon controlling the driver and a higher-level protocol
    in place.

    Before I brew my own thing there, is there any existing protocol so far
    which I could be conforming to? Something like POP3

    -> LIST
    <- 0: SBIG ST-9
    <- 1: SBIG ST-10
    <- .
    -> IMG SET CAMERA 0
    <- +OK Using SBIG ST-9
    -> IMG WIDTH 1024
    <- +OK
    -> IMG HEIGHT 768
    <- +OK
    -> IMG DURATION 60.0
    <- +OK
    -> INTEGRATE
    <- OK
    -> FETCH
    <- DATA FOLLOWS
    <- blablablabla (base64 encoded)
    <- .
    -> QUIT
    <- +OK Bye!

    If there was, I'd really be interested.

    Regards,
    Johannes

  2. Re: Protocol for sending (still) pictures over network

    In article ,
    Johannes Bauer wrote:
    >I've developing a backend for (astronomical) CCD cameras. As the camera
    >is connected to a PC and the pictures shold be viewed some place else, I
    >want to have a daemon controlling the driver and a higher-level protocol
    >in place.


    >Before I brew my own thing there, is there any existing protocol so far
    >which I could be conforming to? Something like POP3


    HTTP is the protocol usually used for this purpose.
    Just make your directory listing something that is easily
    parsable, and accept a GET command which has some constant
    prefix such as /image/ followed by the name of the image to fetch.
    If you don't need any real security you could probably get away
    with using HTTP 1.0 protocol, which is much simpler than HTTP 1.1 .

  3. Re: Protocol for sending (still) pictures over network

    In article ,
    Walter Roberson wrote:

    >>Before I brew my own thing there, is there any existing protocol so far
    >>which I could be conforming to? Something like POP3

    >
    >HTTP is the protocol usually used for this purpose.
    >Just make your directory listing something that is easily
    >parsable, and accept a GET command which has some constant
    >prefix such as /image/ followed by the name of the image to fetch.
    >If you don't need any real security you could probably get away
    >with using HTTP 1.0 protocol, which is much simpler than HTTP 1.1 .


    Depending on what was intended, that might be inconsistent with the
    other person's sample commands. These appear to involve more than just
    fetching existing images:

    -> IMG WIDTH 1024
    -> IMG HEIGHT 768
    -> IMG DURATION 60.0
    -> INTEGRATE

    That HTTP is now the favorite kludge for tunneling through firewalls
    and to bybase and subvert security doesn't convince me. Maybe I'm just
    hopelessly prejudiced against SOAP and worse stuff. See
    http://www.google.com/search?q=soap+http
    including
    http://en.wikipedia.org/wiki/SOAP


    If I were in the mood for HTTP kludges for such an application, I'd just use
    something like
    http://camera1.example.com?WIDTH=102...&DURATION=60.0
    or
    https://camera1.example.com?WIDTH=10...&DURATION=60.0
    with some flavor of HTTP authentication. A CGI script of a perl or
    Borne shell script or a C program invoked by the Apache HTTP server
    httpd would talk to the camera, telescope mount, and so forth. Httpd
    would deal with the HTTP authentication chitchat, the TLS stuff for
    HTTPS, as well as HTTP 1.0 vs 1.1. I suspect from what httpd does to
    some of my slower CGI scripts that it would be necessary to fiddle with
    httpd's timeouts to allow the CGI script to not answer for minutes as
    suggested by "DURATION 60.0." Or have one URL that tells the camera
    to capture an image and another URL that fetches whatever has been
    captured.


    http://www.google.com/search?q=network+camera+control
    finds a bunch of relevant sounding web pages. For example,
    http://camera-control.qarchive.org/
    starts with a link for something that "has been specifically designed
    for use with telescope cameras." See also
    http://www.google.com/search?q=netwo...escope+control

    Classic remote proocedure calls might be cleaner
    http://www.google.com/search?q=remote+procedure


    Vernon Schryver vjs@rhyolite.com

  4. Re: Protocol for sending (still) pictures over network

    On Sep 3, 11:11*am, Johannes Bauer wrote:
    > Hello group,
    >
    > I've developing a backend for (astronomical) CCD cameras. As the camera
    > is connected to a PC and the pictures shold be viewed some place else, I
    > want to have a daemon controlling the driver and a higher-level protocol
    > in place.
    >
    > Before I brew my own thing there, is there any existing protocol so far
    > which I could be conforming to? Something like POP3
    >
    > -> LIST
    > <- 0: SBIG ST-9
    > <- 1: SBIG ST-10
    > <- .
    > -> IMG SET CAMERA 0
    > <- +OK Using SBIG ST-9
    > -> IMG WIDTH 1024
    > <- +OK
    > -> IMG HEIGHT 768
    > <- +OK
    > -> IMG DURATION 60.0
    > <- +OK
    > -> INTEGRATE
    > <- OK
    > -> FETCH
    > <- DATA FOLLOWS
    > <- blablablabla (base64 encoded)
    > <- .
    > -> QUIT
    > <- +OK Bye!
    >
    > If there was, I'd really be interested.



    What not just send the JPEG (or whatever image format you prefer) as
    an email attachment. SMTP is pretty easy. A JPEG also has room for a
    lot of exposure and camera data. Or you could dump that data in the
    body of the email or another attachment.

  5. Re: Protocol for sending (still) pictures over network

    On Wed, 03 Sep 2008 18:11:27 +0200, Johannes Bauer wrote:
    > Hello group,
    >
    > I've developing a backend for (astronomical) CCD cameras. As the camera
    > is connected to a PC and the pictures shold be viewed some place else, I
    > want to have a daemon controlling the driver and a higher-level protocol
    > in place.
    >
    > Before I brew my own thing there, is there any existing protocol so far
    > which I could be conforming to? Something like POP3
    >
    > -> LIST
    > <- 0: SBIG ST-9
    > <- 1: SBIG ST-10
    > <- .
    > -> IMG SET CAMERA 0
    > <- +OK Using SBIG ST-9
    > -> IMG WIDTH 1024
    > <- +OK
    > -> IMG HEIGHT 768
    > <- +OK
    > -> IMG DURATION 60.0
    > <- +OK
    > -> INTEGRATE
    > <- OK
    > -> FETCH
    > <- DATA FOLLOWS
    > <- blablablabla (base64 encoded)
    > <- .
    > -> QUIT
    > <- +OK Bye!
    >
    > If there was, I'd really be interested.


    Very hard to tell what you want the protocol to *do*.
    What's INTEGRATE?

    If all you want is to offer a bunch of files lying around on a
    computer, I suggest using existing software. HTTP, FTP,
    rsync-over-ssh, rsync or all of them. They are better at moving huge
    data sets than anything you or I can come up with.

    If you want a protocol for controlling the camera-and-computer,
    including pointing it at the sky, yes, then I'd do something like what
    you do. But I'd skip the FETCH command and do something like this
    instead:

    STORE
    OK
    Your file is available from now and until 8 hours from now as:
    http://example.com/foo89898
    rsync://example.com/foo89898
    ftp://example.com/foo89898

  6. Re: Protocol for sending (still) pictures over network

    Jorgen Grahn schrieb:

    >> If there was, I'd really be interested.

    >
    > Very hard to tell what you want the protocol to *do*.
    > What's INTEGRATE?


    Yes, I should have been more specific, sorry for that.

    Integration of a picture in CCD-terms means "take a frame". The CCD
    picture is the integral of the photons over time.

    I found another requirement which would be nice-to-have and therefore
    makes me tend to an own solution: Suppose you have three computers. One
    is connected on the telescope camera. The other is connected to the
    telescope adjustment.

    I'll define adjustment further: The earth rotates around its axis,
    therefore stars appear to "move" on arcs. When taking pictures of dark
    objects, integration time may well be 10 minutes or more. Therefore the
    picture is blurred. The adjustment rotates the telescope in phase with
    earths rotation, so that pictures are sharp. For that there is a second
    very-high-speed, very-low-resolution CCD-seonsor in the CCD-camera. A
    program reads out that fast CCD sensor, does an autocorrelation,
    determines where the picture has moved and gives a signal to the
    telescope adjustment to compensate.

    Now with the above setup, there would be one server which should be able
    to relay connections to all parts (i.e. camera and adjustment). The user
    only connects to the main server which then does the rest.

    > If you want a protocol for controlling the camera-and-computer,
    > including pointing it at the sky, yes, then I'd do something like what
    > you do. But I'd skip the FETCH command and do something like this
    > instead:


    This is a very good idea which I will certainly use. I like relying on
    existing protocols very much because it increases the versatility of
    solutions.

    > Also ... I have a feeling astronomers are smart people with many odd
    > skills, and with expensive equipment they want to make the most of, so
    > I'd be surprised if noone hasn't solved and published the solution to
    > this problem long ago ...


    I must admit that I really had a huge smile on my face when reading your
    words, because you are exactly right: smart people with odd skills :-)
    And there is much software around for astronomers (like MIDAS), but I've
    found none which fulfills all of my requirements. That's why I hoped
    someone would know a protocol which does what I want (not only does had
    it saved me time, but I am very much a supporter of open standards).

    Regards,
    Johannes

+ Reply to Thread