DTM_WRITE feature requests

[chris]

I have been playing around with datatypes.library's DTM_WRITE method, and it seems to me to have two main flaws:

1. When calling DTM_WRITE (or via SaveDTObject) the only option is to save to a file on disk.
It would be useful to be able to save to a memory location, maybe one automatically allocated by datatypes.library (as the size of the resulting file will be unknown). This could be handled perhaps the same as reading from memory, where the subclasses believe they have a BPTR to an open file on disk.

2. There appears to be no way to determine whether a subclass supports DTM_WRITE in RAW format.
Something like GetDTMethods which can find out whether a DTObject supports this would be very useful (getting this information from ObtainDataType would be even more useful). At the moment the only way to find out appears to be to try it, and then look at the resulting file and see if it is in the expected format. Not very user-friendly!

The second is probably more important than the first, the lack of any way to find out if a subclass supports writing in their native format might explain why nobody ever uses it.

[ChrisH]

The second is probably more important than the first, the lack of any way to find out if a subclass supports writing in their native format might explain why nobody ever uses it.

As far as I was aware (having played around with saving via datatypes & discussing it on Utility Base), AmigaOS 3.x & 4.x only support saving in IFF. You cannot save as JPEG or anything else. I'm not even sure if there IS an official way to properly request saving in a non-IFF format, at least it didn't seem documented (kinda looked like they had the idea of supporting it, but never got around to implementing it - and that's what someone else claimed).

AROS on the other hand only supports saving as PNG (or something like that).

I found this a major annoyance, as Datatypes were supposed to get rid of the need for file format specific code, but if I want to save as say JPEG (as someone has requested I do for PictureAlbum's thumbnails, to reduce their size by 5-10 times) then I must interact with jpeg.library or similar.

[chris]

The second is probably more important than the first, the lack of any way to find out if a subclass supports writing in their native format might explain why nobody ever uses it.

As far as I was aware (having played around with saving via datatypes & discussing it on Utility Base), AmigaOS 3.x & 4.x only support saving in IFF. You cannot save as JPEG or anything else. I'm not even sure if there IS an official way to properly request saving in a non-IFF format, at least it didn't seem documented (kinda looked like they had the idea of supporting it, but never got around to implementing it - and that's what someone else claimed).

SaveDTObject (or DTM_WRITE method, which is the same thing) with mode DTWM_RAW.

Now, your DataType Object needs to be the correct subclass already before you save as DTWM_RAW, so if you have loaded using DataTypes, you are immediately locked to either saving in IFF (DTWM_IFF) or in the raw format you loaded from (DTWM_RAW). If you've created a new DataTypeObject of the correct subclass, however (the usual case if you are saving I'd have thought), DTWM_RAW will save in that format.... if the subclass supports DTM_WRITE. Some DataTypes pass DTM_WRITE to the superclass even if DTWM_RAW is requested. I'm guilty of this, because I didn't realise it was a bug until I started reading up on it, but only DTWM_IFF should be passed to the superclass.

A search of all Aminet readmes reveals a grand total of ONE datatype which supports DTM_WRITE in RAW format. (this one, if you're interested). As I say, there appears to be no way to check this programmatically (other than trying it, which is too late in the process for most uses, which will want to ask the format to save in before they start attempting saves).

There may be others which don't mention it in their readme. I'm going to add it to my WebP datatype when I get a few spare minutes, because it should be a doddle to add, and gives me a format I'm more familiar with for testing.

[chris]

And, to add to this, it looks like the DTA_BaseName tag of NewDTObject doesn't work, even when using the correct DTA_SourceType of DTST_RAM.

Calling ObtainDataType(DTST_RAM, "DataType Name") and then passing that to DTA_DataType works fine.


So, to write a file using DataTypes, you need something like the following steps:
* dt = ObtainDataType(DTST_RAM, "DataType Name")
* NewDTObjectA(DTA_SourceType, DTST_RAM, DTA_DataType, dt)
* Poke the data into the empty DataType object (using something like PDTM_WRITEPIXELARRAY for picture subclasses or God-knows-what for anything else)
* Pray that the DataType supports native writing and that the above steps haven't been a complete waste of time.
* SaveDTObject(DTWM_RAW) or equivalent DTM_WRITE
* Clean up


If writing in IFF format, you only need:
* NewDTObject(DTA_SourceType, DTST_RAM, DTA_GroupID, GID_WHATEVER)
* Poke the data into the empty DataType object
* SaveDTObject(DTWM_IFF)
* Clean up

[chris]

Grand total of DataTypes I have installed that will create a blank DataType object in memory and attempt a write:

FLIC
GIFANIM
WAVE
WebP

This was a "no data" test, so the save itself failed in all cases.

FLIC does not support DTM_WRITE
GIFANIM looks like it does, as I get a load of encoder errors output
WAVE I have no idea about
WebP supports writing fully, as I just added it.
RGFX I have installed, but it did not create the blank DataType object, so you can't use it for saving arbitrary data.

That is pathetic - I have 43 descriptors - I was expecting some of the OS included ones to support writing, but if they do it is only for data they have loaded themselves (of course the majority of the superclasses do in IFF format, which wasn't tested here).

However, if DTST_RAM is the sticking point, I have at least found a workaround for point 2 of my original message. It doesn't guarantee support of writing, but it reduces the list dramatically.

[salass00]

WAVE I have no idea about

My wave.datatype does support writing. I can't speak for the OS-included one though.

[chris]

WAVE I have no idea about

My wave.datatype does support writing. I can't speak for the OS-included one though.

It's probably yours I have installed I don't think there is one included with the OS, is there?

[ChrisH]

@chris
Thanks for your info on how to save using datatypes, as I couldn't work out how to specify the type of a new datatype object ... but your tests also seem to show this is fairly academic, due to lack of support

[afxgroup]

IIRC a lot of datatypes doesn't supports write

[Thematic]

I don't think there is one included with the OS, is there?

wav.datatype 53.5 (5.6.10)