A first for OS4?

[chris]

Unsatisfactory Software is proud to announce the first release of the WebP DataType for AmigaOS 4.

WebP is a new heavily compressed image format developed by Google. In a repeat of the launch of PNG, where Cloanto made AmigaOS one of the first operating systems to support the new format, Unsatisfactory Software has performed the same feat with WebP.

This new DataType will allow any OS4 system with DataTypes supporting software, to view WebP images. This includes older AmigaOS web browsers such as AWeb.

WebPConv can be used to convert existing images to the new format.

WebP DataType
WebPConv

More information about WebP can be found at http://code.google.com/speed/webp

[chris]

Great! Did you have some code already written? Or more precisely: How did you write a datatype so quickly. :-p

I have some old datatypes (based on the code of salass00) which need minimal alteration to create a new one, and the WebP library is very simple.  The hardest bit was building libvpx, but after a few failed attempts I realised MickJT had already ported it - so I just used the pre-built one.

Simples

[chris]

Quite clearly it was about the WebP in particular. Indeed it isn't a first.

Hence the question mark.

Of course, the routines are available for Linux, but beyond the example webpconv file converter, what can you actually do with WebP on Linux?  Does anything else support it?

With this datatype you can actually use WebP files under AmigaOS just like any other image file format, without the need to convert the files back to something else first in a manual process.

I've just written the code for NetSurf for WebP too, so at least one web browser will shortly be supporting it.  Whether WebP takes off... well, we'll see.  With Google behind it, it just might.

As for JPEG2000, there are some incredibly high quality NASA charts in JPEG2000 format, the lower quality ones are JPEG.  It may not have much of a foothold, but there are JPEG2000 images out there in the wild - unlike MNG/JNG.

It takes a long time for a new graphics format to gain a following, I was using PNG for years (on my website too) before the main browsers started supporting it properly, and got lamented for it.  Now everybody uses PNG.  You have to start somewhere.  I'd rather release this now and show that AmigaOS is still up-to-date, than wait five years for the forums to be full of "why can't I view this image, it's in WebP format?".

Besides, it was quick and easy to do, I've probably wasted more time explaining myself than actually writing code.

[chris]

thanks !

any chance you would do more datatypes like ogg ? we have mp3, flac and wave but no ogg datatype (I usually encode my CDs in ogg with ADripper).

You might want to direct that question towards Fredrik (salass00), he's more of a whizz on the audio datatypes than me (given that I've never written one).

[chris]

The day datatypes become bidirectional, I'll be a happy man

They already are, but hardly anything supports the save function, so it's rare for datatypes to implement it (this one doesn't, although I suspect it's about two lines of code so I can add it if you have a need for it?)

[chris]

By bidirectional I mean saving in the same format the datatype decodes, that is to say, every datatype subclass as a codec. Every time I've saved a datatype, I've got an IFF file.

Yes, that's what I was talking about.  The datatypes system is perfectly capable of doing this (although MultiView's support is a bit rubbish - I think it always writes in IFF, it should be asking), however most subclasses just forward DTM_WRITE to the superclass - ie. you end up with an IFF file.  There is a little program on Aminet which converts between formats using datatypes, but I can't find it at the moment.

Because there's next to no software which uses the function, the majority of datatypes don't implement it.

edit http://aminet.net/package/util/conv/DTConvert018
Doesn't support v43 picture datatype interface, although source is available so that could be fixed.

[chris]

Chicken v Egg ?

Yep.

[chris]

Reading through some example source and documentation it seems that writing images in indexed modes works through V42 datatype calls. Not sure if the feature is supported for RGB images as of V43, which may explain why it went un-developed since?

It must be supported for v43, as IFF saves work in 24/32-bit.

It's only a case of using PDTM_READPIXELARRAY to get the data and then writing it out to disk in the right format.

It would be a good start if MultiView allowed selection of the save format.