Aw: Re: Acquiring Dental RVG on Linux
> > 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: > > (0009, 110a) Private tag dataUL: 1983368088 Does this https://groups.google.com/g/orthanc-users/c/8pOUQJH2oTs help in any way ? Karasten
Re: Aw: Aw: Re: Acquiring Dental RVG on Linux
Am Samstag, 2. Januar 2021, 19:02:59 CET schrieb Sebastian Hilbert: > 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. > I had contacted an ebay seller that sells repaired devices. They state that a new license is 75 $ and one needs to reinstall (IOW buy a new license) when you move to another computer with the same sensor. They recommend a laptop :-) They also state that there is some sort of server setup where you could use the sensor from multiple computers on a network with one license. I have no idea what clues that gives. First info seems to imply the license is specific to the computer. Best, SH
Aw: Re: Acquiring Dental RVG on Linux
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. Januar 2021 um 18:03 Uhr > Von: "Sonali Warunjikar" > An: debian-med@lists.debian.org > Betreff: Re: Acquiring Dental RVG on Linux > > On Sat, Jan 02, 2021 at 05:24:15PM +0530, Sonali Warunjikar wrote: > > If I imagine line pair to be equivalent of 2 pixels, the pixel width isn't > > matching with that. Essentially lp/mm is appearing coarser than pixel > > width and probably hence called 'true (measured) resolution' and may be > > they aren't expected to match. > > > > I tried both: 1. using pixel width compute pixels per meter 2. using > > lp/mm, assuming 1 lp is equivalent to 2 pixels compute pixels per meter. > > > > 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 > > portion of the finger). I need to go and gather more x rays carefully (may > > be using a coin to make the boundaries more accurate) before confirming > > which measure is accurate or whether something else is required or is just > > a fixed calibration factor is needed. > > [1] is the image produced by a coin kept right on the sensor whose > diameter is officially 21.93mm (appears 22mm to us by accuracy with which > we can measure at home). > > The spec[2] says: pixel size = 19 micrometer, 'true (measured) resolution > = 16 linepairs/mm. > > The png encoder requires pixels/metre > by pixel size it comes out to be: 52631 > by lines per mm it is (explained above): 32000 > > I measured the count of pixels along diameter line using gimp, by drawing > a line that to a naked eye looks like a diameter. It comes to be 1172. > > So pixels/m should be diameterpixels * 1000/21.93 = 53442.77. This is > closer to the one derived from pixel size, but quite far from linepair/mm. > > Can someone suggest any better way (preferably some tool) to measure the > diameter of the circle in image [1] to improve the accuracy? > > > [1] http://mayuresh.sdfeu.org/coinxray.png > [2] > https://pdf.indiamart.com/impdf/22884448473/MY-16502350/dental-rvg-systems-kodak-5200.pdf > >
Re: Aw: Re: Acquiring Dental RVG on Linux
On Mon, Jan 04, 2021 at 09:42:08AM +0100, Sebastian Hilbert wrote: > There is some info on the licensing stuff in this document > http://hsc.myvnc.com/last/good/upload/faq/pdf/CS3000_Dental_Imaging_IG.pdf[2] This version of procedure is much newer than the one I bought in 2015. Both node locked and floating (server) options are present in this which weren't there back then. Neither is my device model present in most of the screen shots where model numbers appear. [There is 5x00 in some screen shots and I do not know how to correlate these two observations.] The activation process on my device involves sharing with them a key that is generated locally on your computer by running their utility, along with device serial number and several more fields (10 to 20) and then they return a code which is to be entered in their application. What I am told by the retailer is if you need another installation (no matter for your convenience or disk crashed or whatever) you need to pay some fees to get and activate the license. We have to assume that they are trying to exploit you or are themselves naive, if the license file theory is to be true. Otherwise they could have told you to just copy a file from one computer to another. I do not recollect whether I tried it with this app (but most likely I did), but I have seen this with multiple applications before, when they say node locked it doesn't work by copying the installation to another machine. Now let's say for the sake of argument license file exists, the initialization trace is unlikely to be a straightforward function of such file.
Re: �Aw: Re: Acquiring Dental RVG on Linux
On Sun, Jan 03, 2021 at 02:48:58PM +0100, Karsten Hilbert wrote: > > https://forums.anandtech.com/threads/advice-on-sizing-a-server-for-25-users-dental-office.2171855/ Feel for them. Just to contrast it, the whole activity I did started with a desire to use a Raspbery Pi 4 (now that it has sufficient RAM options) with a wall mounted monitor of suitable resolution, as a dedicated dental imaging setup in place of having to move a laptop around. It will make the setup quite tidy. Once we sort out everything and it becomes usable, I'll be roping in a Pi.
Re: �Aw: Re: Acquiring Dental RVG on Linux
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 I know personally, > among those who use exactly the same device, among those who would trust > it to be given into a person's hand who is doing crazy things with an > operating system whose name they haven't heard and who has written a > disclaimer that it may damage their device? > > Unless that person had the reputation of someone like Linus, it's hard to > convince another dentist, even if found with the same device and is a > close acquaintance. Wouldn't blame them, these devices are costly and the > can't be expected to comprehend what we are up to with it and what's the > big deal about achieving that when things work for them on Windows anyway. > > In general, it's hard to get individual (non company) engineers and > doctors to work together, particularly the latter trusting the former > purely for experimentation when nothing is broken for the latter! You have perfectly described the quagmire. I'd trawl the web for posts like this https://forums.anandtech.com/threads/advice-on-sizing-a-server-for-25-users-dental-office.2171855/ and attempt to contact them. Places like stackoverflow might work well for that. Say, this https://stackoverflow.com/questions/30062133/how-would-i-convert-a-raster-image-to-a-usable-format-like-jpg which I found with site:stackoverflow.com rvg sensor on Google (not that I don't prefer duckduckgo ... :) > I'm sure communities like *-med will have long experience of these situations. You tell me ... Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Re: Aw: Re: Acquiring Dental RVG on Linux
On Sat, Jan 02, 2021 at 07:11:16PM +0100, Karsten Hilbert wrote: > Mayuresh (Ganesha? ;-) Good grasp and patience to search! > 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 ... Yes. And I was also gently reminded of there being many dentists in Pune ;-) (again above remark holds for mentioning Pune). The problem is: it limits the universe to those whom I know personally, among those who use exactly the same device, among those who would trust it to be given into a person's hand who is doing crazy things with an operating system whose name they haven't heard and who has written a disclaimer that it may damage their device? Unless that person had the reputation of someone like Linus, it's hard to convince another dentist, even if found with the same device and is a close acquaintance. Wouldn't blame them, these devices are costly and the can't be expected to comprehend what we are up to with it and what's the big deal about achieving that when things work for them on Windows anyway. In general, it's hard to get individual (non company) engineers and doctors to work together, particularly the latter trusting the former purely for experimentation when nothing is broken for the latter! It happened with us because both professionals are in the same family. I'm sure communities like *-med will have long experience of these situations.
Re: Aw: Re: Acquiring Dental RVG on Linux
On Sat, Jan 02, 2021 at 07:02:59PM +0100, Sebastian Hilbert wrote: >This theory would have to be checked with a 3rd party software that >officially supports the device - if such a thing exists. We saw at least one third party software on this thread which insists that the carestream drivers should be running fine. Odds are in favor of driver having the locks.
Aw: Re: Acquiring Dental RVG on Linux
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 exp/br/y/contrast until the raw capture "looks like" the one shown by CareStream software. Wash, rinse, repeat with a few more x-rays. One might then be able to extrapolate the approximate settings ? Karsten
Aw: Aw: Re: Acquiring Dental RVG on Linux
> 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
Aw: Aw: Re: Acquiring Dental RVG on Linux
> 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 would have to be checked with a 3rd party software that > officially supports the device - if such a thing exists. I thought so, too, but mayuresh quite convincingly argues that it likely happens inside the TWAIN driver code somewhere because: a) yes, there is 3rd party software supporting the sensor b) but, only via the sensor's TWAIN driver c) and, there is documentation on the web that the TWAIN driver must be "set up" by CareStream representatives However, I would test the latter assumption/attestation by downloading the driver, install it, and see what happens :-) Mayuresh (Ganesha? ;-) did, however, point out a good way forward: 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 ... Karsten
Aw: Re: Acquiring Dental RVG on Linux
> 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
Aw: Aw: Re: Acquiring Dental RVG on Linux
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--Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.Am 02.01.21, 18:55 schrieb Karsten Hilbert : 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 sensor via CareStream. Kodak wanted its RVG5200 to be branded "Kodak" (as in: it shows up as "Kodak" on the USB bus). 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 the device (even though it did not technically change). So, for re-branding, Kodak simply put a USB veil (fake device) "covering" the unchanged Trophy USB device. If that theory holds I find it reasonable to assume that the license checks happens in the *first* part of the init, the Kodak device one. Does that make any sense ? Karsten
Aw: Aw: Re: Acquiring Dental RVG on Linux
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 would have to be checked with a 3rd party software that officially supports the device - if such a thing exists.--Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.Am 02.01.21, 18:55 schrieb Karsten Hilbert : 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 sensor via CareStream. Kodak wanted its RVG5200 to be branded "Kodak" (as in: it shows up as "Kodak" on the USB bus). 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 the device (even though it did not technically change). So, for re-branding, Kodak simply put a USB veil (fake device) "covering" the unchanged Trophy USB device. If that theory holds I find it reasonable to assume that the license checks happens in the *first* part of the init, the Kodak device one. Does that make any sense ? Karsten
Aw: Re: Acquiring Dental RVG on Linux
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 sensor via CareStream. Kodak wanted its RVG5200 to be branded "Kodak" (as in: it shows up as "Kodak" on the USB bus). 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 the device (even though it did not technically change). So, for re-branding, Kodak simply put a USB veil (fake device) "covering" the unchanged Trophy USB device. If that theory holds I find it reasonable to assume that the license checks happens in the *first* part of the init, the Kodak device one. Does that make any sense ? Karsten
Aw: Re: Acquiring Dental RVG on Linux
> 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 > portion of the finger). I need to go and gather more x rays carefully (may > be using a coin to make the boundaries more accurate) before confirming > which measure is accurate or whether something else is required or is just > a fixed calibration factor is needed. There's actually pre-made x-ray markers for that https://veterinary-instrumentation.co.uk/catalog/product/view/id/6206/s/xray-marker-with-scale/category/2582/ but I assume any known length might do for calibration. OTOH, dental x-ray shows rather small structures so the distance between the actual sensor surface and the imaged body part could matter quite a bit. Karsten
Aw: Re: Acquiring Dental RVG on Linux
> [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 mm. Not sure how to correlate it with 19 > micro pixel size. > > [1] > https://pdf.indiamart.com/impdf/22884448473/MY-16502350/dental-rvg-systems-kodak-5200.pdf I saw that PDF before but by the time I found it Aaron had already hinted at the 12-bit-grayscale nature of the data (the small table in that PDF would eventually have told us so, too). Karsten
Aw: Re: Acquiring Dental RVG on Linux
> 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 working well (making sure to avoid lossless compression). DICOM is mostly "just" a wrapper from more normal image data, such as JPEG2000 or TIFF. We can easily convert standard images to DICOM, and only at that point we would start thinking about study/series/instance issues. Karsten
Aw: Re: Acquiring Dental RVG on Linux
> > 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 sensor using any old TWAIN compatible scanning software. > > You may not get X-Rays but you may get useful USB startup traces. This https://www.ihs.gov/doh/EDR/documents/DEXIS_Imaging_Suite_Supported_Hardware_508.pdf claims to support the Kodak Sensor TWAIN interface... Karsten
Aw: Re: Acquiring Dental RVG on Linux
> 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). Plug in the sensor and monitor the USB flow. > > Since on that "machine" you never entered any license key material > you might be able to obtain untainted traces. 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. You may not get X-Rays but you may get useful USB startup traces. Karsten
Aw: Re: Acquiring Dental RVG on Linux
> 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) 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). Plug in the sensor and monitor the USB flow. Since on that "machine" you never entered any license key material you might be able to obtain untainted traces. Karsten
Aw: Re: Acquiring Dental RVG on Linux
> 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 another sensor ? I gather there's more than one dentist in Pune ? ;-) Or else the RVG/Kodak representative might be interested in providing a replacement while checking yours for quirks that you noticed during use :-D > I can anyway put the code somewhere and write down the steps > to gather those traces may be? Any thoughts? That would certainly be well advisable. Karsten
Aw: Re: Acquiring Dental RVG on Linux
> 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
Aw: Re: Acquiring Dental RVG on Linux
> 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 suppose finding suitable defaults is useful but then one should strive to convert the data to a more conventional format, say, some DICOM variant and feed that to Orthanc for storage and to Ginkgo CADx / Aeskulap / your-favourite-viewer for image display. They offer controls for adjusting exposure, brightness, and contrast. I can ascertain one _needs_ to adjust those dynamically :-) Karsten
Aw: Re: Acquiring Dental RVG on Linux
> 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 /dev/zero) - copy the capture raw image data into a file inside the loopback filesystem - unmount it - run photorec on the loopback file Hopefully, photorec finds your image data and tells us what sort of image it is. Karsten
Aw: Re: Acquiring Dental RVG on Linux
How is the machine connected ? USB ? Network ? What are the resulting files you get on disk with the Windows software or is it stored in a database ? I might be worth looking into how the software actually finds out the hardware has changed. They might check the MAC address of the network card. Gesendet: Freitag, 11. Dezember 2020 um 10:09 Uhr Von: "Sonali Warunjikar" An: debian-med@lists.debian.org Betreff: Re: Acquiring Dental RVG on Linux On Fri, Dec 11, 2020 at 08:48:21AM +0100, Karsten Hilbert wrote: > The windows imaging application might work under Wine, or be > put into a VM, and might possibly store the imaging results > in a somehow accessible format, which you might be able to > further process on the Linux side. Yes, my setup is precisely that right now. A VirtualBox windows instance on Linux host and shared samba file system over which I can get the images back to Linux. However the license of the proprietary software is node locked which does not allow me to change the VM. For example I can't even switch from virtualbox to qemu or something else that might suit me. Tried porting the vm to qemu, but windows always finds that as if the motherboard has changed and refuses to boot. If I do a fresh installation I'll have to buy the software license all over again every time I do so. You mentioned DICOM - is it a protocol to talk to digital x ray device? If there are any resources kindly do share. I'll also search.
