Which datatypes?

[Tarzin]

Hello!


I'm currently more using my Workbench 3.1.4 during theses confined times.
I was looking pictures (IFF, JPG, PNG) with visage/multiview and was thinking about which datatypes are the best to handle pictures?


Actually, original datatypes are installed but are there better ones?:
- Warp Datatypes (which are still developped)
- Ak Datatypes


My Amiga is configured with a 030 ACA card and 128Mo of Ram (no graphic card)



Thanks for your advices!

[AMIGASYSTEM]

More than better the two you mentioned are the most up to date ones

[nogginthenog]

Warp DT's are still supported.
https://www.warpdt.co.uk/

[Tarzin]

Thanks.
Are there comparisons speed between datatypes?

[indigolemon]

Originally Posted by Tarzin

Thanks.
Are there comparisons speed between datatypes?

Head to the WarpDT page, there are comparisons on the datatype pages showing Warp vs ak at least

[PeterK]

I would recommend the free JPEG datatype JFIFdt44 from Henryk Richter, which loads my background picture about 30% faster than the WarpDT when I disable the WinUAE Jit. Sorry, that was caused by the WarpDT feature "fancy upsampling", which is not available in JFIFdt44. Fancy Upsampling should be switched off.
http://aminet.net/package/util/dtype/JFIFdt44

And it's also an advantage to use the older picture.datatype 45.17 from OS 3.9 instead of the newer 46.13 of OS 3.1.4, because the scaling is better with the OS 3.9 version. If I remember it correctly, scaling also didn't work correctly with the new OS 3.1.4 IPrefs 45.16, but with the old 45.13 from OS 3.9 it's fine, but I didn't re-check that for long. In addition, the picture.datatype 45.17 has still PPC support built-in.

Also the free PNG datatype v44 from Gunther Nikl is quite good, but you will need a FPU for the 68020+ version, I think. Only the 68000 version works without it, if I remember it correctly.
http://aminet.net/package/util/dtype/PNGdt44

[DarrenHD]

Originally Posted by PeterK

I would recommend the free JPEG datatype JFIFdt44 from Henryk Richter, which loads my background picture about 30% faster than the WarpDT when I disable the WinUAE Jit.
http://aminet.net/package/util/dtype/JFIFdt44

And it's also an advantage to use the older picture.datatype 45.17 from OS 3.9 instead of the newer 46.13 of OS 3.1.4, because the scaling is better with the OS 3.9 version. If I remember it correctly, scaling also didn't work correctly with the new OS 3.1.4 IPrefs 45.16, but with the old 45.13 from OS 3.9 it's fine, but I didn't re-check that for long. In addition, the picture.datatype 45.17 has still PPC support built-in.

Also the free PNG datatype v44 from Gunther Nikl is quite good, but you will need a FPU for the 68020+ version, I think. Only the 68000 version works without it, if I remember it correctly.
http://aminet.net/package/util/dtype/PNGdt44

Do you happen to know why PPC support was removed in the OS 3.1.4 picture.datatype? Seems like a backwards step. Also, with Henryk's JFIF datatype I gather it's written in 68k asm so no PPC support?

Darren

[PeterK]

No, I don't know why the OS 3.1.4 picture.datatype has no PPC support built-in anymore and why the scaling quality is a little lower than with the OS 3.9 version or why the newer IPrefs doesn't scale my Jpeg wallpaper anymore. Maybe that will change again in OS 3.2, but only the developers can answer that.

The JFIFdt44 has probably no PPC support yet, and the PNGdt44 not either.

[gulliver]

We no longer support hybrid kernels. You can do that at your own risk.

IPrefs in 3.1.4 did not scale wallpapers (More details of its behavior are on the 3.1.4 FAQ on Aminet). For AmigaOS 3.2 IPrefs received some very interesting enhancements.

[Tarzin]

@indigolemon
Thanks, I have a look at comparisons. From point of view of the author, WarpDT seems to be good!

@PeterK,
Thanks for advice. I would like to stay with a rather standard Workbench and not merge many OS components

I'll try WarpDT for the moment ,thanks!

[indigolemon]

@Tarzin the author is on here, he's also the man behind the recent iBrowse updates among other things

[Tarzin]

@indigolemon,
Downloaded WarpDT yesterday on my A1200.
Will do some tries today and probably buy WarpDT -> I like the idea of supporting active developers ;-)

[Futaura]

Originally Posted by PeterK

I would recommend the free JPEG datatype JFIFdt44 from Henryk Richter, which loads my background picture about 30% faster than the WarpDT when I disable the WinUAE Jit.
http://aminet.net/package/util/dtype/JFIFdt44

On a 68080, sure - the AMMX IDCT will be a big boost.

