Yesterday I got a sort of crazy idea: "What if I could make my oscilloscope hardcopy to email instead of the broken built-in printer?". As it turns out, the LeCroy 93xx series is capable of both accepting remote control commands and dumping hardcopies to the same RS-232-C bus - write 'SCREEN_DUMP' and it will dump it in the same session, pretty sweet.
The 93xx series features quite a lot of output formats ranging from BMP and all the way to some odd format called HP 7550 which I assume is before my time - BMP and TIFF sadly taking 40 seconds at 19200 baud to fully process. HP 7550 took around 9 seconds, but after some googling I gave up on that format - it seemed to be very troublesome to get something working with that format. Finally I settled for the compressed TIFF format (12 seconds @ 19200 baud) - the problem was that the file received from the oscilloscope was not something libtiff gladly wanted to process.
When I gave the file to imagemagick's identify program, it didn't want to play along.
Fair enough. I tried to open it in Photoshop which to my great surprise actually worked - which meant that all the data was available but the format was corrupted.
Libtiff was helpful enough to provide me with a number: 70992 and 26911 - 70992 is located as a long at 0x7E in the TIFF header, but what about 26911? Replacing 70922 with 26911 fixed this one TIFF, but I needed to know how to calculate this number. This is where the utility called exiftool comes along.
Some quick math: file_size - 26911 = 1746 (Strip Offsets). In reality I did check how libtiff calculates the error message's "expect" value and then verified it with exiftool, but you get the idea.
Result: 9350_fix_tiff.py
This script has evolved and now contains an SMTP function which sends the hardcopy as a color and B/W attachment (PNG format) to my email when I press "Screen dump". Pretty neat if I may say so myself.
The 93xx series features quite a lot of output formats ranging from BMP and all the way to some odd format called HP 7550 which I assume is before my time - BMP and TIFF sadly taking 40 seconds at 19200 baud to fully process. HP 7550 took around 9 seconds, but after some googling I gave up on that format - it seemed to be very troublesome to get something working with that format. Finally I settled for the compressed TIFF format (12 seconds @ 19200 baud) - the problem was that the file received from the oscilloscope was not something libtiff gladly wanted to process.
When I gave the file to imagemagick's identify program, it didn't want to play along.
# identify -verbose filecomp.tiff
Image: filecomp.tiff
Format: TIFF (Tagged Image File Format)
Class: DirectClass
Geometry: 816x696+0+0
Resolution: 121.791x148.085
Print size: 6.7x4.7
Units: PixelsPerInch
Type: Bilevel
Base type: Bilevel
Endianess: MSB
Colorspace: RGB
Rendering intent: Undefined
Interlace: None
Background color: white
Border color: rgb(223,223,223)
Matte color: grey74
Transparent color: black
Compose: Over
Page geometry: 816x696+0+0
Dispose: Undefined
Iterations: 0
Compression: RLE
Orientation: TopLeft
Properties:
date:create: 2011-03-09T17:48:01+01:00
date:modify: 2011-03-09T17:48:01+01:00
signature: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
tiff:photometric: min-is-white
tiff:rows-per-strip: 696
Artifacts:
verbose: true
Tainted: False
Filesize: 28.7KB
Number pixels: 568KB
Pixels per second: 0b
User time: 0.010u
Elapsed time: 0:01.000
Version: ImageMagick 6.6.0-4 2010-11-16 Q16 http://www.imagemagick.org
identify: incorrect count for field "ColorMap" (768, expecting 6); tag trimmed. `filecomp.tiff' @ warning/tiff.c/TIFFWarnings/703.
identify: filecomp.tiff: Read error on strip 0; got 26911 bytes, expected 70992. `TIFFFillStrip' @ warning/tiff.c/TIFFErrors/493.
Fair enough. I tried to open it in Photoshop which to my great surprise actually worked - which meant that all the data was available but the format was corrupted.
Libtiff was helpful enough to provide me with a number: 70992 and 26911 - 70992 is located as a long at 0x7E in the TIFF header, but what about 26911? Replacing 70922 with 26911 fixed this one TIFF, but I needed to know how to calculate this number. This is where the utility called exiftool comes along.
# exiftool -g1 -D filecomp.tiff
---- ExifTool ----
- ExifTool Version Number : 8.15
---- System ----
- File Name : filecomp.tiff
- Directory : .
- File Size : 28 kB
- File Modification Date/Time : 2011:03:09 17:48:01+01:00
- File Permissions : rw-r--r--
---- File ----
- File Type : TIFF
- MIME Type : image/tiff
- Exif Byte Order : Big-endian (Motorola, MM)
---- IFD0 ----
255 Old Subfile Type : Full-resolution image
256 Image Width : 816
257 Image Height : 696
258 Bits Per Sample : 1
259 Compression : PackBits
262 Photometric Interpretation : WhiteIsZero
273 Strip Offsets : 1746
277 Samples Per Pixel : 1
278 Rows Per Strip : 696
279 Strip Byte Counts : 70992
282 X Resolution : 121.7910448
283 Y Resolution : 148.0851064
284 Planar Configuration : Chunky
296 Resolution Unit : inches
320 Color Map : (Binary data 1536 bytes, use -b option to extract)
---- Composite ----
- Image Size : 816x696
Some quick math: file_size - 26911 = 1746 (Strip Offsets). In reality I did check how libtiff calculates the error message's "expect" value and then verified it with exiftool, but you get the idea.
Result: 9350_fix_tiff.py
import struct
def fix_tiff (f):
f.seek (0, 2)
file_size = f.tell()
# Get 'Strip Offsets'
f.seek (0x5A)
real_size = file_size - struct.unpack ('>I', f.read (4))[0]
print 'Patching to', real_size
# Write 'Strip Byte Counts'
f.seek (0x7E)
f.write (struct.pack ('>I', real_size))
This script has evolved and now contains an SMTP function which sends the hardcopy as a color and B/W attachment (PNG format) to my email when I press "Screen dump". Pretty neat if I may say so myself.
Comments
Post a Comment