Am Wed, Apr 10, 2024 at 09:15:02PM +0530 schrieb Nilesh Patra:
> since no-one uses med packages on these archs[1].
That's certainly not so.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Am Sat, Feb 10, 2024 at 09:39:26PM +0100 schrieb Karsten Hilbert:
> Me being upstream would be OK with demoting
>
> dep:libchipard-tools -> rec:libchipcard-tools
>
> Might someone around here be able to afford the time for
> updating the Debian package metadata ac
Am Sun, Feb 11, 2024 at 12:28:14AM +0530 schrieb Nilesh Patra:
> > > gnumed-client 1.8.18+dfsg-1 is marked for autoremoval from testing on
> > > 2024-03-15
> > >
> > > It (build-)depends on packages with these RC bugs:
> > > 1062249: libchipcard: NMU diff for 64-bit time_t transition
> > >
Dear list members,
Debian packaging CI is sending me this:
> gnumed-client 1.8.18+dfsg-1 is marked for autoremoval from testing on
> 2024-03-15
>
> It (build-)depends on packages with these RC bugs:
> 1062249: libchipcard: NMU diff for 64-bit time_t transition
> https://bugs.debian.org/1062249
> > If we cannot find this documentation within roughly the next 24 hours, I
> > will have to find a way to get the images we need using gnome-screenshot.
> > aeskulap appears not to be designed to be driven from the command line, so I
> > may have to use some terrible workaround like extracting
Am Fri, Nov 11, 2022 at 09:57:36PM +0100 schrieb Andreas Tille:
> Am Fri, Nov 11, 2022 at 07:39:53AM -0800 schrieb L Peter Deutsch:
> > Dear M. Pipelka and M. Tille,
> >
> > I found your names and e-mail addresses on the aeskulap man page.
> >
> > A hospital has provided us with a CD of CT scans
Am Wed, Oct 12, 2022 at 09:08:47AM -0300 schrieb Leonardo M. Ramé:
> Good news!, Horos shows the image exactly as the software from Carestream.
> Now it's a matter of looking at their source code.
Ha ! Now *that* is interesting. I am pretty curious as to
what they do ...
Karsten
--
GPG 40BE
Am Fri, Jul 29, 2022 at 09:56:05AM +0200 schrieb Andreas (Debian):
> I wonder if there is some decision about the naming scheme. I *really*
> want to get the CVE bugs fixed. Users might consider Debian packages
> useless otherwise.
As far as I remember the "Mumps community" considers each and
Am Sun, Feb 13, 2022 at 12:15:13AM +0530 schrieb Mayuresh:
> Please do have a look at a sample header attached. If you find any fields
> that may give any hints about the calibration or post processing that the
> vendor software applies, please do highlight.
The only fields appearing relevant
> > Please do have a look at a sample header attached. If you find any fields
> > that may give any hints about the calibration or post processing that the
> > vendor software applies, please do highlight.
>
> E.g. this (undocumented aka Private) tag's value seems to be varying
> across images:
>
Am Mon, Jan 03, 2022 at 10:31:32AM +0100 schrieb Jakub Wilk:
> You may want to give CLAHE (Contrast Limited Adaptive Histogram Equalization)
> a try.
>
> It's implemented in OpenCV.
For what it's worth, here's code which so does:
#!/usr/bin/env python3
import cv2
import numpy as np
image =
Am Tue, Dec 21, 2021 at 01:04:21PM +0530 schrieb Mayuresh:
> Would appreciate some inputs on figuring out the transformation from [3]
> to [4] - brightness, contrast, gamma etc. and suitable tools (preferably
> non interactive) to carry them out.
imagemagick would be scriptable
Karsten
--
GPG
> > Maybe it helps to get someone with artistic (?) or (or best: and)
> > graphics processing experience to look at both images. A
> > seasoned digital photographer is likely to have a good idea
> > as to what transforms to apply in their favourite photo
> > processing application to make one more
> Maybe it helps to get someone with artistic (?) or (or best: and)
> graphics processing experience to look at both images. A
> seasoned digital photographer is likely to have a good idea
> as to what transforms to apply in their favourite photo
> processing application to make one more like the
> Printing a map between raw and transformed pixel values shows that for a
> given raw pixel value there are multiple transformed values i.e. the
> transformation is not a function of pixel's value alone. It seems some
> sort of filtering where the neighboring pixels also influence the
>
- Weitergeleitete Nachricht von Karsten Hilbert
-
> Date: Fri, 24 Dec 2021 10:10:34 +0100
> From: Karsten Hilbert
> To: debian-med@lists.debian.org
> Subject: Re: Acquiring Dental RVG on Linux
>
> > My main problem right now is to figure out the transformation t
Am Sat, Jul 10, 2021 at 03:05:36PM +0200 schrieb Rob van der Putten:
> Which Debian packages support the ASTM lab equipment (over TCP) protocol? An
> overview
> would be nice.
For what that's worth a quick search
libcacard-dev - Virtueller Emulator für Common Access Cards (CAC) -
Am Mon, May 10, 2021 at 03:30:24PM +0530 schrieb Nilesh Patra:
> >Would you or someone you know be interested in sponsoring a medical
> >physics reference manual and (second-check) calculator for inclusion in
> >the Debian repository? I am thinking to write one as a useful
> >compendium
> >of
Am Sun, Jan 17, 2021 at 06:36:49PM +0100 schrieb Hilbert, Sebastian:
> When you talk about the comparison, are you comparing an image displayed
> inside
> their software/viewer to an image that gets reconstructed from the DIY driver
> ?
That is what I did, yes. Or, rather, a jpeg *produced* by
test
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Am Sun, Jan 17, 2021 at 08:44:54AM +0530 schrieb Sonali Warunjikar:
> http://mayuresh.sdfeu.org/snaps.zip
>
> vendor.jpg: using vendor software which seems to adjust `something'
>
> ours.png: ours, appears underexposed
>
> raw.dat: raw sensor data 12 bit little endian 0 padded (a program to deal
Am Sun, Jan 17, 2021 at 08:17:38AM +0530 schrieb Sonali Warunjikar:
> > It alludes to LUT
> That is IDENTITY. It would almost certainly mean no transformation.
>
> > and Rescale
> Intercept 0 and scale 1 again means there is no transformation.
>
> > and Pixel Intensity Relationship
> Its linear.
CareStream about exposure
https://www.carestream.com/blog/2016/09/06/understanding-radiology-exposure-indicators/
digital x-ray postprocessing:
Am Sat, Jan 16, 2021 at 11:11:21PM +0100 schrieb Karsten Hilbert:
> http://www.44342.com/network-protocols-f546-t2480-p1.htm
>
> https://forum.dcmtk.org/viewtopic.php?t=1075
I have downloaded the R1.rvg and looked at its metadata.
ExifTool
ExifToo
I have, for what it helps, searched the web for some more
information regarding the RVG type of DICOM file.
Maybe some hints can be gleaned from that:
http://www.44342.com/network-protocols-f546-t2480-p1.htm
https://forum.dcmtk.org/viewtopic.php?t=1075
Karsten
--
GPG 40BE 5B0E
Am Fri, Jan 15, 2021 at 04:28:47PM +0530 schrieb Sonali Warunjikar:
> > Because, perhaps, it learns of low-exposure from the sensor,
>
> The app does remark about under / over exposure, but I think it's
> inferring it from the image data. This is because we have instrumented all
> interactions
Am Fri, Jan 15, 2021 at 12:16:37PM +0530 schrieb Sonali Warunjikar:
> For mid to high exposures the quality is matching that of the vendor
> application. For low expsoure the vendor app does much better.
Would you be willing to post a vendor app image and an
Elephant version thereof ?
Maybe
Am Sun, Jan 10, 2021 at 09:28:09AM +0530 schrieb Sonali Warunjikar:
> - Simple normalizations to utilize the full contrast and reduction in
> brightness or any other manual adjustment to contrast and brightness
> does not make up for less exposure in our application, whereas vendor
>
> - Simple normalizations to utilize the full contrast and reduction in
> brightness or any other manual adjustment to contrast and brightness
> does not make up for less exposure in our application, whereas vendor
> application manages to get it right with the same exposure level.
>
> -
> On Saturday, January 09, 2021 03:36:21 AM Karsten Hilbert wrote: > Maybe
> offer for display what the needed tools can consume, but retain > the
> original depth as a backup. Over here it wouldn't even be legal > to discard
> data due to its having been obtained
> On Wed, Jan 06, 2021 at 05:13:58PM +0530, Sonali Warunjikar wrote:
> > I think distance calibration is over. Now over to other image parameters.
>
> Some observations about depth (bits per pixel):
>
> - The proprietary software is producing images with only 8 bit depth,
> throwing away half of
draw four lines touching the circle, each pair at 90°
draw a line splitting each 90° in half (at 45° that is) going through the circle
the intersection of those two midlines should be the centre of the circle :-)
better: fit a square around the circle ...
Karsten
> Gesendet: Dienstag, 05.
Am Sun, Jan 03, 2021 at 10:42:23AM +0530 schrieb Sonali Warunjikar:
> > Test his code with another RGV5200 sensor. I would try to find
> > dental office IT user groups and ask if anyone owns that sensor
> > and would be willing to test ...
>
> The problem is: it limits the universe to those whom
Am Sun, Jan 03, 2021 at 02:18:25PM +0100 schrieb Karsten Hilbert:
> Maybe I'm wrong but I suppose that is because "exposure"
> isn't really a image characteristic, is it ? Now, in optics,
> as in photography, it is the combination of aperture and
> shutter speed, IOW, to &
Am Sun, Jan 03, 2021 at 10:29:42AM +0530 schrieb Sonali Warunjikar:
> On Sat, Jan 02, 2021 at 09:25:38PM +0100, Karsten Hilbert wrote:
> > Then, manually with, say, GIMP, adjust exp/br/y/contrast until the raw
> > capture "looks like" the one shown by CareStream softwar
Am Sun, Jan 03, 2021 at 12:41:49PM +0530 schrieb Sonali Warunjikar:
> On Sat, Jan 02, 2021 at 06:55:12PM +0100, Karsten Hilbert wrote:
> > Eventually, Kodak started marketing its sensor via CareStream.
>
> Rather Kodak sold its healthcare business: "In 2007, the Kodak Hea
Am Sun, Jan 03, 2021 at 12:07:27PM +0530 schrieb Sonali Warunjikar:
> On Sat, Jan 02, 2021 at 06:55:12PM +0100, Karsten Hilbert wrote:
> > Removing the Trophy USB IDs from the hardware and putting in the
> > Kodak USB IDs may have carried the risk of needing to re-certify
>
Am Fri, Jan 01, 2021 at 11:56:46PM +0530 schrieb Sonali Warunjikar:
> Have also placed a call with the retailer regarding calibration. They said
> they'll get back but I doubt whether they even understood the question.
I can entirely feel your pain ...
> Next question will be to choose the
Am Thu, Dec 31, 2020 at 02:15:33PM +0530 schrieb Sonali Warunjikar:
> The proprietary software directly gives a DICOM file
I think it'd be interesting to see what
exiftool -g1 -ee -m -u $THE_DICOM_FILE
has to say. Perhaps one can retrieve some hints for further
processing of the raw
As for the "best" post-processing settings for the raw image could the
following scenario help ?
- setup a passthrough, logging, usb monitor
- capture an x-ray image with the Windows software
- simultaneously capture the raw image within the monitor
Then, manually with, say, GIMP, adjust
> If someone else had a sensor and could make the current code work as is, this
> would exclude a license in unique to the sensor
That's exactly what was proposed.
Next step would be to identify another user of said
sensor who'd be willing to have the code run.
Karsten
> The company being acquired is correct. The license stuff is a different
> story. The license check might entirely happen in their
> commercial software. In other words talking to the device might be possible
> without any license check. If one knows how to talk to the device.
>
> This theory
> Given this (page 5)
>
>
> https://www.atlasresell.com/sites/default/files/KodakTrophyWindowsGuide.pdf
and this
http://www.unident.ru/en/news/Carestream-120-years-in-the-service-of-dentistry-13633.phtml
:-o
Karsten
Given this (page 5)
https://www.atlasresell.com/sites/default/files/KodakTrophyWindowsGuide.pdf
I've got a theory on the two devices:
Once upon a time an x-ray sensor was developed and
certified by Trophy.
Later, Trophy was acquired by Kodak.
Eventually, Kodak started marketing its
> The latter is coming closer to the reality, but not sure it's accurate
> enough as yet. May be there was a gap between the finger and the sensor
> when trial x ray was taken as our attention was on usb interface rather
> than lengths (getting computed length smaller than the actual one of the
>
> [1] confirms the pixel size to be 19 micro. pypng does have a way to
> supply it. Now it's reporting sensible distances, but have to check and
> see if there are calibration issues.
>
> BTW any idea, what "True (measured) resolution = 16lp/mm" means in [1]? It
> seems it's called line pairs per
> It is showing the length of index finger distal phalanx close to 1ft! (I
> assure that's not the reality!)
:-)
> Can anyone suggest which field it is? (Another point in favor of DICOM,
> but let me sort out the issue with a generic image first.)
Sure, I would first get one image format
> On Fri, Jan 01, 2021 at 09:19:34AM +0100, Karsten Hilbert wrote:
> > https://www.sodiumdental.com/kodak-rvg-6000-calibration-file/
>
> Nice hint. Will try and follow. But another way as I said in previous post
> is to get them with an interactive viewer and apply up fro
> With the discovery of hidden device I feel it's the contrary now. The
> licensing might be tied to the driver.
Hmm, one can download a driver here
https://sqps.onstreamsecure.com/origin/csdental/CSD/Downloads/RVG4-6-9-C.zip
If that's the genuine driver, and the driver "contains" the
> > Install a freshly downloaded version (say, a trial version) of your
> > imaging software (or of another software documented to support your
> > sensor). Plug in the sensor and monitor the USB flow.
>
> Or, since the sensor offers a TWAIN driver, you might try to install that
> and access the
> On Fri, Jan 01, 2021 at 09:09:48AM +0100, Karsten Hilbert wrote:
> > Or, since the sensor offers a TWAIN driver, you might try to install that
> > and access the sensor using any old TWAIN compatible scanning software.
>
> On this list or on sane-devel I am told TWAIN is a
> The traces to play back are learned from a machine with license installed,
> without which there was nothing to learn. They do play back fine on a
> different machine.
>
> To check what is tied to the license and what is not I'll need a different
> device rather than a different machine.
Yeah,
> Another idea: get an entirely fresh machine (laptop/VM) that never knew
> anything of your clinic/sensor before. A Windows machine, that is.
>
> Install a freshly downloaded version (say, a trial version) of your
> imaging software (or of another software documented to support your
> sensor).
> I'll refine the code a bit and open it up. But the unfortunate nature of
> such exercise is where I have a driver but I do not 'know' the protocol. I
> am merely playing back the traces and those traces could be tied to my
> license key.
Another idea: get an entirely fresh machine (laptop/VM)
> I'll refine the code a bit and open it up. But the unfortunate nature of
> such exercise is where I have a driver but I do not 'know' the protocol. I
> am merely playing back the traces and those traces could be tied to my
> license key.
You don't, by any chance, happen to be able to access
> would give much more credit to ... your own persistence.
Very true. Pulling this off is quite a feat unless one is
a fairly experienced hard/soft tinkerer.
Karsten
> Yes, it's now closer to a real X ray. The Dr still sees some problems, but
> I think it will need some experiments with exposure, brightness and
> contrast.
Typically, there's presets for those but as a doctor one always plays
with them such settings during the diagnostics process.
So, I
> On Thu, Dec 31, 2020 at 02:15:33PM +0530, Sonali Warunjikar wrote:
> > Now the USB layer is as such over. The challenge now shifts to the format
> > of the data gathered.
I would also try the following:
- create a small loopback filesystem
- mount it
- fill it with a nulls-only file (cp from
Am Wed, Dec 30, 2020 at 07:01:47PM +0530 schrieb Sonali Warunjikar:
> On Wed, Dec 30, 2020 at 02:27:41PM +0100, Karsten Hilbert wrote:
> > That 'C' does NOT occur unless you issue the first 'S' ? Or
> > does it, after some timeout ?
>
> It occurs after timeout. So I should
Am Wed, Dec 30, 2020 at 09:55:54AM +0530 schrieb Sonali Warunjikar:
> To be precise I do not know how to issue two back to back 'S' without a
> 'C' occurring in between.
Theoretically there is no way to do so:
Since you don't issue the 'C' you can't control when (after
the first 'S') it
Am Tue, Dec 29, 2020 at 03:10:37PM +0530 schrieb Sonali Warunjikar:
> On Mon, Dec 28, 2020 at 06:48:47PM +0530, Sonali Warunjikar wrote:
> > Right now I am stuck with 'Timeout error' when processing Ii event
> > (interrupt read). Have written to pyusb mailing list as well. Any help
> > here will
Am Sun, Dec 27, 2020 at 09:35:16PM +0530 schrieb Sonali Warunjikar:
> Something remarkable happened. After playing back the initialization
> sequence the usb device talked with till that point _disappears_ (not seen
> in lsusb any more) and a new device with a different vendor:product (ID
>
Am Sun, Dec 27, 2020 at 03:37:28PM +0530 schrieb Sonali Warunjikar:
> On Sun, Dec 27, 2020 at 11:44:07AM +0530, Sonali Warunjikar wrote:
>
> I realize all control transfers are to be handled using a different api
> ctrl_transfer and wht usbmon is showing are nothing but its parameter
> values.
Am Sun, Dec 13, 2020 at 01:29:41PM +0100 schrieb Hilbert, Sebastian:
> > Sorry, I said earlier I captured from the start of windows VM. But may be
> > I erred. I have recaptured just the initial part and attached herewith.
> >
> > A bit intimidating...
>
> Briefly looked at what you captured.
>
>
Am Sat, Dec 12, 2020 at 10:00:54PM +0530 schrieb Sonali Warunjikar:
> On Sat, Dec 12, 2020 at 09:10:21PM +0530, Sonali Warunjikar wrote:
> > Next step requires going to clinic and exposing it to xray and see what
> > happens. Will update soon.
>
> No luck. For the same end point that showed data
Am Sat, Dec 12, 2020 at 03:44:44PM +0530 schrieb Sonali Warunjikar:
> At this stage: python's libusb is giving only input/output errors for
> various trials. I came across python libusb1 and don't yet know the
> difference. Will try it out.
Am Sat, Dec 12, 2020 at 07:00:12AM +0100 schrieb Hilbert, Sebastian:
> Am Samstag, 12. Dezember 2020, 06:54:29 CET schrieb Sonali Warunjikar:
> > On Fri, Dec 11, 2020 at 10:42:23PM +0530, Sonali Warunjikar wrote:
> > > What is unclear is e.g. '57856 = ' is supposed to indicate length of the
> > >
Am Fri, Dec 11, 2020 at 07:22:21PM +0100 schrieb Karsten Hilbert:
> > I can try and write code using python libusb to try and read the end point
> > 2 as seen. Any other hints?
If you do try and get some useful interfacing going in Python
you might be interested in integrating that
Am Fri, Dec 11, 2020 at 10:42:23PM +0530 schrieb Sonali Warunjikar:
> On Fri, Dec 11, 2020 at 11:06:06AM +0100, Karsten Hilbert wrote:
> > usbmon
>
> Attaching a usbmon trace. 2 snaps (x rays) were taken and that reflects in
> the trace. I am trying to understand the forma
Am Fri, Dec 11, 2020 at 11:06:06AM +0100 schrieb Karsten Hilbert:
> > Basically when the proprietary application is open on Windows, the device
> > is connected to USB port and x-ray is shot, the image appears in that
> > software and it can be saved as a .rvg file.
>
Am Fri, Dec 11, 2020 at 03:19:26PM +0530 schrieb Sonali Warunjikar:
> >What are the resulting files you get on disk with the Windows software or
> >is it stored in a database ?
>
> It is .RVG file which is a DICOM file (as reported by file command).
> Those open fine in open source
Am Fri, Dec 11, 2020 at 12:59:56PM +0530 schrieb Sonali Warunjikar:
> > > I have a carestream dental RVG device with USB interface and I am stuck
> > > with their proprietary software for acquiring the RVG image which runs
> > > only on Windows. Isn’t there any Linux based alternative by which I
Am Fri, Dec 11, 2020 at 10:19:30AM +0530 schrieb Sonali Warunjikar:
> I have a carestream dental RVG device with USB interface and I am stuck
> with their proprietary software for acquiring the RVG image which runs
> only on Windows. Isn’t there any Linux based alternative by which I can
>
Am Mon, Nov 30, 2020 at 12:44:23PM +0100 schrieb Maarten L. Hekkelman:
> I'm preparing another package and this one has a dependency on a library
> found on
> github. The library, a C++ implementation of the NEWUOA algorithm, comes with
> a MIT
> license but has no tag or version number at
On Wed, Aug 12, 2020 at 12:25:31PM +0200, Gert Wollny wrote:
> Maybe we should just enable sse or even sse2, I doubt
> that anyone is running this library on i386 hardware that is not sse2
> capable.
For a moment I was going to go "Uh", but then
Architecture:i686
On Sat, Mar 09, 2019 at 12:05:00PM +0100, Karsten Hilbert wrote:
> On Sat, Mar 09, 2019 at 08:03:56AM +0200, olivier sallou wrote:
>
> > Found a coffee opened at 8 near appartments
>
> t-coffee:
> Installiert: (keine)
> Installationsk
On Sat, Mar 09, 2019 at 08:03:56AM +0200, olivier sallou wrote:
> Found a coffee opened at 8 near appartments
t-coffee:
Installiert: (keine)
Installationskandidat: 12.00.7fb08c2-4
Versionstabelle:
12.00.7fb08c2-4 990
My 2 Euro cent:
> and comment on the current status (may be also addressing my repeated
> question for reflecting the version inside the package name which
> is IMHO not the best idea since it always delays the uploads).
A change to that will likely never happen because that's part
of the very
On Thu, Apr 06, 2017 at 11:27:48AM +0200, Gert Wollny wrote:
> > I wonder whether we could keep VTK-6 for projects using the old API
> > and force VTK-7-only projects to use the new one? VTK-6 and VTK-7
> > should be co-installable, right?
>
> I think the language bindings are not
On Sun, Mar 19, 2017 at 07:48:37AM +0100, Mark 1234 wrote:
> There's a piece of abandon-ware called ezDicom that is a fantastic
> lightweight Dicom viewer:
>
> https://sourceforge.net/projects/ezdicom/
>
> The source code is provided in the link. The authors are not reachable
> (I tried several
On Wed, Mar 01, 2017 at 07:58:34PM +0100, Andreas Tille wrote:
> > >HIS
> > >IMAGING
> > >LAB
> > >ONCO
> > >PRACTICE
> > >
> > >Karsten
> >
> > I agree with Karsten's selection.
>
> Thanks also to Karsten. Commited.
May I, again, point out that the existing tasks are rather
arbitrary ?
On Wed, Mar 01, 2017 at 02:56:34PM +0100, Andreas Tille wrote:
> Could you please suggest task(s) inside the Debian Med scope[1]
> where the package fits into?
HIS
IMAGING
LAB
ONCO
PRACTICE
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9
On Wed, Dec 14, 2016 at 06:49:20AM +0100, Sébastien Jodogne wrote:
> This issue is very low priority wrt. my TODO list for the upstream project.
Understandable.
> Anyone is obviously welcome to help me and contribute by packaging this
> script into the orthanc Debian package.
...
> Le 14 déc.
> The project has just been forked by Jérôme Pinguet.
> There is a threat, he will probably not respect the GPL license terms.
Hopefully, this doesn't happen. If so, German courts have now
handled a few GPL cases as precedents.
Karsten Hilbert
On Wed, May 25, 2016 at 03:39:40PM +0200, Steffen Möller wrote:
> >>> The former mentioned technical reasons aside I would like to add support
> >>> for the political statement that this technology is available and should
> >>> become clinical practice.
> >> What should or should not become
On Wed, May 25, 2016 at 01:17:25PM +0200, Karsten Hilbert wrote:
> > The former mentioned technical reasons aside I would like to add support
> > for the political statement that this technology is available and should
> > become clinical practice.
>
> What should or sho
On Wed, May 25, 2016 at 12:42:21PM +0200, Steffen Möller wrote:
> I think to have gathered enough reason in my initial email for a judge to
> decide that the intent to package OpenAPS is good and genuine and not
> intending to persuade anyone to actually use the software on a patient.
I am with
On Wed, May 25, 2016 at 12:42:21PM +0200, Steffen Möller wrote:
> > However, if I understand things correctly, this openAPS offers _tools_
> > but not a ready-made solution to run your blood-glucose. So, no
> > matter how well we install the package, the user WILL have to
> > write their own
ur blood-glucose. So, no
matter how well we install the package, the user WILL have to
write their own monitoring/dispensing loop.
> What we should probably do is asking a lawyer
That is useless for several reasons at several levels.
Karsten Hilbert
> https://github.com/openaps/openaps
>
> to assemble a bunch of off-the shelf components to establish a feedback
> loop to control blood sugar levels.
>
> Their philosophy is that to comply with FDA regulations the device
> should not be sold, it is up to the individuals and their parents to
>
On Tue, Apr 12, 2016 at 05:01:50PM +0200, Gert Wollny wrote:
> > BTW, any news regarding
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813638
> >
> > ? Anything I can do at the moment ?
> I've asked upstream to tag a new result, but so far he didn't do this,
> so I will
On Tue, Apr 12, 2016 at 04:02:35PM +0200, Karsten Hilbert wrote:
> > > > https://github.com/asamardzic/tempo
> > > Any volunteer to package this (may be in a MoM project)?
> > If no-one steps up for a MoM , I'll prepare the package.
>
> Be aware, tho
On Tue, Apr 12, 2016 at 03:40:13PM +0200, Gert Wollny wrote:
> > > long time no update, but relevant for Debian Med:
> > >
> > > https://github.com/asamardzic/tempo
> > Any volunteer to package this (may be in a MoM project)?
> If no-one steps up for a MoM , I'll prepare the package.
Be
long time no update, but relevant for Debian Med:
https://github.com/asamardzic/tempo
Karsten
On Wed, Mar 02, 2016 at 12:28:41PM +0100, Gert Wollny wrote:
> I've installed the Orthanc server and successfully send some data to
> the server.
...
> Retrieving the data was unsuccessful, because Orthanc tells me
>
> W0302 10:43:16.730446 main.cpp:630] Orthanc has started
> E0302
BTW, may I kindly recall to attention this Aeskulap wishlist item ?
It seems like really low hanging fruit.
Karsten
- Forwarded message from Karsten Hilbert <karsten.hilb...@gmx.net> -
> Date: Wed, 03 Feb 2016 23:23:26 +0100
> From: Karsten Hilbert <karsten.
On Wed, Feb 17, 2016 at 12:23:50PM +0100, Karsten Hilbert wrote:
> > Here it would then be nice if someone would also document the according work
> > -flows.
>
> I posted 5 use cases which would cover _a lot_ of ground for
> the typical user. Note that Ginkgo CADx was/is ab
On Tue, Feb 16, 2016 at 03:30:23PM +0100, Gert Wollny wrote:
> Well, I will now prepare the project on github, and continue cleaning
> the code etc. My focus will be to work on the C++, i.e. try to remove
> race conditions, crashes, and the like.
>
> Where I definitely will need help is to set
User story #5
- doctor displays a DICOM study
- doctor zooms/pans/rotates/flips image
- doctor changes contrast of image
- doctor returns to "original" display of image
- doctor annotates interesting areas with
- arrows
- circles
- ellipses
- text
- doctor saves annotations
- doctor
User story #4
- doctor display a range of studies downloaded from a PACS server
- doctor burns selected studies onto a CDROM to give to the
patient for referral to another doctor
1 - 100 of 573 matches
Mail list logo
