English Amiga Board


Go Back   English Amiga Board > Support > support.Apps

 
 
Thread Tools
Old 22 April 2020, 07:47   #1
Tarzin
Registered User
Tarzin's Avatar
 
Join Date: Jul 2006
Location: Dunkerque / FRANCE
Posts: 125
Post Which datatypes?

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!

Last edited by Tarzin; 22 April 2020 at 08:42.
Tarzin is offline  
Old 22 April 2020, 08:37   #2
AMIGASYSTEM
Registered User
AMIGASYSTEM's Avatar
 
Join Date: Aug 2014
Location: Brindisi (Italy)
Posts: 5,801
More than better the two you mentioned are the most up to date ones
AMIGASYSTEM is offline  
Old 22 April 2020, 21:26   #3
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 946
Warp DT's are still supported.
https://www.warpdt.co.uk/
nogginthenog is offline  
Old 23 April 2020, 08:25   #4
Tarzin
Registered User
Tarzin's Avatar
 
Join Date: Jul 2006
Location: Dunkerque / FRANCE
Posts: 125
Thanks.
Are there comparisons speed between datatypes?
Tarzin is offline  
Old 24 April 2020, 14:39   #5
indigolemon
Bit Copying Bard

indigolemon's Avatar
 
Join Date: Jan 2017
Location: Kelty, Fife, Scotland
Age: 37
Posts: 871
Quote:
Originally Posted by Tarzin View Post
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
indigolemon is offline  
Old 24 April 2020, 16:49   #6
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,751
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

Last edited by PeterK; 29 April 2020 at 22:33.
PeterK is offline  
Old 24 April 2020, 17:36   #7
DarrenHD
Registered User
 
Join Date: Aug 2008
Location: London / Canada
Posts: 554
Quote:
Originally Posted by PeterK View Post
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
DarrenHD is offline  
Old 24 April 2020, 21:09   #8
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,751
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.
PeterK is offline  
Old 24 April 2020, 21:25   #9
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 42
Posts: 2,149
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.
gulliver is offline  
Old 25 April 2020, 07:26   #10
Tarzin
Registered User
Tarzin's Avatar
 
Join Date: Jul 2006
Location: Dunkerque / FRANCE
Posts: 125
@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!
Tarzin is offline  
Old 25 April 2020, 17:07   #11
indigolemon
Bit Copying Bard

indigolemon's Avatar
 
Join Date: Jan 2017
Location: Kelty, Fife, Scotland
Age: 37
Posts: 871
@Tarzin the author is on here, he's also the man behind the recent iBrowse updates among other things
indigolemon is offline  
Old 26 April 2020, 08:25   #12
Tarzin
Registered User
Tarzin's Avatar
 
Join Date: Jul 2006
Location: Dunkerque / FRANCE
Posts: 125
@indigolemon,
Downloaded WarpDT yesterday on my A1200.
Will do some tries today and probably buy WarpDT -> I like the idea of supporting active developers ;-)
Tarzin is offline  
Old 29 April 2020, 21:33   #13
Futaura
Registered User

Futaura's Avatar
 
Join Date: Aug 2018
Location: United Kingdom
Posts: 88
Quote:
Originally Posted by PeterK View Post
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.
Futaura is offline  
Old 29 April 2020, 22:27   #14
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,751
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.
PeterK is offline  
Old 29 April 2020, 22:46   #15
Futaura
Registered User

Futaura's Avatar
 
Join Date: Aug 2018
Location: United Kingdom
Posts: 88
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.
Futaura is offline  
Old 30 April 2020, 01:09   #16
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,751
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.
PeterK is offline  
Old 01 May 2020, 18:24   #17
Tarzin
Registered User
Tarzin's Avatar
 
Join Date: Jul 2006
Location: Dunkerque / FRANCE
Posts: 125
WarpDT is needed/working under OS 3.1.4?
Installation tell me that I need at last OS 3.5
Tarzin is offline  
Old 01 May 2020, 21:13   #18
Futaura
Registered User

Futaura's Avatar
 
Join Date: Aug 2018
Location: United Kingdom
Posts: 88
Quote:
Originally Posted by Tarzin View Post
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
Futaura is offline  
Old 01 May 2020, 22:35   #19
buggs
Registered User

 
Join Date: May 2016
Location: Rostock/Germany
Posts: 74
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:
buggs is offline  
Old 02 May 2020, 02:21   #20
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 42
Posts: 2,149
Quote:
Originally Posted by buggs View Post
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.
gulliver is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
AK-Datatypes In Development amigakit.com Amiga scene 9 19 May 2020 11:37
problem with datatypes honx support.Apps 23 13 September 2016 20:45
Datatypes.library 44.48 anyone? Amicol request.Other 3 26 August 2014 23:02
AFA OS and datatypes Rod_cl support.Apps 0 16 September 2006 01:39
Datatypes to replace fc.studio support.Apps 0 02 February 2006 14:37

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 12:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09560 seconds with 13 queries