However, be careful when comparing datatypes - for example, JFIFdt defaults to lower quality image output (faster), whereas WarpJPEG defaults to better quality output (slower). Both datatypes have settings to change these decoding parameters.

[PeterK]

Sorry, yes there was an important difference in the settings, it's your "fancy upsampling" which makes the loading slow, although I cannot see a difference in quality, but you have mentioned that already in your docs.

When I disable this "fancy upsampling", the better chroma decoding, then the WarpJPEG.datatype indeed seems to be even a bit faster than JFIFdtv44, which does not have that feature. But with Jit enable I could never see any difference in speed, both can load a 1920x1200 Jpeg image scaled down to 1280x720 by the OS 3.9 picture.datatype 45.17 in less than 1 s. So, I have to change my comment now.

[Futaura]

Check DCT method too - WarpJPEG defaults to slow integer, JFIFdt to fast integer. Historically, this default was chosen as it was better quality (well, the standard really - the IJG set this to the default for a reason) and did not make too much difference in speed on WarpOS compared to other datatypes. WarpJPEG doesn't have the float method as that has same quality as slow integer, but is slower on most, if not all Amiga hardware.

[PeterK]

Setting the WarpDT DTC method to fast integer makes no visible (countable in seconds) speed difference on my WinUAE system, but I have no benchmark or stop watch to measure that exactly.

I think the main problem is the localization (translation) of "fancy up-sampling" in your German version of the Warp datatypes. In your preferences it calls this feature "Genaue Farbwiedergabe ermöglichen" and no user who wants to get best results would ever risk to disable this pretty useless feature, because translated back to English language it would mean "make exact color rendering possible", but nothing like "fancy up-sampling". Maybe, you should change the translation to something like "langsame Pseudo-Farboptimierung" or "slow pseudo color optimization", so that everybody can understand that it costs more speed than it would improve the resulting quality.

[Tarzin]

WarpDT is needed/working under OS 3.1.4?
Installation tell me that I need at last OS 3.5

[Futaura]

Originally Posted by Tarzin

WarpDT is needed/working under OS 3.1.4?
Installation tell me that I need at last OS 3.5

It is needed to change prefs options, currently requiring the OS3.5+ resource.library, although this can also be done in a text editor.

However, wait a few days for the new version - this removes the resource.library requirement

[buggs]

TBH, the main reason for my rewrite of JFIFdt was JPEG decoding performance on Vampire cards. The available 68k CPUs have quite a hard time to decode JPEG files in a timeframe that users are willing to tolerate. That's why JFIFdt defaults to the fast integer iDCT. Also, the quality loss of the fast iDCT is documented as 4dB PSNR at high bitrates, which in turn translates to a standard deviation of a little more than 1 (out of 256 levels).

So this is what an example performance comparison will show on my development system (V1200 is about 10% slower than this). Up/Left: JFIFdt, Up/Right: WarpDT, lower right Visage internal JPEG decoder.


The image I was using for the test above is actually the only image available for download out of the advertisement comparison chart for WarpJPEG, which in turn is kind of a roadblock to an independent confirmation of those numbers.

As an example, I tried to have a look at the recent WarpJPEG improvements on my A4000 (Cyberstorm MK-I/060, Kick 3.1.4, P-IV, picture.datatype 45.17 from 3.9BB2) and did not achieve the results posted on the webpage using the method mentioned there (by a significant margin, see below). Reliable benchmarking on Amiga is not easy to accomplish. Long-standing users tend to install a variety of software packages (including patches) which will affect the runtime behaviour to a point where the one or other addition to the system can tip the scale.

Especially the choice of picture.datatype is known to make a huge difference. The picture.datatype from CGFX is supposed to be fast. Same can be said for the one from OS3.9 BoingBag2. Sadly, the latter one did not find it’s way into the latest OS updates.

So I would suggest to test different available software packages how they perform on the individual machine, in the local software configuration in order to find the best working solution.

In any case, this thread compelled me to have another look at JFIFdt. I’ve reduced some calling overhead to picture.datatype and the libJPEG, respectively. The 68k colour transform code path also got another polishing look. I’ll upload the update to Aminet during the weekend.

Phone picture (Please disregard the first result for WarpJPEG, I had to click the nag requester away):

Cybergrab:

[gulliver]

Originally Posted by buggs

Especially the choice of picture.datatype is known to make a huge difference. The picture.datatype from CGFX is supposed to be fast. Same can be said for the one from OS3.9 BoingBag2. Sadly, the latter one did not find it’s way into the latest OS updates.

Just to let you know that the picture.datatype from 3.1.4 is the same as the one from 3.9 but it is bugfixed and enhanced. It is also compiled to run on a 68000 (the 3.9 one, was compiled for 020+). So the difference in speed might probably be only attributed to the compilation options.