Which datatypes?

[Tarzin]

Originally Posted by Futaura

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?

[buggs]

Originally Posted by gulliver

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.

[Futaura]

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:

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:

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]

Originally Posted by Tarzin

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.

[gulliver]

@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.

[AMIGASYSTEM]

Originally Posted by Tarzin

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

[Tarzin]

Originally Posted by gulliver

@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?)

[PeterK]

@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.

[AMIGASYSTEM]

Peter is Aminet's problem, there are other Archives that download files 0, like "zmakebas.lha", "IcarosLive_2_2_8.tar.bz2", "renderlib68k.lha"

[PeterK]

Ok, thanks AMIGASYSTEM,

I could successfully download it via anonymous FTP from main.aminet.net /util/dtype/JFIFdt44.lha, size is 818.444.

[AMIGASYSTEM]

Ok downloaded

[buggs]

Originally Posted by PeterK

@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.

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.

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.

[Tarzin]

Bought Warp Datatypes :-)
Waiting my key now.

My A1200/030 will be up to date! :-)

[Storm]

Originally Posted by Tarzin

Bought Warp Datatypes :-)
Waiting my key now.

Same here, just registered and now waiting.