On 12/10/22 14:22, Karsten Hilbert wrote:
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
El mié, 12 oct 2022 10:15:30 -0300, Sébastien Jodogne escribió
>
> On 12/10/22 14:22, Karsten Hilbert wrote:
> > 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
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
El mié, 12 oct 2022 08:44:51 -0300, Leonardo M. Ramé
leonardo.r...@informemedico.com.ar> escribió
> El mié, 12 oct 2022 08:28:57 -0300, Mayuresh escribió
>
> > On Tue, Oct 11, 2022 at 11:22:20AM -0300, Leonardo M. Ramé wrote:
> > > I would like to reach Mayuresh
El mié, 12 oct 2022 08:28:57 -0300, Mayuresh escribió
> On Tue, Oct 11, 2022 at 11:22:20AM -0300, Leonardo M. Ramé wrote:
> > I would like to reach Mayuresh hoping to find a solution to this.
>
> Hi. Glad to see your interest in this problem.
>
> Unfortunately I do not
On Tue, Oct 11, 2022 at 11:22:20AM -0300, Leonardo M. Ramé wrote:
> I would like to reach Mayuresh hoping to find a solution to this.
Hi. Glad to see your interest in this problem.
Unfortunately I do not still have a solution. I tried some brute force
method like machine learning, the results
Hi, I have the same problem, please read my analysis here:
https://github.com/nroduit/Weasis/discussions/335
I would like to reach Mayuresh hoping to find a solution to this.
Regards,
Leonardo M. Ramé
InformeMedico.com.ar
Tel.: +54 9 (0351) 6629292
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
On Sun, Feb 13, 2022 at 01:35:35PM +0100, Karsten Hilbert wrote:
> https://groups.google.com/g/orthanc-users/c/8pOUQJH2oTs
>
> help in any way ?
No luck with that thread.
--
Mayuresh
On Sun, Feb 13, 2022 at 12:15:13AM +0530, Mayuresh wrote:
> - Will possibly try an LUT now. Again not very elegant, but might be more
> accurate than neural net and less costly. But not sure, whether across
> images the lookup table would be uniform or not.
Ruled this out. Across images, LUT
> > 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:
>
On Sun, Feb 13, 2022 at 12:15:13AM +0530, Mayuresh wrote:
> 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)
On Wed, Jan 05, 2022 at 03:19:12PM +0100, Karsten Hilbert wrote:
> > 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:
Some updates:
- Using various OpenCV recipes or
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 =
You may want to give CLAHE (Contrast Limited Adaptive Histogram
Equalization) a try.
It's implemented in OpenCV.
--
Jakub Wilk
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
>
On Sunday, December 26, 2021 08:06:14 AM Mayuresh wrote:
> 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
On Fri, Dec 24, 2021 at 10:20:19AM +0100, Karsten Hilbert wrote:
> > Notably, the vendor image pushes pixel weighting way to the
> > extreme, things are either "nearly black" or "nearly white".
Printing a map between raw and transformed pixel values shows that for a
given raw pixel value there
- 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
On Tue, Dec 21, 2021 at 11:17:02AM +0100, Andreas Tille wrote:
> Given that you are programming in Python I'd recommend PIL to do some
> image processing. If you want to do some post-processing possibly
> ImageMagick is your friend.
Sure, that helps. I'll use either of these once I figure out
Hi,
Am Tue, Dec 21, 2021 at 01:04:21PM +0530 schrieb Mayuresh:
> Reviving this[1] old thread after a gap of 1 year.
>
> Thanks to the thread this[2] open source implementation to interact with a
> dental RVG device got developed. As of my pausing this work it was
> possible to extract the X ray
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.
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 endian 0
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:
>
>
>
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
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
ExifTool Version
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
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
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
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.
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 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
clues as
> 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 by means of radiation. > > (It
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 by means of radiation.
>
> (It is only
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 practiced or
not and
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:
-
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
> 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
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
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) has a 3
> to 4
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,
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
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
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
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.
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
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.
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 "how much light" (xrays)
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 software.
>
> Precisely planning
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 Health
> Group was sold to
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
> > the device (even
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
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 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
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 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
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
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
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)
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
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 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
Am Samstag, 2. Januar 2021, 09:34:52 CET schrieb Sonali Warunjikar:
> 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
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 there are
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! (I
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
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 in pixel
>
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,
Am Freitag, 1. Januar 2021, 09:34:58 CET schrieb Sonali Warunjikar:
> 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
>
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 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.
For what it's
> 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
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
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
> > 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: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 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: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
>
> 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,
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 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
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
> 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)
1 - 100 of 184 matches
Mail list logo
