From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ffe4fb1477fe67e6 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: Newbie Needs Ada Advice References: <1178212418.538270.283700@c35g2000hsg.googlegroups.com> <1178635220.859690.3310@y80g2000hsf.googlegroups.com> <5abtplF2n3855U1@mid.individual.net> <1178650313.462774.91850@e51g2000hsg.googlegroups.com> <1178659640.093325.10510@y5g2000hsa.googlegroups.com> From: Markus E Leypold Organization: N/A Date: Tue, 08 May 2007 23:56:24 +0200 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:gpHSa+EI+zqkCchhXkYkx/lgzZk= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.74.36.55 X-Trace: news.arcor-ip.de 1178660878 88.74.36.55 (8 May 2007 23:47:58 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!storethat.news.telefonica.de!telefonica.de!news-fra1.dfn.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news1.google.com comp.lang.ada:15664 Date: 2007-05-08T23:56:24+02:00 List-Id: ezkcdude writes: > On May 8, 4:21 pm, Markus E Leypold > wrote: >> ezkcdude writes: >> > All helpful responses. Thanks. One idea that now makes some sense >> > (having thought about it for all of a couple of hours), is that the >> > GUI/interface could be a separate application that simply sets up the >> > experiment (i.e. microscope configuration). For example, creating an >> > XML document with appropriate hardware parameters, and then feeding >> > this document to the "engine", which actually controls the microscope. >> >> Don't use XML for that. Overkill. Just plain old tagged data lines >> >> param1 2342.2423 >> param2 32423.234 >> >> or even a 1-line per call >> >> CALL function_name 1212 123123 123 1112 >> >> will suffice and be more readable. Imap uses lispish lists as interface. >> >> Regards -- Markus > > Well, maybe if I explain the experiment better, it will make more > sense, why I can't do this so simply. Basically, we do time-lapse > imaging of several (living) specimens (usually quail embryos, but > could also be cell culture) over the course of a few hours to days. > For each specimen, there are several illumination modes (brightfield + > 1 or more fluorescence channels). On top of that the microscope stage > is moved to several overlapping "tiles" for each specimen, so a > widefield montage can be later stitched together in post-processing. > Finally, we capture several slices in the z-direction, which can be > collapsed according to a focus score (sort of like an auto-focus > routine). Again, that can be done in post-processing. Anyway, to > illustrate, here is a typical example: > > Experiment: > 6 embryos > 2x4 tiles > 7 z-planes > 3 illumination modes > 12 minutes/frame (5 frames/h) > > Each grayscale image that is acquired is about 635K, so for one 12- > hour experiment, we're acquiring 6*8*7*3*5*12*635K~38GB! > > And I need to mention that the embryos do not simply stay put, they > can move around enough that periodic adjustments to the microscope > must be made. That is why it is so important to have some graphical > feedback. I must be able to make sure the embyro is positioned > correctly, and this will obviously vary from embryo-to-embryo and > between experiments. Well, if that still sounds easy to you... Just think RPC and choose a suitable data format for your protocol. Calling a "remote" function would just be writing a record in a given format and waiting for an answering record. I doubt XML will give you much benefit there, esp. with pcitures. Concerning pictures: I suggest you write them into a picture queue in the filesystem and don't pass them through the RPC interface. What you pass through the interface would just be the file names. If your GUI or tools want to manipulate images (i.e. removing them while encoding them to another format), you need a protocol so that different tools can operate on the image store, i.e. some way to lock the store and make changes in it known to all participants. Recently I've been playing with the idea to use the maildir protocol for something like this, because it mostly eliminates the necessity of locking. Regards -- Markus