AK DataType vs. WarpDT

@ktadd

There was originally a prefs file for each datatype, I merged those into one prefs file, there is an editor, didn't realise it hadn't been released. Your not missing much if your only using them for saving, and most of the options are classic with gfx card related anyway.

@thread

I think it's a little unfair to characterise the ak-datatypes as mature software due to the age of the original project as nothing much was done with it since the early 2000s

There was no suport forsome version 44 features like DTST_MEMORY and even DTST_RAM was unsupported even though that is trivial to support for an image class.

Work that has been done on them includes, upgrading the underlying libpng libjpeg libtiff to the latest (at time of build versions). I'm never convinced by version chasing with thse libraries, the formats have been stable for many years so unless you explictly need a bug fix or API feature there is little gain, *but* those libs were very out of date so might as well use the latest version to replace them.

Some pngs would not work due to mistakes in the png decoding API usage those are fixed, one or two could make it crash, due to testing the wrong pointer for NULL befor using a different one! (which was NULL and crashed)

Tiff support was also fixed up a bit, 1 colour tiffs (often used for Faxes) now work for example.

The datatypes now use the datatypes.library provided file handles and do not reopen there own files, thus fixing DTST_MEMORY in a single hit, DTDT_RAM is supported.

So a lot of work has been done, use them if you like but Olivers WarpDT collection will almost certainly out do them when it comes to decding peformance. Perhaps those who like to play at benchmarking can verify that....

Working on them did reveal so errors and wrong assumption in other components when for example AK-GIF promotes a multipalette gif to 24bit to cope with the colour range anim.gadget stopped working right WRT alpha, as it assumed that there is always a bitplane mask, but this isn't the case for 32bit images and the actual alpha channel must be extracted. That measn that animgadget now supports true alpha on any multiimage format that supports it. (anyone want to write an APNG picture datatype?)

@broadblues

Good to hear much work has gone into improving the AK datatypes. The AK name is something of a double-edged sword really. In one sense, those datatypes were popular and well known in the 1990s (helped because there were no other alternatives for some years), but I'm sure people will remember the many updates that fixed some bug, only to break something else entirely. The basic coding bugs that you mention are precisely why some classed the old AK datatypes as unstable. They were never really mature in that sense. So, I guess it's 50/50 whether it would have been wiser to drop the name and rebrand them, particularly as it sounds like the new ones bear little resemblance to the original versions, in a good way.

I agree it was never wise to version chase libpng, libtiff, libjpeg, etc, as it's hard to pick a stable version sometimes, as those come with their own bugs too. However, in the last couple of years, development of libjpeg, libpng and zlib has stagnated. Particularly with libpng, some of those more recently involved have been making pointless changes, such as changing types, formatting comments, etc, which do not affect functionality at all.

In contrast to the old AK datatypes, I'd argue that the WarpDTs are far more muture, having of course been in constant development and refinement over the last 20+ years and are no less modern than the new AK datatypes. Not saying they are perfect, but I hope closer to perfection than they were at the beginning .

@Futaura

Just downloaded and installed the new update to your datatypes. Thanks for your continued support! I'm a satisfied customer, and I don't plan to replace your datatypes with anything else.

@Futaura
Yes, you have reason WarpDT Preferences is available with executable for AmigaOS4 and MorphOS, this fault failure mine was because I have installed only in my AmigaOS 3.9.

The lack of DTST_MEMORY support will surely break AmigaAMP's album cover display. This is such an old feature (introduced in V44) that today every datatype, especially if it's released for OS4, should support it.

@tomsoniq

Datatype classes do not need to specifically support DTST_MEMORY. Datatypes.library itself handles DTST_MEMORY, creating a pseudo file handler, so that classes still see a normal file handle. As far as classes are concerned, they're reading from a file, yet in the case of DTST_MEMORY, datatypes.library feeds the file handle with the memory buffer instead.

@Futaura
Hmm, alright but why do the akJFIF datatypes fail for DTST_MEMORY but work with DTST_FILE?

The following works fine with the original OS4 JPEG datatype:

