summaryrefslogtreecommitdiff
path: root/doc/teco/teco2.txt
diff options
context:
space:
mode:
authorJörg Frings-Fürst <debian@jff-webhosting.net>2019-07-31 16:59:49 +0200
committerJörg Frings-Fürst <debian@jff-webhosting.net>2019-07-31 16:59:49 +0200
commit1687222e1b9e74c89cafbb5910e72d8ec7bfd40f (patch)
treed78102ce30207c63e7608eeba743efd680c888dc /doc/teco/teco2.txt
parent58912f68c2489bcee787599837447e0d64dfd61a (diff)
New upstream version 1.0.28upstream/1.0.28
Diffstat (limited to 'doc/teco/teco2.txt')
-rw-r--r--doc/teco/teco2.txt65
1 files changed, 32 insertions, 33 deletions
diff --git a/doc/teco/teco2.txt b/doc/teco/teco2.txt
index 5b64a83..b45b795 100644
--- a/doc/teco/teco2.txt
+++ b/doc/teco/teco2.txt
@@ -4,15 +4,15 @@
INQUIRY
TECO VM3564 (1)
-000: 06 00 02 02 43 00 00 10 52 45 4c 49 53 59 53 20 ....C...RELISYS
-016: 41 56 45 43 20 49 49 20 53 33 20 20 20 20 20 20 AVEC II S3
+000: 06 00 02 02 43 00 00 10 52 45 4c 49 53 59 53 20 ....C...RELISYS
+016: 41 56 45 43 20 49 49 20 53 33 20 20 20 20 20 20 AVEC II S3
032: 31 2e 30 37 31 2e 30 37 00 01 54 45 43 4f 20 56 1.071.07..TECO V
048: 4d 33 35 36 34 20 00 01 01 2c 00 01 02 58 09 f6 M3564 ...,...X..
064: 0d af 01 2c 00 08 01 00 ...,....
TECO VM3564 (2)
-000: 06 00 02 02 43 00 00 10 52 45 4c 49 53 59 53 20 ....C...RELISYS
-016: 41 56 45 43 20 49 49 20 53 33 20 20 20 20 20 20 AVEC II S3
+000: 06 00 02 02 43 00 00 10 52 45 4c 49 53 59 53 20 ....C...RELISYS
+016: 41 56 45 43 20 49 49 20 53 33 20 20 20 20 20 20 AVEC II S3
032: 31 2e 30 39 31 2e 30 39 00 01 54 45 43 4f 20 56 1.091.09..TECO V
048: 4d 33 35 36 34 20 00 01 01 2c 00 01 02 58 09 f6 M3564 ...,...X..
064: 0d af 01 2c 00 08 01 00 ...,....
@@ -25,21 +25,21 @@ TECO VM356A (1)
064: 0d af 01 2c 00 08 01 00 ...,....
TECO VM356A (2)
-000: 06 00 02 02 43 00 00 10 50 72 69 6d 61 78 20 20 ....C...Primax
-016: 4a 65 77 65 6c 20 20 20 20 20 20 20 20 20 20 20 Jewel
+000: 06 00 02 02 43 00 00 10 50 72 69 6d 61 78 20 20 ....C...Primax
+016: 4a 65 77 65 6c 20 20 20 20 20 20 20 20 20 20 20 Jewel
032: 31 2e 30 31 31 2e 30 31 00 01 54 45 43 4f 20 56 1.011.01..TECO V
048: 4d 33 35 36 41 20 00 01 01 2c 00 01 02 58 09 f6 M356A ...,...X..
064: 0d af 01 2c 00 08 01 00 ...,....
TECO VM3575
-000: 06 00 02 02 43 00 00 00 20 20 20 20 20 20 20 20 ....C...
-016: 46 6c 61 74 62 65 64 20 53 63 61 6e 6e 65 72 20 Flatbed Scanner
+000: 06 00 02 02 43 00 00 00 20 20 20 20 20 20 20 20 ....C...
+016: 46 6c 61 74 62 65 64 20 53 63 61 6e 6e 65 72 20 Flatbed Scanner
032: 31 2e 30 33 31 2e 30 33 00 01 54 45 43 4f 20 56 1.031.03..TECO V
048: 4d 33 35 37 35 20 00 01 01 2c 00 01 02 58 09 f6 M3575 ...,...X..
064: 0d af 01 2c 00 08 01 00 ...,....
TECO VM656A
-000: 06 00 02 02 43 00 00 00 52 45 4c 49 53 59 53 20 ....C...RELISYS
+000: 06 00 02 02 43 00 00 00 52 45 4c 49 53 59 53 20 ....C...RELISYS
016: 41 50 4f 4c 4c 4f 20 45 78 70 72 65 73 73 20 36 APOLLO Express 6
032: 31 2e 30 33 31 2e 30 33 00 01 54 45 43 4f 20 56 1.031.03..TECO V
048: 4d 36 35 36 41 00 01 01 2c 00 01 02 58 09 f6 0d M656A...,...X...
@@ -53,8 +53,8 @@ TECO VM6575
064: 0d af 01 2c 00 08 01 00 ...,....
TECO VM6586
-000: 06 00 02 02 43 00 00 00 20 20 20 20 20 20 20 20 ....C...
-016: 46 6c 61 74 62 65 64 20 53 63 61 6e 6e 65 72 20 Flatbed Scanner
+000: 06 00 02 02 43 00 00 00 20 20 20 20 20 20 20 20 ....C...
+016: 46 6c 61 74 62 65 64 20 53 63 61 6e 6e 65 72 20 Flatbed Scanner
032: 33 2e 30 31 33 2e 30 31 00 01 54 45 43 4f 20 56 3.013.01..TECO V
048: 4d 36 35 38 36 20 00 01 01 2c 00 01 02 58 09 f6 M6586 ...,...X..
064: 0d af 01 2c 00 08 01 00 ...,....
@@ -93,7 +93,7 @@ Set calibration. Apparently the line is computed from the calibration lines. It
INQUIRY
-12 00 00 00 48 00
+12 00 00 00 48 00
standard inquiry
72 bytes
32-39: firmware version
@@ -123,8 +123,8 @@ SET WINDOW
24 00 00 00 00 00 00 00 35 00 (VM3575)
24 00 00 00 00 00 00 00 38 00 (VM6586)
-Total length is
- 07 = length
+Total length is
+ 07 = length
VM3575 53-8 = 45
VM6586 56-8 = 48
VM3552 69-8 = 61
@@ -142,11 +142,11 @@ Total length is
34 = bit depth? - invariant, always 8
36 = (vm6586 only ?) halftone pattern ?
1 = type 1 dithering
- 37 =
+ 37 =
0x80 = RIF?
48 = color channel to use
if scan mode is 0 or 2:
- 0x00 = red
+ 0x00 = red
0x01 = green
0x02 = blue
if scan mode is 05 -> ignored
@@ -161,10 +161,10 @@ Total length is
READ
28 00 00 00 00 19 00 1f 0e 00
5 = number of lines to read
- 7-8 = buffer size.
+ 7-8 = buffer size.
Always number of lines to read * size of a line.
0x2000 appears to be the upper limit
-
+
SEND
2A 00 03 00 00 04 00 0C 00 00
@@ -194,7 +194,7 @@ GET DATA BUFFER STATUS
7 = ? always 0x14
11 = bit 7 - (maybe) scanner is ready to send data
12-13 = number of lines (constant during a scan)
- 14-15 = bytes per line (constant during a scan)
+ 14-15 = bytes per line (constant during a scan)
16-17 = garbage (the command only returns 0x10 bytes)
@@ -236,32 +236,31 @@ TECO VM656A reads 8 lines of calibration
TECO VM6586 ??
Algorithms used (text from Alex Wulms):
-The old algorithm was based on the assumption that the calibration value needs
-to be an offset, to go from the value obtained during input to the average
+The old algorithm was based on the assumption that the calibration value needs
+to be an offset, to go from the value obtained during input to the average
value (0x800).
-E.g., if the input value is 0x800, the calibration value must be 0x800 (0x1000
+E.g., if the input value is 0x800, the calibration value must be 0x800 (0x1000
- 0x800).
-Likewise, if the input value is 0x700, the calibration value must be 0x900
+Likewise, if the input value is 0x700, the calibration value must be 0x900
(0x1000 - 0x700)
And if the input value is 0x600, the calibration value must be 0xA00
-The new algorithm is based on the assumption that the calibration needs to be
-a multiplication factor, to compensate for the too strong or too weak pixel
-in the sensor. Again, we want to obtain the average value (approximately
+The new algorithm is based on the assumption that the calibration needs to be
+a multiplication factor, to compensate for the too strong or too weak pixel
+in the sensor. Again, we want to obtain the average value (approximately
0x800) for every pixel read during calibration.
-E.g., if the input value is 0x800, the calibration value must be 0x800
+E.g., if the input value is 0x800, the calibration value must be 0x800
(0x800*0x800 / 0x800).
-Likewise, if the input value is 0x700, the calibration value must be 0x924
+Likewise, if the input value is 0x700, the calibration value must be 0x924
(0x800*0x800 / 0x700).
-And if the input value is 0x600, the calibration value must 0xAAA (0x800*0x800
+And if the input value is 0x600, the calibration value must 0xAAA (0x800*0x800
/ 0x600)
-Though, carefull comparison with scans done under windows has shown that the
-factor is slightly different from 0x800*0x800(=0x400000) but in stead it
-seems to be approximately 0x40302f (which would mean that the average value
+Though, carefull comparison with scans done under windows has shown that the
+factor is slightly different from 0x800*0x800(=0x400000) but in stead it
+seems to be approximately 0x40302f (which would mean that the average value
is approximately 0x803 in stead of 0x800).
Hope this is clarifies the new algorithm.
-