Re: SANE_FRAME Formats (was Re: xsane-0.31 available)

Steve Gunnell (steveg@ccis.adisys.com.au)
Wed, 04 Aug 1999 14:58:06 +0800

Grin. Oliver is very firm in his opinions which is fair enough as he is
doing the work. My judgement would be that SANE_FRAME_RAW
would only ever be used when a new backend is being tested and a
completely untouched data stream is needed for evaluation. Otherwise
why have data formats at all (as you point out)?

Perhaps the wrong conceptual model is being used here by using
names that poorly model the actual function. Try this model:

Data Source
V
Source Adapter
V
Translator == Control Source
V
Sink Adapter
V
Data Sink

Data Sources are Scanners, Digital Cameras, Network Links, and File Readers.

The Source Adapter translates logical commands from the Control
Source into physical commands sent to the Data Source. It also
passes status information back to the control source. The Source
Adapter also knows what data types the data source can deliver.
Currently mistakenly known as the Back-end.

The Data Sinks are image programs (like gimp), File Writers,
Printers, Network Links, and Faxes. Or even possibly things like
displays or engraving machines.

The Sink Adapter handles the logical to physical mapping for control
and data flow between the Control Source and the Data Sink. The
Sink adapter also knows which data types the Sink can accept.

The Control Source or Translator is where scanimage, xscanimage and
xsane live. It selects which source and sink adapters to use and breaks
out the various Source and Sink logical controls and statuses for the
benifit of the user. A Control source need not have any UI if it can
recieve its control input from the Sink Adapter (like saned). Currently
mistakenly called a Front-end but really a kind of Middle-end.

Now when a custom data stream needs to be handled the developer
hacks a Source Adapter and a Sink Adapter with a custom
SANE_FRAME_XXX and Oliver doesn't need a total rewrite of
xsane to handle it. Additionally if Oliver wants the IR channel to map
to Gimp Alpha and Nick wants it to map to Layer(IR) we just need
to have two sink adaptors available for GIMP_RGB_ALPHA and
GIMP_RGB_AUX_LAYER.

*shrug* ymmv

Steve Gunnell

Nick Lamb wrote:

> Am I fighting a losing battle here?
>
> Why is it so desirable to have
>
> This..... Instead of this...
>
> SANE_FRAME_RAW SANE_FRAME_G3
> SANE_FRAME_RAW SANE_FRAME_G4
> SANE_FRAME_RAW SANE_FRAME_JFIF
> SANE_FRAME_RAW SANE_FRAME_RGBI
> SANE_FRAME_RAW SANE_FRAME_TEXT
>
> How about...
>
> SANE_FRAME_RAW SANE_FRAME_RGB
> SANE_FRAME_RAW SANE_FRAME_GREY
> SANE_FRAME_RAW SANE_FRAME_BLUE
>
> Under what circumstances is it preferable NOT to know what kind of data
> we are dealing with? Are default: labels in switch blocks suddenly being
> taxed by the US government?
>
> Maybe I'm being REALLY REALLY STUPID here, but I can't see any down side
> to knowing what the **** was in the data stream before someone like
> Oliver decides to turn it into a JPEG and save it in a file.
>
> If you have some genuinely unexplained data, which can't be classified,
> what makes you think anyone wants to process it anyway?
>
> Nick.
>
> --
> Source code, list archive, and docs: http://www.mostang.com/sane/
> To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com