struct Bitmap to file? - with DataTypes

FWIW, (on OS4) saving IFF/ILBM pictures via datatypes works fine, whatever the picture depth.

@Kas1e,
is the sample that I link here is OK for you ?

http://www.amigans.net/modules/xforum ... t_id=78899#forumpost78899

@zzd10h
yep , all is fine, will make a enhancement req today for those datatypes

Great,
Thank.

@zzd10h
Done with BZs for savers:

#8375 - bmp
#8376 - gif
#8377 - jpeg
#8378 - png
#8379 - tiff

I assume its only ones graphics datatypes which come with os4 by default and which need savers (right ?)

Thank you Kas1e to have open these enhancments requests.

By hoping for the future ;)

Quote:

well all could do with savers, but only the os ones can be updated as part of the os,

All this makes me think about a more general datatypes-related problem.

Let's suppose I write a FLAC Datatype (ie. a subclass of the Sound Datatype) in which I also implement the DTM_WRITE method. As FLAC encoding is a CPU-intensive task, performing the method will naturally take some time (in fact, several minutes on a Sam440). Is the datatypes system ready/designed for this? Will the user be informed about the progress of the task somehow, or will the datatype keep doing work silently, leaving the user puzzled about what's happening?

@trixie.

No idea, but nothing stops the Flac datatype from putting up an (optional) progress requester.

The calling application should at least set the application busy etc etc.

I can't see how it would be any different from using a libflac based saver.

If datatypes were to get subclass savers then they probably need class specific tags to set format specific options.

@broadblues

Quote:
Considering the fact that things like the actual text rendering (in the case of Text Datatype subclasses) or sound playback (in the case of Sound Datatype subclasses) are done at the superclass level, I'd recommend implementing the progress requester at the superclass level as well - for the sake of user interface consistency. If different datatypes implement each their own way of indicating progress (some will use Gadtools, some ReAction...), we end up in an unpredictable system that will only confuse the user.

@zzd10h

Just to make you know, one of BZ already assigned !

Good news.
Courage for the developper(s)

@all

If we assume that we have savers in datatypes, how can i load let's say png file, and save it in bmp file ?

I.e. what logic of program should be ? Open both datatypes, then open .png file and then SaveDTObject but not with DTWM_RAW but with what ?

Woaah there! How did I miss this discussion? (probably the irrelevant thread topic - Ed)

I've discussed this before:
http://forum.hyperion-entertainment.biz/viewtopic.php?f=14&t=195

You will see from that thread that I have identified quite a number of problems that go beyond merely supporting DTM_WRITE:
1. You can't DTM_WRITE to an in-memory location
2. There is no way of identifying if a DataType supports DTM_WRITE without trying it
3. If you want to convert between formats you have to create a blank DataType object in memory (DTST_RAM) using the destination subclass (a lot of DataTypes don't support this either).
4. The DTA_BaseName tag of NewDTObject doesn't work (this is a datatypes.library bug, unless I'm doing something wrong)

A DataType subclass needs to support creation of a new blank DataType object in memory (DTST_RAM) and DTM_WRITE in order to be able to convert from one format to another. The calling application also needs to know that DTM_WRITE is supported (which there isn't any way of doing AFAIK), otherwise you end up with unexpected IFF data where it has been passed to the superclass.

Quote:

It's in the thread link I posted in my previous post, but basically you have to open the PNG as normal, create a blank BMP DTObject and copy all the data over, then save the BMP. There's no "quick" way of doing it (but normally you'd be poking in-application data in, rather than directly converting from another DTObject, so it's not really a problem)

btw, my WebP DataType has DTM_WRITE support if anybody needs one for testing (it's the only picture datatype I know of that has DTM_WRITE support that actually works).

@Chris
Quote:

If you can provide simple test case which i can attach to BZ, then i can make a BZ for.

I'm pretty sure it's just:

Object *dto = NewDTObjectA(DTA_SourceType, DTST_RAM, DTA_BaseName, "ilbm");

Returns NULL rather than creating an object. Can't remember now, nobody seemed interested when I was complaining about DTM_WRITE two years ago.

Quote:

I expect that it's a typo but you missed the TAG_DONE!

Object *dto = NewDTObjectA(DTA_SourceType, DTST_RAM, DTA_BaseName, "ilbm",TAG_DONE);

@Chris

I don't know if there is still any problems with NewDTObject() and DTA_BaseName but I just made it possible to create empty objects with DTST_RAM using following datatype classes:
ilbm.datatype
png.datatype
bmp.datatype
jpeg.datatype

This was not possible before.

The code I used to test uses destdtn = ObtainDataTypeA(DTST_RAM, basename, NULL); and DTA_DataType tag so it's a bit different from your code.

If you send me some code using your method I can test and ensure that it also works correctly.

@broadblues

Quote:

To be really correct that needs to be:

Object *dto = NewDTObject(NULL, DTA_SourceType, DTST_RAM, DTA_BaseName, "ilbm",TAG_DONE);