How to export images using datatypes?

[Karlos]

Hi all,

Does anybody have any example code of how to export picture data using datatypes in C/C++?

Specifically, what I want to accomplish is

1) Obtain a list of v43 capable image datatypes installed on the system and allow the user to select one.

2) Use the selected datatype to encode some RGB data into the chosen datatype format and write it as a file.

I know you can use the DTM_WRITE_PIXELARRAY method (or whatever it's called) to copy RGB data to a datatype object and DTM_WRITE to save it again. However DTM_WRITE seems to save iff all the time :-?

I've looked around for examples but most code seems only concerned with decoding datatypes. I have also seen tools that interconvert datatypes so I'm sure exporting must work, but how does one achieve it?

[Thomas]

AFAIK it is not possible to do this. The only two converters I found on Aminet which can convert *to* datatypes need a custom datatypes.library V45. There is no way to do it with V40 (OS3.1) or V44 (OS3.9).

If you find a way, I'd be very interrested in it.

Bye,
Thomas

[Karlos]

Bugger, that's kind of what I was starting to suspect :-( When I looked at dtconvert it mentioned something like this.

We need bidirectional datatypes as standard, decode only is simply not enough :-(

-edit-

I do remember reading datasheets for various image datatypes that support writing of their format.

If you could actually get an instance of one of these you might have a chance :-?

[blobrana]

Hum,
i remember a program called `Datachrome` (on a Amiga format disk)Amiga format list
That could `intercept` (but not destroy) "open file" system calls (datatypes) and convert them on the fly ...
(worked seamlessly in the background)

Could that be made to work?

[Karlos]

Hmmm.

To be honest, I think what is needed is a new set export datatypes. This would work in parallel with the existing system until a better overall replacement is written. You'd still have a similar heirarchy and methods.

The main difference is that you'd be able to have some base data in memory along with a description (for instance an image would have width, height, modulus, pixel format etc).

The information in the above example could be passed to a root exportpicture.datatype which in turn could be used to obtain a list of all the installed child types that can encode and export this data.

The data in the list would give you the name and various capabilities of each datatype.

Now, encoding is fundamentally more complex than decoding as far as parameters goes since knowledge of the format is needed. By obtaining the capabilities of a specific datatype you might be able to set some type specific properties. This isn't really ideal for a simple OOP type encoder strategy though.

However, you could simplify all this down to a set of options that can be represented as simple values in the parent interface. We might have, for the exportpicture.datatype generic export properties such as

resolution (DPI perhaps)
compression 0...100
quality 0...100
maximum colours 2...2^32 (or whatever)

It would be up to the specific exporting datatype to interpret these. Some may ignore them all together. There'd probably be a few more properties than those above. The point is, the programmer is sheilded from some unwanted complexities.