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
acquire the RVG over USB?
I know there are a lot of imaging software options. My qu
On Fri, Dec 11, 2020 at 08:04:27AM +0100, Karsten Hilbert wrote:
> 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 w
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 se
On Fri, Dec 11, 2020 at 10:13:19AM +0100, Sebastian Hilbert wrote:
>How is the machine connected ? USB ? Network ?
To the imaging device - USB.
>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 fi
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 format using [1].
I think the lines C Bi:1:014:2 are the ones showing returned data.
What is unclear
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
> data that follows but it's not exactly 57856 bytes following it on that
> event (line).
It seems, no matter the data length, u
On Fri, Dec 11, 2020 at 07:22:21PM +0100, Karsten Hilbert wrote:
> http://vusb-analyzer.sourceforge.net/
Due to pygtk requirement not being met on my ubuntu 20.04 above doesn't
work. Yes there are quirks to get it to work. But for now I am comfortable
looking at usbmon also and do some exper
On Sat, Dec 12, 2020 at 11:00:58AM +0100, Karsten Hilbert wrote:
> If you figure out a way to control your device to some useful
> extent I'd be willing to help adapt GNUmed
That would be great if it happens.
At this stage: python's libusb is giving only input/output errors for
various trials. I
On Sat, Dec 12, 2020 at 04:16:18PM +0100, Karsten Hilbert wrote:
> 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
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 being received in usbmon,
the read call times out even after X ray ex
On Sat, Dec 12, 2020 at 05:49:04PM +0100, Sebastian Hilbert wrote:
> Can you share a usbmon recording ?
It's attached as email attachment in one of the earlier posts.
On Sat, Dec 12, 2020 at 05:59:38PM +0100, Karsten Hilbert wrote:
> You may want to capture USB traffic during *startup* of the
> Windows app, not before exposure only. It may well send setup
> commands at that point.
Yes, in fact usbmon was started even before windows VM. That makes me
believe it
On Sat, Dec 12, 2020 at 05:56:04PM +0100, Sebastian Hilbert wrote:
> Found a presentation that says it is Twain compatible and works with third
> party
> applications
>
> https://de.slideshare.net/smokeypike/the-rvg-5200-from-carestream-dental-digital[1]
Yes that is the exact product and this is
On Sat, Dec 12, 2020 at 06:03:04PM +0100, Sebastian Hilbert wrote:
> You might already be aware of this ressource
>
> https://www.devalias.net/devalias/2018/05/13/usb-reverse-engineering-down-the-rabbit-hole/[1]
No I wasn't. Thanks for another great pointer.
On Sat, Dec 12, 2020 at 06:00:16PM +0100, Sebastian Hilbert wrote:
> For scanning you might want to look at
>
> https://pypi.org/project/pyScanLib/[1]
>
> and
>
> https://github.com/soachishti/autoScanner[2]
I am conversant with sane and above look more 'above' it as layers. I
think they will b
On Sat, Dec 12, 2020 at 11:49:16PM +0100, Sebastian Hilbert wrote:
> https://german.alibaba.com/product-detail/lk-c64-rvg-5200-x-ray-sensor-dental-digital-x-ray-sensor-60431854823.html[1]
Great find! Somehow even the English site takes to German page on
searching and clicking on this product. Not
On Sat, Dec 12, 2020 at 05:59:38PM +0100, Karsten Hilbert wrote:
> You may want to capture USB traffic during *startup* of the
> Windows app, not before exposure only. It may well send setup
> commands at that point.
Sorry, I said earlier I captured from the start of windows VM. But may be
I erred
On Sun, Dec 13, 2020 at 10:13:39AM +0530, Sonali Warunjikar wrote:
> 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...
Also a wireshark capture (attached,
On Sun, Dec 13, 2020 at 12:06:22PM +0530, Sonali Warunjikar wrote:
> Also a wireshark capture (attached, gzipped), a filter 'usb.bus_id == 1
> and usb.device_address == 6' reveals the device in question.
>
> Honestly no clue how I'll make use of all this!
>
>
On Sun, Dec 13, 2020 at 12:51:34PM +0100, Sebastian Hilbert wrote:
> Have you asked the manufacturer for information on using this as a twain
> device ?
I thought I replied to that. This product's pages open only in German even if I
search on the English site. So could not find where to ask.
For
On Sun, Dec 13, 2020 at 02:47:15PM +0100, Sebastian Hilbert wrote:
> If you want to try talking to the device look at
>
> https://github.com/JohnDMcMaster/usbrply[1]
Present worry is getting reliable data to replay in the first place. As I
said usbmon truncates bytes and I have several observatio
On Sun, Dec 13, 2020 at 02:33:07PM +0100, Sebastian Hilbert wrote:
> I guess they hand out a twain driver on request.
But for Windows, right? I have the manufacturer supplied driver anyway. If
you mean, use it to understand the protocol, then it's almost the same
exercise going on with the manufac
On Sun, Dec 13, 2020 at 02:05:10PM +0100, Sebastian Hilbert wrote:
> I know that all the pointers get overwhelming. What you are looking at
> is way beyond my expertise.
No. All your links have added value and I have examined each one of them.
Please continue to share whatever you think might even
On Sat, Dec 12, 2020 at 11:49:16PM +0100, Sebastian Hilbert wrote:
> LK-C64 from YesBiotech from South Korea.
>
> Sold on alibaba.com
Summary:
1. I finally found an English page and have sent a query.
2. I sent a query to the manufacturer (2nd time around) and like before no
response. There is
On Sun, Dec 20, 2020 at 10:53:57AM +0100, Sebastian Hilbert wrote:
> I guess the next step would be to obtain a hardware USB debugger like
> the ones I have referenced. They are around $100 US and come bundled
> with software that makes capturing reliable.
I'd need to be convinced about inadequacy
On Sun, Dec 13, 2020 at 07:11:24PM +0100, Karsten Hilbert wrote:
> I would start even earlier: Even without the device attached
> _at all_.
>
> - start capture
> - start windows app
> - stop capture
> - stop windows app
>
> - rinse and repeat until you see a pattern (of what is sent
> to the US
On Sun, Dec 27, 2020 at 11:22:22AM +0530, Sonali Warunjikar wrote:
> arr = [ 0x00, 0x12, 0x80, 0x06, 0x01, 0x00, 0x00, 0x00, 0x00, 0x12 ]
To mimic:
1.022.000 S Ci 0012 80 06 0100 0012
Have also tried dropping the first two elements, which may not be a part
of the message i.e.
arr = [ 0
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. The following call works (first time ever something worked
On Sun, Dec 27, 2020 at 11:32:10AM +0100, Karsten Hilbert wrote:
> Very nice !
I figured out more things, mainly the answers to confusions I had in the
last mail. The answers to my questions are:
Host always initiates the interaction. It is called 'i' if host is seeking
information and not sendin
On Sun, Dec 27, 2020 at 03:53:36PM +0100, Sebastian Hilbert wrote:
> > Will update the thread when some progress is made. Looks like as far as
> > the basic knowhow is concerned, I may not have too many more questions.
>
> Sounds good. Persistence will pay off.
Something remarkable happened. Afte
On Mon, Dec 28, 2020 at 12:03:34PM +0100, Sebastian Hilbert wrote:
> Can you clearly identify the end of this initial transmission and some sort of
> resting state ? In other word the exact endpoint before image is requested
> from the device. I guess you would have to plug/unplug a couple times an
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 be great as well.
Still stuck there... Any idea from
On Wed, Dec 30, 2020 at 12:38:53AM +0100, Karsten Hilbert wrote:
> I agree. It seems quite likely to be more setup of the device.
To be precise I do not know how to issue two back to back 'S' without a
'C' occurring in between.
1.007.001 S Ii 0002
1.007.000 S Ci 0342 c0 83 0008 0342
That's
On Wed, Dec 30, 2020 at 09:34:26AM +0100, Sebastian Hilbert wrote:
> shouldn't it be possible to find "repetition" when taking images - if
> feasible ? It should be
> possible to at least identify (even with fuzzy start and end) "data blocks".
> Once data blocks
> are identified the "stuff inb
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 specify large enough timeout for S Ii
on a thread and do other S Cis on another. It does sound weird
On Wed, Dec 30, 2020 at 03:43:05PM +0100, Karsten Hilbert wrote:
> Does pyusb not offer any non-blocking submissions ?
No. But it offers timeout, within which I should try and run another
thread.
On Wed, Dec 30, 2020 at 09:55:54AM +0530, Sonali Warunjikar wrote:
> On the face of it, it's weird if multithreading is required for a serial
> communication where there is one link and two devices at both ends of it.
> But may be the device is designed to not respond to Ii until
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.
Almost there...
The image resolution on Windows is known and the byte array gathered is
double of widthxheight indicating
On Thu, Dec 31, 2020 at 02:13:51PM +0100, Sebastian Hilbert wrote:
>
> https://stackoverflow.com/questions/32622658/read-16-bit-png-image-file-using-python
This almost confirms pillow to be the culprit. Will try the alternatives.
On Thu, Dec 31, 2020 at 02:47:15PM +0100, Karsten Hilbert wrote:
> Hopefully, photorec finds your image data and tells
> us what sort of image it is.
Not much problem with that, as the image can already be seen clearly, just
that it's losing depth due to an apparent pillow limitation. Will use
oth
On Thu, Dec 31, 2020 at 01:10:25PM -0500, Aaron M. Ucko wrote:
> From what I gather, python3-pythonmagick should support 16-bit channel
> depths. I'm not at all familiar with its usage details, though, so I
> can't give you any more specific tips.
In the meantime I used libpng. It supports 16 bit
On Thu, Dec 31, 2020 at 02:59:03PM -0500, Aaron M. Ucko wrote:
> Thanks for posting this! It looks like raw 12-bit little-endian data,
> with byte ranges alternating between [0, 255] and [0, 15]; I get
> plausible results with the below patch:
You just gave me a new year's gift! It was so importa
On Thu, Dec 31, 2020 at 10:34:13PM -0500, Aaron M. Ucko wrote:
> You might conceivably also need some non-linear gamma correction.
Thanks. Will keep that in mind.
And of course I'd have given up the activity long back but for continuous
encouragement and inputs from Karsten and Sebastian. A big t
On Fri, Jan 01, 2021 at 09:01:40AM +0100, Karsten Hilbert wrote:
> Since on that "machine" you never entered any license key material
> you might be able to obtain untainted traces.
The traces to play back are learned from a machine with license installed,
without which there was nothing to learn.
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 driver-app interface
rather than
On Fri, Jan 01, 2021 at 08:35:36AM +0100, Karsten Hilbert wrote:
> You don't, by any chance, happen to be able to access another sensor ?
Too costly proposition!
> I gather there's more than one dentist in Pune ? ;-)
Ah, that's a possibility. Will check, not easy but not impossible.
> Or else
On Fri, Jan 01, 2021 at 08:28:21AM +0100, Karsten Hilbert wrote:
> > 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
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 front.
On Fri, Jan 01, 2021 at 09:34:08AM +0100, Karsten Hilbert wrote:
> I know, the idea was to install the CareStrean TWAIN "driver" but not
> the CareStream dental imaging solution in the hope that the license
> material resides in the imaging solution rather than the TWAIN driver.
With the discovery
On Fri, Jan 01, 2021 at 08:30:17AM +0100, Karsten Hilbert wrote:
> Very true. Pulling this off is quite a feat unless one is
> a fairly experienced hard/soft tinkerer.
Let me reveal: the dentist (registered on this list) herself is not the
tinkerer. Her husband is who is an engineer by profession.
On Fri, Jan 01, 2021 at 11:42:23AM +0100, Karsten Hilbert wrote:
>
> https://sqps.onstreamsecure.com/origin/csdental/CSD/Downloads/RVG4-6-9-C.zip
>
> If that's the genuine driver, and the driver "contains" the licensing
> material, then there must be a way on "insert" the license data into
>
On Fri, Jan 01, 2021 at 06:14:35PM +0100, Sebastian Hilbert wrote:
> The use case for converting to DICOM _could_ be :
>
> 1.) standard based "image" storage and sharing
> 2.) image manipulation with standard (any) DICOM viewer out there
Agree. But these don't sound so pressing. 1. Storage, retri
On Fri, Jan 01, 2021 at 11:56:46PM +0530, Sonali Warunjikar wrote:
> After image calibration, another requirement is distance measurement. Here
> DICOM might help as this will come by default in DICOM viewers. But I
> guess gimp should be able to do that. I am able to get distances
On Fri, Jan 01, 2021 at 08:35:36AM +0100, Karsten Hilbert wrote:
> > 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.
Please take a look and advise. This is my first submission on github. I
ma
On Sat, Jan 02, 2021 at 12:00:09AM +0530, Sonali Warunjikar wrote:
> PS: The unit is a dropdown in gimp and can be set to mm instead of pixels.
The png generated is missing the information to compute this distance
(dpi?).
It is showing the length of index finger distal phalanx close to 1ft!
On Sat, Jan 02, 2021 at 01:32:32PM +0530, Sonali Warunjikar wrote:
> Have to also check whether the pypng package supports that field.
[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 t
On Sat, Jan 02, 2021 at 12:26:52PM +0100, Sebastian Hilbert wrote:
> "The maximum spatial resolution is described as ability to separate patterns
> of black and
> white lines and it is given in line pairs per millimeter ([lp/mm]). As
> theoretical limit it is
> described in the literature and com
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 driver
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 software.
Precisely planning to do that. It's also ok to take 2 snaps (1 on win, 1
on Linux) keeping the sens
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.
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
> the device (even though it did not technically change).
>
> So, for re-branding, Kodak simply put
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 Health
Group was sold to Onex Corporation ... and Kodak Health Group was renamed
Carestream Health." [1]
On Sun, Jan 03, 2021 at 02:30:44PM +0100, Karsten Hilbert wrote:
> BTW, was there ever any feedback from that alibaba contact ?
On 3 consecutive days an apparently auto-generated email came with someone
saying he or she will get back by tomorrow. Stopped after that.
On Sun, Jan 03, 2021 at 02:32:30PM +0100, Karsten Hilbert wrote:
> The margin of error will be larger than the precision of approximation :-)
For most of the image parameters, a Dr can decide whether the x ray looks
right in absolute terms. Comparing gives just a rough basis for a
technician. Same
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
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 an
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
On Tue, Jan 05, 2021 at 06:07:51PM +0100, Karsten Hilbert wrote:
> better: fit a square around the circle ...
Thanks. gimp's ellipse drawing tool with aspect ratio locked to 1:1 pretty
much does the same. The visual judgment of the circle matching (or its
bounding box being a tangent, but that giv
On Tue, Jan 05, 2021 at 11:17:47PM +0530, Sonali Warunjikar wrote:
> Thanks. gimp's ellipse drawing tool with aspect ratio locked to 1:1 pretty
> much does the same. The visual judgment of the circle matching (or its
> bounding box being a tangent, but that gives fewer check points)
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 the d
On Sat, Jan 09, 2021 at 09:46:33AM +0100, Karsten Hilbert wrote:
> > This means at the most 10 bits can be relevant for human consumption.
>
> At once, that is ?
>
> One can shift the shades-on-screen across the spectrum, or am I mistaken ?
You are right. But there is a need of proper user int
On Sat, Jan 09, 2021 at 09:36:21AM +0100, Karsten Hilbert wrote:
> (It is only allowable by law to apply the minimum needed radiation
> dose. If I can throw away bits that can be construed to mean that
> medically I could have gotten away with a lower dose.)
I see following problems then:
- Lik
On Sat, Jan 09, 2021 at 02:58:24PM +0530, Sonali Warunjikar wrote:
> (Or may be there is a configurable option somewhere that I may have
> missed.)
There is one called "carestream large" which retains all bits. So
technically they are compliant. But whether that option is prac
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.
Trying to figure out appropriate post-processing that is needed / that the
proprietary application does to get the images right. Haven't got any
On Sun, Jan 10, 2021 at 10:56:18PM +0100, Karsten Hilbert wrote:
> Perhaps the vendor app "knows" something about this type of
> sensor (such as a gamma curve) - or, perhaps, it even learns
> something off this sensor during initialization, wear-n-tear
> etc ?
No progress in discovering that. Trie
On Fri, Jan 15, 2021 at 10:05:36AM +0100, Karsten Hilbert wrote:
> 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 with the device
Following are observations about the metadata which aren't surprising
given that the device has nothing to do with DICOM. It is giving a raw
bitmap and not even a byte more. (Just before writing this I went through
the raw usbmon trace once again.)
> It alludes to LUT
That is IDENTITY. It would al
On Sun, Jan 17, 2021 at 12:26:25AM +0100, Karsten Hilbert wrote:
> CareStream about exposure
>
>
> https://www.carestream.com/blog/2016/09/06/understanding-radiology-exposure-indicators/
>
> digital x-ray postprocessing:
>
>
> http://www.google.com/url?q=https://www.aapm.org/meetin
On Fri, Jan 15, 2021 at 04:28:47PM +0530, Sonali Warunjikar wrote:
> Will try and share some images.
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
79 matches
Mail list logo