MyDTObject = NewDTObject(NULL,
DTA_SourceType, DTST_MEMORY,
DTA_SourceAddress, MyMemoryPtr,
DTA_SourceSize, MyDataLen,
DTA_GroupID, GID_PICTURE,
PDTA_Remap, TRUE,
PDTA_Screen, MyScreen,
PDTA_DestMode, PMODE_V43,
OBP_Precision, PRECISION_GUI,
TAG_DONE);

...but fails as soon as the akDataTypes are installed.

If I then create a temporary file and write the data to it like

if((TempFile=fopen("T:TempImage", "w"))) {
fwrite(MyMemoryPtr, 1, MyDataLen, TempFile);
fclose(TempFile);
}

then I can open it with:

MyDTObject = NewDTObject("T:TempImage",
DTA_SourceType, DTST_FILE,
DTA_GroupID, GID_PICTURE,
PDTA_Remap, TRUE,
PDTA_Screen, MyScreen,
PDTA_DestMode, PMODE_V43,
OBP_Precision, PRECISION_GUI,
TAG_DONE);

although the akDataTypes are installed.

@tomsoniq

I'm not sure why DTST_MEMORY isn't working in your context, but I did explicitly fix this for the AK-Datatypes.

The *old* AK-Datatypes package did all reopen the file passed to them rather than using the passed file handle, and explicitly rejected anything but DTST_FILE, but this has now been fixed up and *should* be working.

I know that it working for AK-PNG as the gadgetry in the mediadeck.gadget is loaded via DTSTMEMORY and that *is* working...

Can you confirm which versions you are using?

Hmmph, just checking the code and I see that AK-JFIF has two very simlar functions for loading image data, one I fixed up the other still rejects anything but DTST_FILE and obviously the unfixed one is the one called most often (the fixed one handles grayscale)

Should be fixed in the 54.16 build

@broadblues
Great, thanks, glad to hear.
A fellow AmigaAMP user has got the current release (I think from the Enhancer Software v2.0) which is still broken.
I don't have that, so out of curiosity I simply installed a very old 68k package just to be able to reproduce what's happening.

@broadblues

You need more betatesters

Thank you for the quick fix

@ktadd
Ok, I see the enhancer 2.1 has updates to the AK Datatypes which has me poondering another question.

What happens if I have both sets of datatypes installed?
Say I have a Warp_bmp and a AK_bmp datatype installed. Which one will be used for displaying a .bmp file?

Note: I have been using the Warp Datatypes. (registered)

@ktadd

The one that will get used for reading is defined by which BMP descriptor you have installed in DEVS:Datatypes. "AddDatatypes LIST" will show you which are active.

@ktadd

It depends which descriptors you have installed.

If you have both JPEG and AKJFIF for example, the first on the list that matches will be used. That will likely depnd on the order they were stored in the directory.

I have a question

WarpDT or AK-Datatype use warp3d nova to go even faster?

Some good development work in the last few weeks on AK-Datatypes: AK-ILBM updated, Picture Datatype updated and Datatypes Library updated in their PPC (V54) and 68K (V46) versions.

We are upgrading these ready for the forthcoming Enhancer Software V2.3 and also the A600GS.

AK-ILBM Datatype V54.19 / V46.19
Datatypes Library V54.24 / V46.24
Picture Datatype V54.9 / V46.9

@mattew
And all still the same .. :)

I mean are you for real still don't see how vague is to post version numbers (which mean nothing) and “was updated” words, without actual providing of information what exactly were changes and updated ? Why ppls should be interested in those datatypes vs Oliver's one ? What good/new were done lately in AK ones so we should take attention on?

Not that recreating a wheel with datatypes is anyhow important and interesting, but still, even if somebody will find it interesting: how we should get what exactly were changed/updated ?

But that rhetorical, as probably you will say now that this all foundation, Hyperion is bad and so on without answering on actual question, right ?:)

ps. And even link to wiki is broken (you make a typo by missing "t" letter) in this post :(

@amigakit

Quote:

What relevant changes have been made to the PPC version?

@Maijestro
They "was updated" , that should be enough :) (sarcasm mode)