Re: [sane-devel] Sane backend for an intraoral X ray camera
On Thu, Dec 31, 2020 at 10:47:02PM +0530, Mayuresh wrote:
> This scenario of converting raw data to an image must be very common in
> sane. Wonder if I could get some suggestions. If a python package (other
> than PIL for above issue) can do it, it will be better as the driver
> itself is in python. But even other alternatives will do
In the meantime I used libpng. It supports 16 bit depth. But the results
aren't yet correct - it's not looking like a normal X ray. May be I am
missing something about the image format.
I am keeping a sample image if anyone could try and reconstruct here:
http://mayuresh.sdfeu.org/img.dat.gz
Note the parameters:
width = 1168
height = 1562
depth = 16
It's little endian or big endian is unclear, both ways it is producing
results.
interlace is true or false is not clear, pypng did not show any difference
when interlace in its png encoder was true vs false.
It may require color inversion, which could be done either after
reconstructing image or during.
Here is some code using pypng:
# Please set flnm suitably
import struct
with open(flnm,'rb') as fp: buf = [ 65535 - v[0] for v in
struct.iter_unpack('>H',fp.read()) ]
width = 1168
height = 1562
depth = 16
arr = [ buf[i:i+width] for r in range(height) for i in [r*width] ]
import png
with open('see.png','wb') as fp:
png.Writer(
width = width,
height = height,
greyscale = True,
bitdepth = depth,
).write(fp,arr)
Re: [sane-devel] Sane backend for an intraoral X ray camera
On Sun, Dec 13, 2020 at 07:23:46PM +0530, Mayuresh wrote: > I am trying to get sane work with a digital X ray device used for > dentistry described here [1] on Linux (Ubuntu 20.04) or on NetBSD 9.1. With the help of usbmon (untruncated version courtesy [1]) and pyusb I managed to get the camera to work and return a byte array to me. [It's complicated as the device that actually returns the data is hidden and gets unlocked only after following certain sequence of interactions with the device that at first appears. But that's a matter of detail.] Using PIL python APIs I am also able to convert the raw byte array into an image, though there is just one glitch. The raw data is a 16 bit grayscale image, which converts fine, but when showing / saving it's treated like an 8 bit image. I read on some thread that this is indeed a limitation of the pillow (PIL) package. This scenario of converting raw data to an image must be very common in sane. Wonder if I could get some suggestions. If a python package (other than PIL for above issue) can do it, it will be better as the driver itself is in python. But even other alternatives will do [1] https://github.com/swetland/usbmon
Re: [sane-devel] Sane backend for an intraoral X ray camera
On Thu, Dec 17, 2020 at 09:31:20PM -0500, m. allan noah wrote: > The device does not support twain. The device speaks a proprietary > protocol. May be besides proprietary protocol it also supports TWAIN? https://de.slideshare.net/smokeypike/the-rvg-5200-from-carestream-dental-digital Enhanced workflow • TWAIN compatible – Simplifies implementation – Allows for direct acquisition with TWAIN compliant third party imaging software – Enables customer to continue using existing TWAIN compliant software Anyway, if pint is defunct, this is a non starter.
Re: [sane-devel] Sane backend for an intraoral X ray camera
On Thu, Dec 17, 2020 at 08:54:17PM -0500, m. allan noah wrote: > If the windows driver gives you some options, then you make a series > of logs each with a different combination of settings. Then compare > the logs to determine what changes. Anything that remains, you may > have to hard code. The manufacturer has said that the device supports TWAIN (I shared a link in the first post). I understand pint backend is a way to mimic TWAIN (or is that not correct?). Is there any way to force use a given backend (pint in this case) - just to try out?
Re: [sane-devel] Sane backend for an intraoral X ray camera
On Thu, Dec 17, 2020 at 8:11 PM Mayuresh wrote: > > On Thu, Dec 17, 2020 at 07:42:06AM -0500, m. allan noah wrote: > > I took a quick look at the protocol and did not recognize it. > > > Perhaps someone else will recognize the protocol. > > If that is not recognized, what is the way out? Just play back as it is by > hard coding the values? > If the windows driver gives you some options, then you make a series of logs each with a different combination of settings. Then compare the logs to determine what changes. Anything that remains, you may have to hard code. > If I were to do that what tools are suitable? I tried python libusb once, > but could not mimic even 1 step, was getting input/output error or timeout > error. If you want to use sane, you copy a backend that seems readable to you, and pound it into shape. For instance, the cardscan backend is small, and uses USB. > Also, the 'END POINT' numbers reported by wireshark (by double clicking on > any event) aren't matching those reported by lsusb or usbmon. So when > mimicing it's unclear which end point numbers to trust. Oddly, the in vs out end points will have a difference in the highest bit (eg, 0x01 vs 0x81), and some logging programs don't show that distinction. I am not sure if that is what you are seeing. allan -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"
Re: [sane-devel] Sane backend for an intraoral X ray camera
On Thu, Dec 17, 2020 at 07:42:06AM -0500, m. allan noah wrote: > I took a quick look at the protocol and did not recognize it. > Perhaps someone else will recognize the protocol. If that is not recognized, what is the way out? Just play back as it is by hard coding the values? If I were to do that what tools are suitable? I tried python libusb once, but could not mimic even 1 step, was getting input/output error or timeout error. Also, the 'END POINT' numbers reported by wireshark (by double clicking on any event) aren't matching those reported by lsusb or usbmon. So when mimicing it's unclear which end point numbers to trust.
Re: [sane-devel] Sane backend for an intraoral X ray camera
I approved both mails days ago, but the web-based download is a good idea. I took a quick look at the protocol and did not recognize it. Seems to be a few control URBs for setup, and then perhaps a string of interrupt URBs as the scanner waits for the x-ray source to fire? The image data is visible in the log, appears to be 12 bit, padded to 16 bit. I don't currently have a dicom viewer to look at the images. Perhaps someone else will recognize the protocol. allan On Thu, Dec 17, 2020 at 3:36 AM Mayuresh wrote: > > On Tue, Dec 15, 2020 at 11:25:32PM +0530, Mayuresh wrote: > > There were 3 x rays taken, just to give more room for observation, out of > > which first was discarded as it was completely dark. Attaching a zip of > > the remaining two. Have chosen an export format called 'carestream large' > > which presumably preserves maximum details relevant to the exercise. > > > > Request moderators to please let this and the previous mail pass through > > to relevant recipients. > > The mail with attachment is not yet approved or rejected by the moderator. > > I have kept the image contents here: > http://mayuresh.sdfeu.org/snaps.zip > -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"
Re: [sane-devel] Sane backend for an intraoral X ray camera
carestream large is a Kodak (now CS Dental) specific format known as .RVG. I don't believe they can be opened outside of CS's various imaging apps. Can you see if you can export it to DICOM or TIFF or other such more standard format? On Tue, Dec 15, 2020 at 3:12 PM Mayuresh wrote: > On Tue, Dec 15, 2020 at 10:56:25PM +0530, Mayuresh wrote: > > On Mon, Dec 14, 2020 at 08:12:38AM -0500, m. allan noah wrote: > > > usbmon is truncated, and the final image is necessary to determine top > > > vs bottom, left vs right, etc. So we need a wireshark and an image > > > from the same scan. > > > > PFA: > > > > lsusb: lsusb -v description of the device > > > > snaps3.pcapng.gz: wireshark output right from starting windows till > taking > > 3 x rays and closing windows > > > > I am stuck with sharing the actual images due to some samba issue. Will > > share them shortly. > > There were 3 x rays taken, just to give more room for observation, out of > which first was discarded as it was completely dark. Attaching a zip of > the remaining two. Have chosen an export format called 'carestream large' > which presumably preserves maximum details relevant to the exercise. > > Request moderators to please let this and the previous mail pass through > to relevant recipients. >
Re: [sane-devel] Sane backend for an intraoral X ray camera
On Tue, Dec 15, 2020 at 11:01:43PM +0530, Mayuresh wrote: > Due to size of the attachment (gzipped 750k) the message has gone to > moderator approval. FYI please. Same with a second mail wherein I have attached the images. Request the moderators to please let it reach the relevant recipients.
Re: [sane-devel] Sane backend for an intraoral X ray camera
On Mon, Dec 14, 2020 at 08:12:38AM -0500, m. allan noah wrote: > usbmon is truncated, and the final image is necessary to determine top > vs bottom, left vs right, etc. So we need a wireshark and an image > from the same scan. Due to size of the attachment (gzipped 750k) the message has gone to moderator approval. FYI please.
Re: [sane-devel] Sane backend for an intraoral X ray camera
usbmon is truncated, and the final image is necessary to determine top vs bottom, left vs right, etc. So we need a wireshark and an image from the same scan. allan On Sun, Dec 13, 2020 at 9:45 PM Mayuresh wrote: > > On Sun, Dec 13, 2020 at 05:08:31PM -0500, m. allan noah wrote: > > I don't see anything immediately obvious in the protocol, but we > > really need to see some scans. Even without the xray source we may > > learn something. But certainly the xray source, and the final image > > produced by the windows software will be required to be sure. > > Right now I am having the attached usbmon output where 2 back to back > snaps (x rays) were taken. This one has missed some initial part which is > present in the previous snaps (wireshark and usbmon) that I attached. > > The final image produced by windows software is probably not of much use > for the protocol for 1. It is compressed while the device returns raw. > Both snaps consistently show 3648832 bytes were returned as bulk out by > the device while the final images are around 1MB. 2. It adds additional > information such as patient name, date etc which is not really coming from > the device. So wireshark/usbmon may offer better clues than image produced > by the windows software. > > Will try and share the image over some time. -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"
Re: [sane-devel] Sane backend for an intraoral X ray camera
On Sun, Dec 13, 2020 at 05:08:31PM -0500, m. allan noah wrote: > I don't see anything immediately obvious in the protocol, but we > really need to see some scans. Even without the xray source we may > learn something. But certainly the xray source, and the final image > produced by the windows software will be required to be sure. Right now I am having the attached usbmon output where 2 back to back snaps (x rays) were taken. This one has missed some initial part which is present in the previous snaps (wireshark and usbmon) that I attached. The final image produced by windows software is probably not of much use for the protocol for 1. It is compressed while the device returns raw. Both snaps consistently show 3648832 bytes were returned as bulk out by the device while the final images are around 1MB. 2. It adds additional information such as patient name, date etc which is not really coming from the device. So wireshark/usbmon may offer better clues than image produced by the windows software. Will try and share the image over some time. 9a7e27e90c00 2077710468 C Ii:1:014:1 -2:8 0 9a7e6a88e9c0 2077751699 S Ii:1:014:1 -115:8 2 < 9a7e6a88e9c0 2078707765 C Ii:1:014:1 -2:8 0 9a7e27e90840 2078748352 S Ii:1:014:1 -115:8 2 < 9a7e27e90840 2079725117 C Ii:1:014:1 -2:8 0 9a7e6b018a80 2079806458 S Ii:1:014:1 -115:8 2 < 9a7e6b018a80 2080741043 C Ii:1:014:1 -2:8 0 9a7e6a88ef00 2080781014 S Ii:1:014:1 -115:8 2 < 9a7e6a88ef00 2081758837 C Ii:1:014:1 -2:8 0 9a7e6b018540 2081839959 S Ii:1:014:1 -115:8 2 < 9a7e6b018540 2082754282 C Ii:1:014:1 -2:8 0 9a7e6a88ee40 2082815789 S Ii:1:014:1 -115:8 2 < 9a7e6a88ee40 2083769489 C Ii:1:014:1 -2:8 0 9a7e6b018900 2083810199 S Ii:1:014:1 -115:8 2 < 9a7e6b018900 2084769873 C Ii:1:014:1 -2:8 0 9a7e2972cc00 2084809990 S Ii:1:014:1 -115:8 2 < 9a7e2972cc00 2085786276 C Ii:1:014:1 -2:8 0 9a7e6a88e300 2085866753 S Ii:1:014:1 -115:8 2 < 9a7e6a88e300 2086800899 C Ii:1:014:1 -2:8 0 9a7e6a88ec00 2086861556 S Ii:1:014:1 -115:8 2 < 9a7e6a88ec00 2087799394 C Ii:1:014:1 -2:8 0 9a7e2972ccc0 2087860799 S Ii:1:014:1 -115:8 2 < 9a7e2972ccc0 2088817201 C Ii:1:014:1 -2:8 0 9a7e6a88ea80 2088918508 S Ii:1:014:1 -115:8 2 < 9a7e6a88ea80 2089834581 C Ii:1:014:1 -2:8 0 9a7e2972ccc0 2089915779 S Ii:1:014:1 -115:8 2 < 9a7e2972ccc0 2090831761 C Ii:1:014:1 -2:8 0 9a7e27e909c0 2090893474 S Ii:1:014:1 -115:8 2 < 9a7e27e909c0 2091832603 C Ii:1:014:1 -2:8 0 9a7e6a88ee40 2091873641 S Ii:1:014:1 -115:8 2 < 9a7e6a88ee40 2092847208 C Ii:1:014:1 -2:8 0 9a7e6a88e0c0 2092948165 S Ii:1:014:1 -115:8 2 < 9a7e6a88e0c0 2093866738 C Ii:1:014:1 -2:8 0 9a7e27e90c00 2093926879 S Ii:1:014:1 -115:8 2 < 9a7e27e90c00 2094868633 C Ii:1:014:1 -2:8 0 9a7e6b018cc0 2094909293 S Ii:1:014:1 -115:8 2 < 9a7e6b018cc0 2095869982 C Ii:1:014:1 -2:8 0 9a7e2972cc00 2095910144 S Ii:1:014:1 -115:8 2 < 9a7e2972cc00 2096861974 C Ii:1:014:1 -2:8 0 9a7e27e900c0 2096963171 S Ii:1:014:1 -115:8 2 < 9a7e27e900c0 2097881155 C Ii:1:014:1 -2:8 0 9a7e2972c540 2097941397 S Ii:1:014:1 -115:8 2 < 9a7e2972c540 2098878899 C Ii:1:014:1 -2:8 0 9a7e27e90540 2098919046 S Ii:1:014:1 -115:8 2 < 9a7e27e90540 2099897174 C Ii:1:014:1 -2:8 0 9a7e6a88e9c0 208997 S Ii:1:014:1 -115:8 2 < 9a7e6a88e9c0 2100898493 C Ii:1:014:1 -2:8 0 9a7e2972c840 2100979982 S Ii:1:014:1 -115:8 2 < 9a7e2972c840 2101900100 C Ii:1:014:1 -2:8 0 9a7e6b018300 2101981540 S Ii:1:014:1 -115:8 2 < 9a7e6b018300 2102898305 C Ii:1:014:1 -2:8 0 9a7e27e900c0 2102979824 S Ii:1:014:1 -115:8 2 < 9a7e27e900c0 2103895721 C Ii:1:014:1 -2:8 0 9a7e2972c240 2103977473 S Ii:1:014:1 -115:8 2 < 9a7e2972c240 2104893721 C Ii:1:014:1 -2:8 0 9a7e2972c240 2104975051 S Ii:1:014:1 -115:8 2 < 9a7e2972c240 2105909745 C Ii:1:014:1 -2:8 0 9a7e27e90840 2105973813 S Ii:1:014:1 -115:8 2 < 9a7e27e90840 2106910162 C Ii:1:014:1 -2:8 0 9a7e2972c780 2106970606 S Ii:1:014:1 -115:8 2 < 9a7e2972c780 2107911223 C Ii:1:014:1 -2:8 0 9a7e27e90d80 2107951381 S Ii:1:014:1 -115:8 2 < 9a7e27e90d80 2108927471 C Ii:1:014:1 -2:8 0 9a7e27e9 2109008694 S Ii:1:014:1 -115:8 2 < 9a7e27e9 2109923932 C Ii:1:014:1 -2:8 0 9a7e6a88ec00 2109984240 S Ii:1:014:1 -115:8 2 < 9a7e6a88ec00 2110943376 C Ii:1:014:1 -2:8 0 9a7e2972c180 2110984222 S Ii:1:014:1 -115:8 2 < 9a7e2972c180 2111943609 C Ii:1:014:1 -2:8 0 9a7e2972c180 2111983519 S Ii:1:014:1 -115:8 2 < 9a7e2972c180 2112942550 C Ii:1:014:1 0:8 2 = 0002 9a7e6b018840 2113040161 S Ii:1:014:1 -115:8 2 < 9a7e6b018840 2113441900 C Ii:1:014:1 0:8 2 = 9a7e6b018840 2113446786 S Ii:1:014:1 -115:8 2 < 9a7e2972c3c0 2113454840 S Bi:1:014:2 -115 7680 < 9a7e2972c3c0 2113947507 C Bi:1:014:2 0 7680 = ff0fff0f ff0fff0f ff0fff0f ff0fff0f ff0fff0f ff0fff0f ff0fff0f ff0fff0f 9a7e2972c3c0 2113948062 S Bi:1:014:2 -115 57856
Re: [sane-devel] Sane backend for an intraoral X ray camera
On Sun, Dec 13, 2020 at 10:45:37AM -0800, Ralph Little wrote: > It is a long shot, but you could ask the manufacturer for protocol > information. The retailers are reachable as one may guess they don't even know the word protocol or some haven't heard of Linux. All that they say is if you want another installation how much the license cost is. They assert it won't work without their software. The manufacturer hasn't responded on this a while back. I will try writing again. There is only one presentation by the company where it says the device is TWAIN compatible (link shared in the first post). Someone suggested me to ask alibaba.com[1] as they might answer these queries better. But the product page is in German only (even if I search the product on their English website). So not sure about the link where I can post an English question. [1] https://german.alibaba.com/product-detail/lk-c64-rvg-5200-x-ray-sensor-dental-digital-x-ray-sensor-60431854823.html
Re: [sane-devel] Sane backend for an intraoral X ray camera
I don't see anything immediately obvious in the protocol, but we really need to see some scans. Even without the xray source we may learn something. But certainly the xray source, and the final image produced by the windows software will be required to be sure. allan On Sun, Dec 13, 2020 at 10:59 AM Mayuresh wrote: > > On Sun, Dec 13, 2020 at 09:39:03AM -0500, m. allan noah wrote: > > I think you have far more work to do than you realize.The first step > > would be to get some usb logs of the scanner in action using wireshark > > on windows. Someone here may recognize the image format or protocol. > > Yes, I have those with wireshark as well as usbmon (attached). These are > prior to actually getting the image (which requires going to a dental > clinic to get the device exposed to x ray, so might take some time). > > For wireshark following filter selects the device: > > usb.bus_id == 1 and usb.device_address == 6 > > usbmon has a limitation that it won't show more than 32 bytes per event. > > I am baffled by the difference in end-point numbers shown by wireshark and > usbmon. Those in usbmon match with lsusb, those in wireshark don't. > -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"
Re: [sane-devel] Sane backend for an intraoral X ray camera
Hi, On 2020-12-13 7:59 a.m., Mayuresh wrote: > On Sun, Dec 13, 2020 at 09:39:03AM -0500, m. allan noah wrote: >> I think you have far more work to do than you realize.The first step >> would be to get some usb logs of the scanner in action using wireshark >> on windows. Someone here may recognize the image format or protocol. > Yes, I have those with wireshark as well as usbmon (attached). These are > prior to actually getting the image (which requires going to a dental > clinic to get the device exposed to x ray, so might take some time). > > For wireshark following filter selects the device: > > usb.bus_id == 1 and usb.device_address == 6 > > usbmon has a limitation that it won't show more than 32 bytes per event. > > I am baffled by the difference in end-point numbers shown by wireshark and > usbmon. Those in usbmon match with lsusb, those in wireshark don't. > It is a long shot, but you could ask the manufacturer for protocol information. They mostly ignore requests of this kind or give some b*llshit excuse, but it you don't try, you don't know. Cheers, Ralph
Re: [sane-devel] Sane backend for an intraoral X ray camera
On Sun, Dec 13, 2020 at 09:39:03AM -0500, m. allan noah wrote: > I think you have far more work to do than you realize.The first step > would be to get some usb logs of the scanner in action using wireshark > on windows. Someone here may recognize the image format or protocol. Yes, I have those with wireshark as well as usbmon (attached). These are prior to actually getting the image (which requires going to a dental clinic to get the device exposed to x ray, so might take some time). For wireshark following filter selects the device: usb.bus_id == 1 and usb.device_address == 6 usbmon has a limitation that it won't show more than 32 bytes per event. I am baffled by the difference in end-point numbers shown by wireshark and usbmon. Those in usbmon match with lsusb, those in wireshark don't. rvgstartup.pcapng Description: Binary data 9b06ebff3840 1496354627 S Ci:1:006:0 s 80 06 0100 0012 18 < 9b06ebff3840 1496354806 C Ci:1:006:0 0 18 = 12010002 ff40 2b080a10 0102 0301 9b06ebff3840 1496354838 S Ci:1:006:0 s 80 06 0200 0009 9 < 9b06ebff3840 1496355001 C Ci:1:006:0 0 9 = 09022e00 010105a0 64 9b06ebff3840 1496355015 S Ci:1:006:0 s 80 06 0200 002e 46 < 9b06ebff3840 1496355072 C Ci:1:006:0 0 46 = 09022e00 010105a0 64090400 0004ff00 00060705 81034000 04070582 02000201 9b06ebff3840 1496355088 S Ci:1:006:0 s 80 06 0300 00ff 255 < 9b06ebff3840 1496355128 C Ci:1:006:0 0 4 = 04030904 9b06ebff3840 1496355137 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 < 9b06ebff3840 1496355194 C Ci:1:006:0 0 28 = 1c035200 56004700 20003500 32003000 30002f00 36003200 30003000 9b06ebff3840 1496355207 S Ci:1:006:0 s 80 06 0301 0409 00ff 255 < 9b06ebff3840 1496355262 C Ci:1:006:0 0 14 = 0e035400 72006f00 70006800 7900 9b06ebff3840 1496355272 S Ci:1:006:0 s 80 06 0303 0409 00ff 255 < 9b06ebff3840 1496355329 C Ci:1:006:0 0 22 = 16035200 56004700 35007800 36007800 20002000 2000 9b06ebff3840 1496357438 S Co:1:006:0 s 00 09 0001 0 9b06ebff3840 1496357491 C Co:1:006:0 0 0 9b06ebff3840 1496357542 S Ci:1:006:0 s 80 06 0305 0409 00ff 255 < 9b06ebff3840 1496357609 C Ci:1:006:0 0 22 = 16036800 69006700 68002000 73007000 65006500 6400 9b06ebff3840 1496357691 S Ci:1:006:0 s 80 06 0306 0409 00ff 255 < 9b06ebff3840 1496357761 C Ci:1:006:0 0 10 = 0a034200 75006c00 6b00 9b06f96a3a80 1496703264 S Ci:1:006:0 s 80 06 0100 0012 18 < 9b06f96a3a80 1496703390 C Ci:1:006:0 0 18 = 12010002 ff40 2b080a10 0102 0301 9b06f96a3a80 1496703534 S Ci:1:006:0 s 80 06 0200 0009 9 < 9b06f96a3a80 1496703592 C Ci:1:006:0 0 9 = 09022e00 010105a0 64 9b06ebff3480 1496803926 S Ci:1:006:0 s 80 06 0200 002e 46 < 9b06ebff3480 1496804267 C Ci:1:006:0 0 46 = 09022e00 010105a0 64090400 0004ff00 00060705 81034000 04070582 02000201 9b06ebff3480 1497202675 S Ci:1:006:0 s 80 06 0100 0012 18 < 9b06ebff3480 1497202825 C Ci:1:006:0 0 18 = 12010002 ff40 2b080a10 0102 0301 9b06ebff3480 1497202896 S Ci:1:006:0 s 80 06 0200 002e 46 < 9b06ebff3480 1497202969 C Ci:1:006:0 0 46 = 09022e00 010105a0 64090400 0004ff00 00060705 81034000 04070582 02000201 9b06ebff3480 1497202991 S Ci:1:006:0 s 80 06 0303 0409 00ff 255 < 9b06ebff3480 1497203202 C Ci:1:006:0 0 22 = 16035200 56004700 35007800 36007800 20002000 2000 9b06ebff3480 1497203616 S Co:1:006:0 s 00 09 0001 0 9b06ebff3480 1497203794 C Co:1:006:0 0 0 9b06ebff3480 1497538067 S Ci:1:006:0 s 80 06 0100 0012 18 < 9b06ebff3480 1497538185 C Ci:1:006:0 0 18 = 12010002 ff40 2b080a10 0102 0301 9b06ebff3480 1497538249 S Ci:1:006:0 s 80 06 0200 002e 46 < 9b06ebff3480 1497538664 C Ci:1:006:0 0 46 = 09022e00 010105a0 64090400 0004ff00 00060705 81034000 04070582 02000201 9b06ebff3480 1497538690 S Ci:1:006:0 s 80 06 0303 0409 00ff 255 < 9b06ebff3480 1497538805 C Ci:1:006:0 0 22 = 16035200 56004700 35007800 36007800 20002000 2000 9b06ebff3480 1497539242 S Co:1:006:0 s 00 09 0001 0 9b06ebff3480 1497539299 C Co:1:006:0 0 0 9b06ea268180 1497661504 S Ci:1:006:0 s 80 06 0300 00ff 255 < 9b06ea268180 1497661911 C Ci:1:006:0 0 4 = 04030904 9b06f2d966c0 1497665909 S Ci:1:006:0 s 80 06 0303 0409 00ff 255 < 9b06f2d966c0 1497666451 C Ci:1:006:0 0 22 = 16035200 56004700 35007800 36007800 20002000 2000 9b06ea268240 1497676132 S Ci:1:006:0 s 80 06 0300 00ff 255 < 9b06ea268240 1497676273 C Ci:1:006:0 0 4 = 04030904 9b06f2d966c0 1497679419 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 < 9b06f2d966c0 1497679780 C Ci:1:006:0 0 28 = 1c035200 56004700 20003500 32003000 30002f00 36003200 30003000 9b06f2d96c00 1497682631 S Ci:1:006:0 s 80 06 0300 00ff 255 < 9b06f2d96c00 1497682770 C Ci:1:006:0 0 4 = 04030904 9b06f2d969c0 1497685844 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 < 9b06f2d969c0 1497686269 C Ci:1:006:0 0 28 = 1c035200 56004700
Re: [sane-devel] Sane backend for an intraoral X ray camera
I'm not familiar with the pint interface, but I'd be surprised if it works generically with any twain scanner. How would the windows twain driver run on BSD without some kind of OS emulator? I think you have far more work to do than you realize.The first step would be to get some usb logs of the scanner in action using wireshark on windows. Someone here may recognize the image format or protocol. allan On Sun, Dec 13, 2020 at 9:10 AM Mayuresh wrote: > > I am trying to get sane work with a digital X ray device used for > dentistry described here [1] on Linux (Ubuntu 20.04) or on NetBSD 9.1. > > The device works only on Windows with proprietary software bundled with > the driver provided by the manufacturer. However [1] says "Allows for > direct acquisition with TWAIN compliant third party imaging software" > which gives a hope that it might work with sane on Linux / NetBSD. > > The device is detected by sane-find-scanner as: > found USB scanner (vendor=0x082b, product=0x000c) at libusb:001:009 > > I believe, TWAIN device requires pint backend > > In dll.conf I have mentioned pint and in pint.conf mentioned the device as > /dev/ugen0.0 on NetBSD (that's how it is detected), but scanimage -L > doesn't detect it. Or trying to use scanimage -d pint:/dev/ugen0.0 doesn't > work. > > On Ubuntu sane backends do not include pint and I might have to build from > sources. But before that thought of asking whether it has a chance of > working. Also, on Linux systems what path should be mentioned in pint.conf > - is it something like /dev/bus/usb/001/009 etc or something else? > > > [1] > https://de.slideshare.net/smokeypike/the-rvg-5200-from-carestream-dental-digital > > -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"
[sane-devel] Sane backend for an intraoral X ray camera
I am trying to get sane work with a digital X ray device used for dentistry described here [1] on Linux (Ubuntu 20.04) or on NetBSD 9.1. The device works only on Windows with proprietary software bundled with the driver provided by the manufacturer. However [1] says "Allows for direct acquisition with TWAIN compliant third party imaging software" which gives a hope that it might work with sane on Linux / NetBSD. The device is detected by sane-find-scanner as: found USB scanner (vendor=0x082b, product=0x000c) at libusb:001:009 I believe, TWAIN device requires pint backend In dll.conf I have mentioned pint and in pint.conf mentioned the device as /dev/ugen0.0 on NetBSD (that's how it is detected), but scanimage -L doesn't detect it. Or trying to use scanimage -d pint:/dev/ugen0.0 doesn't work. On Ubuntu sane backends do not include pint and I might have to build from sources. But before that thought of asking whether it has a chance of working. Also, on Linux systems what path should be mentioned in pint.conf - is it something like /dev/bus/usb/001/009 etc or something else? [1] https://de.slideshare.net/smokeypike/the-rvg-5200-from-carestream-dental-digital
