English Amiga Board


Go Back   English Amiga Board > Support > support.Apps

 
 
Thread Tools
Old 02 May 2020, 07:13   #21
Tarzin
Registered User
Tarzin's Avatar
 
Join Date: Jul 2006
Location: Dunkerque / FRANCE
Posts: 128
Quote:
Originally Posted by Futaura View Post
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

Thanks, I'll wait and try again.


By the way, which software to use to display pictures?

I've tried Visage with tooltype Datatype enabled and I get a black screen. Is there another software recommanded?


@Gulliver,
Which the last official version of picture.datatype from OS 3.1.4?
Tarzin is offline  
Old 02 May 2020, 14:30   #22
buggs
Registered User

 
Join Date: May 2016
Location: Rostock/Germany
Posts: 107
Quote:
Originally Posted by gulliver View Post
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.
Thank you Gulliver. I appreciate the information, which is quite interesting and sad at the same time.

I did a little experiment to put my observations into perspective (and numbers) by compiling JFIFdt in dummy mode. It’ll perform all datatype duties (including feeding picture.datatype with meaningless pixel data) but just don’t call the JPEG decoder.

This is what I get with picture.datatype 45.17:


Same test, same machine just with picture.datatype 46.13:


So what we see from this experiment is that picdt 46.13 easily takes up twice as much time for it’s own pleasure and this is only the creation of the datatype object. When a client is going to fetch the decoded data from the picture.datatype, the performance penalty will strike again.

From my point of view, the design of the picture.datatype is inefficient enough as it is: in terms of memory consumption and the runtime overhead caused by copying memory around (several times). I don’t see much point in making this even slower than necessary.

Last edited by buggs; 02 May 2020 at 14:32. Reason: typo
buggs is offline  
Old 02 May 2020, 16:01   #23
Futaura
Registered User

Futaura's Avatar
 
Join Date: Aug 2018
Location: United Kingdom
Posts: 111
I agree that the OS supplied picture.datatype has never been brilliant in speed terms. My understanding is that for OS 3.1.x, picture.datatype v46 had to be rewritten to include all the v43/v44/v45 features due to the v45 source not being available. Perhaps this involved backporting from the picture.datatype from OS4. Even v45.17 is slower than it could be. Certainly the CGX v43 picture.datatype is by far the fastest, at least on >= 15-bit displays. I know the CGX v43 datatype doesn't have the dithering stuff and scaling that v44+ does have, and probably corners can be cut in the CGX datatype not having to worry about native graphics.

Regarding slow vs fast IDCT, the IJG jpeglib documentation says:

Quote:
The IFAST method is considerably less accurate than the other two; its use is not recommended if high quality is a concern.
And the full quote from libjpeg-turbo reads, referenced in a previous comment:

Quote:
If the JPEG image was compressed using a qualitylevel of 85 or below, then there should be little or no perceptible difference between the two algorithms. When decompressing images that were compressed using quality levels above 85, however, the difference between JDCT_IFAST and JDCT_ISLOW becomes more pronounced. With images compressed using quality=97, for instance, JDCT_IFAST incurs generally about a 4-6 dB loss (in PSNR) relative to JDCT_ISLOW, but this can be larger for some images. If you can avoid it, do not use JDCT_IFAST when decompressing images that were compressed using quality levels above 97. The algorithm often degenerates for such images and can actually produce a more lossy output image than if the JPEG image had been compressed using lower quality levels.
I don't agree with some of libjpeg-turbo's claims in general, but what I found from experience is that it is possible to see differences between images decoded with the slow or fast method, sometimes in a relatively major way. Whether this matters to anybody or not is up to them, of course, hence why it is configurable as an option. It is perhaps more obvious with lower resolution images or displays. Personally, I prefer not to sacrifice quality over a small increase in speed.

As with AltiVec, it is no surprise that AMMX optimisation brings a large speed boost to JPEG, and great work with that! Obviously, that is going to be faster than WarpJPEG can manage with no AMMX.

Regarding my benchmarks, all the A1200 ones are performed using the CGX picture.datatype, otherwise that would not make the MorphOS figures comparable to WarpOS, and subsequently WarpOS and 68k. As stated, they use the default settings which is the slow accurate DCT method - I can't be sure if some of the others (the ones that cannot be configured) use the fast or slow method, so it is more fair for WarpJPEG to use slow in the benchmarks (especially as slow is the jpeglib default, so other datatypes are more likely to be using that). There is no point trying to compare your benchmarks with the fast idct and mine with the slow idct - they are obviously going to be completely different.
Futaura is offline  
Old 02 May 2020, 16:04   #24
Futaura
Registered User

Futaura's Avatar
 
Join Date: Aug 2018
Location: United Kingdom
Posts: 111
Quote:
Originally Posted by Tarzin View Post
Thanks, I'll wait and try again.


By the way, which software to use to display pictures?

I've tried Visage with tooltype Datatype enabled and I get a black screen. Is there another software recommanded?
I personally have always preferred MysticView, but it is quite old - maybe there is something better our there now.
Futaura is offline  
Old 02 May 2020, 17:45   #25
gulliver
BoingBagged

