Skip to main content

image acquisition API

9 replies [Last post]
entzik
Offline
Joined: 2003-06-10

what would really make me happy is an image acquisition api, with a few default implementations like twain wrapper on windows & mac, a sane wrapper on linux and so on. It shall have a pluggable architecture so that third party providers and systems can write adaptors for their devices.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
entzik
Offline
Joined: 2003-06-10

I'll play the devil's advocate and ask: how is the swing printing API different from an image acquisition API? we're living a time when multimedia devices appear everywhere. More and more people I know have imaging devices (scanners, digital cameras) rather then printers. I'm not aware of world wide statistics but I think that's the trend. As these devices become more and more widespread, a development platform that aims to attract desktop application developers (that's one of java's ambitions, right?) must, in my opinion, have an API to address those devices, as there is a growing need of applications in this field. I mean, if imaging devices like scanners and digital cameras become as important to desktop application users as printers are, and the JDK already contains a printing API, why not have an image acquisition API in the JDK too?

Message was edited by: entzik

jackwind
Offline
Joined: 2003-06-12

> what would really make me happy is an image
> acquisition api, with a few default implementations
> like twain wrapper on windows & mac,

see JTwain http://asprise.com/product/jtwain/index.php

> a sane wrapper on linux and so on.

see JSane http://asprise.com/product/jsane/index.php

rabbe
Offline
Joined: 2003-06-14

I would like to see an image acquisition JSR created as well.

I would like the API to be able to scale from simple devices such as digital cameras to high speed production scanners that provide advanced image processing features such as barcode and patch code recognition and other image enhancement features.

The problem I see is that there really isn't good cross platform support for these devices. Perhaps there would be incentive to provide drivers if such an API were built into Java?

This would be great from a standards perspective. However it really needn't be a standard part of the JRE.

I'd like to see input from the TWAIN working group, Kofax, Captovation, Kodak, Pixel Translations and other leaders in this field.

mmotovsk
Offline
Joined: 2004-11-23

There is a Morena - Image Acquisition Framework for Java Platform available from www.gnome.sk. In version 6.2, it has common Api for Sane as well as for Twain interfaces. To acquire an image, few lines of code is enough:

//Select a twain driver
//MorenaSource source=TwainManager.selectSource(null);
//Or select a Sane driver
MorenaSource source=SaneConnection.connect("localhost").selectSource(null);
//From this point of code, it is independent if source is twain or sane:
Image image=Toolkit.getDefaultToolkit().createImage(source);

Martin Motovsky

swpalmer
Offline
Joined: 2003-06-10

That looks nice. I think this should be extended to improve support for video acquisition in JMF.
The multimedia APIs are in a really sorry state as it is. There should be better integration with java.nio. E.g. ImageIO should be able to read jpeg data stored in a ByteBuffer without going through many hoops. Java Sound should be able to play sounds from ByteBuffers including using ByteBuffers to stream data continuously for sound or JMF video playback.

sandtiger
Offline
Joined: 2004-03-04

Agreed. Perhaps a part of ImageIO? It seems like the API could naturally be extended so that instead of just reading from files and InputStreams, one could pass a reference to an image source like a camera or scanner.

johnreynolds
Offline
Joined: 2003-06-12

> Agreed. Perhaps a part of ImageIO? It seems like the
> API could naturally be extended so that instead of
> just reading from files and InputStreams, one could
> pass a reference to an image source like a camera or
> scanner.

I think this is a key requirement to get Java "out of the box". For Java to remain relevent in a world where software powered devices increasingly interact with the external (real) world, it is terribly important that we have standard ways of dealing with all forms of I/O: Audio, Visual, Pressure transducers, Temperature sensors, Scent sensors, etc.

zander
Offline
Joined: 2003-06-13

> I think this is a key requirement to get Java "out of
> the box". For Java to remain relevent in a world
> where software powered devices increasingly interact
> with the external (real) world, it is terribly
> important that we have standard ways of dealing with
> all forms of I/O: Audio, Visual, Pressure
> transducers, Temperature sensors, Scent sensors, etc.

With "out of the box" you mean without extra programming, or installed in the JDK base-install.

If you believe it should be in the base libraries; I have to ask why. The obvious problem this statement creates is that the codebase Sun has to maintain grows out of proportion compared to the limited resources one company can put in.

In other words; putting it in the JDK will most probably not lead to the API-standards you want in the long run.

I suggest to look for options to do this in another way; having applications like Sane ship a java-compatibility library seems like a better idea. An open source library building on top of that JNI interface to provide a good cross-platform API is a natural next step.

Naturally you could well have meant the same, in that case, consider this an written-out thought of the same idea :)

johnreynolds
Offline
Joined: 2003-06-12

> With "out of the box" you mean without extra
> programming, or installed in the JDK base-install.

I was being a bit more literal... meaning that Java could interact with the real world that lies beyond the borders of the "box" where Java executes.

I agree that APIs for interacting with the external world may not belong in the base JDK.