This topic contains 4 replies, has 5 voices, and was last updated by PandeleFlorin 11 years, 11 months ago.
-
Posts
-
@spike wrote:
Can anybody share any experience with doing compressed memory transfers? Quirks, pitfalls, etc.? The TWAIN 1.9 spec is pretty terse on this subject.
Can anybody suggest an under 1000$US scanner that supports compressed memory transfers, for testing and development?
How do you tell which values of ICAP_COMPRESSION apply to files, and which to memory transfers? I imagine that you set ICAP_XFERMECH to TWSX_MEMORY, and then query ICAP_COMPRESSION. But does that really work in practice?
No real pitfalls, other than the fact that G4 is raw G4 data – ImageInfo is required to make any real use of the data after collecting it all, the only field of th TW_IMAGEMEMXFER structure that you can use is the BytesWritten – all others should be (-1)
JPEG is a different animal, the entire JPEG file is transferred in memory and can be written directly to a file with extension .jpg to be immediately useful.
Just loop until you get a TWRC_XFERDONE – there is no real way to figure out how much data you can expect or how many calls you need to make to ImageMemXfer, as each compressed image size depends on content.
I can’t direct you to a scanner within that price range, I can tell you that most scanners I have worked with that are sub 30 pages per minute tend not to support compression.
Compression is usually associated with speed and volume.
Jon Harju
@spike wrote:
Can anybody share any experience with doing compressed memory transfers? Quirks, pitfalls, etc.? The TWAIN 1.9 spec is pretty terse on this subject.
Can anybody suggest an under 1000$US scanner that supports compressed memory transfers, for testing and development?
How do you tell which values of ICAP_COMPRESSION apply to files, and which to memory transfers? I imagine that you set ICAP_XFERMECH to TWSX_MEMORY, and then query ICAP_COMPRESSION. But does that really work in practice?
The only thing I’d add is that many scanners that say they support compressed memory transfers, is that the compression is usually done in their DS – which tends to be poorly implemented. this translates to slow throughput. the better scanners, or high end, support on board compression.
regards,
wes@wes wrote:
The only thing I’d add is that many scanners that say they support compressed memory transfers, is that the compression is usually done in their DS – which tends to be poorly implemented. this translates to slow throughput. the better scanners, or high end, support on board compression.
regards,
wesRight, and be careful too if you use JPEG compression that some will use an old-jpeg 😕 format and some other the normal (new) jpeg/exif format no real standard capability in the spec to specify that.
👿
Can anyone say exactly in clean clear english:
1)How to get the total memory area PROPERLY ARRANGED , especially in “tiled” mode, FOR EACH KIND OF COMPRESSION?2)EXACTLY WHAT IS in that memory FOR EACH KIND OF COMPRESSION?
It’s a file, a hbitmap, a dib, FOR GOD’s sake WHAT is in there?3)The exact precise algorithm that decompresses the image, FOR EACH KIND OF COMPRESSION (not only jpeg)?