gulliver's Avatar
 
Join Date: Aug 2007
Location: The South of nowhere
Age: 43
Posts: 2,322
@Tarzin
The last official datatype for 3.1.4 was picture.datatype 46.13 (10.9.2018)

@Henryk @Futaura

Any of you is welcomed to join the AmigaOS development team, and improve on the situation. You can email me, or send me a PM and I can arrange that.
gulliver is offline  
Old 02 May 2020, 21:28   #26
AMIGASYSTEM
Registered User
AMIGASYSTEM's Avatar
 
Join Date: Aug 2014
Location: Brindisi (Italy)
Posts: 6,585
Quote:
Originally Posted by Tarzin View Post
Thanks, I'll wait and try again.


By the way, which software to use to display pictures?

I've tried Visage with tooltype Datatype enabled and I get a black screen. Is there another software recommanded?
There are Multiview, MysticView, LoView, PicShow, CyberShow and many older ones
AMIGASYSTEM is offline  
Old 03 May 2020, 08:28   #27
Tarzin
Registered User
Tarzin's Avatar
 
Join Date: Jul 2006
Location: Dunkerque / FRANCE
Posts: 128
Quote:
Originally Posted by gulliver View Post
@Tarzin
The last official datatype for 3.1.4 was picture.datatype 46.13 (10.9.2018)
that.
Thanks for information.


@Amigasystem,
Thanks, I'll try MysticView and PicShow in a first time (Cybershow and Loview need RTG?)
Tarzin is offline  
Old 04 May 2020, 12:37   #28
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,903
@buggs
Thanks for releasing an update of your JFIFdt44 at Aminet:
http://aminet.net/package/util/dtype/JFIFdt44

Unfortunately, I only get a zero byte file when I try to download the package with IE11 or Opera. You didn't put a virus into that archive again, did you? Maybe Aminet has deleted the contents?

Interesting to see that you've now added a new "FANCYRESAMPLE" option too. I think the main purpose of using lossy JPEG compression is the larger reduction of the file size and the high decoding speed, but unlike to PNG I would see best possible quality only as a minor goal.
PeterK is offline  
Old 04 May 2020, 12:51   #29
AMIGASYSTEM
Registered User
AMIGASYSTEM's Avatar
 
Join Date: Aug 2014
Location: Brindisi (Italy)
Posts: 6,585
Peter is Aminet's problem, there are other Archives that download files 0, like "zmakebas.lha", "IcarosLive_2_2_8.tar.bz2", "renderlib68k.lha"
AMIGASYSTEM is offline  
Old 04 May 2020, 13:01   #30
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,903
Ok, thanks AMIGASYSTEM,

I could successfully download it via anonymous FTP from main.aminet.net /util/dtype/JFIFdt44.lha, size is 818.444.
PeterK is offline  
Old 04 May 2020, 13:26   #31
AMIGASYSTEM
Registered User
AMIGASYSTEM's Avatar
 
Join Date: Aug 2014
Location: Brindisi (Italy)
Posts: 6,585
Ok downloaded
AMIGASYSTEM is offline  
Old 04 May 2020, 13:33   #32
buggs
Registered User

 
Join Date: May 2016
Location: Rostock/Germany
Posts: 107
Quote:
Originally Posted by PeterK View Post
@buggs
Unfortunately, I only get a zero byte file when I try to download the package with IE11 or Opera. You didn't put a virus into that archive again, did you? Maybe Aminet has deleted the contents?
I know from whom I got that Virus a couple of years back. Never accepted anything from him again. Since then, I'm in the habit of checking my Amigas on occasion.



Quote:

Interesting to see that you've now added a new "FANCYRESAMPLE" option too.
That option is a regular feature of jpeglib. I've just exposed it to anyone who might have patience and/or CPU time to spare.



Quote:
I think the main purpose of using lossy JPEG compression is the larger reduction of the file size and the high decoding speed, but unlike to PNG I would see best possible quality only as a minor goal.
I agree. JPEG in DCT mode is lossy in any case. It's just a (philosophical) question how much more loss is seen as acceptable on the client side. But anyway, there are ways to get efficient processing and improved accuracy at the same time. That's for the next update, though.
buggs is offline  
Old 15 August 2020, 07:56   #33
Tarzin
Registered User
Tarzin's Avatar
 
Join Date: Jul 2006
Location: Dunkerque / FRANCE
Posts: 128
Bought Warp Datatypes :-)
Waiting my key now.

My A1200/030 will be up to date! :-)
Tarzin is offline  
Old 22 September 2020, 11:20   #34
Storm
SYS64738

Storm's Avatar
 
Join Date: Oct 2014
Location: Australia
Age: 47
Posts: 79
Quote:
Originally Posted by Tarzin View Post
Bought Warp Datatypes :-)
Waiting my key now.
Same here, just registered and now waiting.
Storm 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 11:45.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.16781 seconds with 15 queries