Source code of jpeg.library?

Does anyone have, or know where the source of jpeg.library can be found?

It is old and needs to be updated. I can't find the source anywhere, only the headers, and I don't want to waste time reinventing the wheel. The links in the readme are dead and I assume the emails are too, although I tried to send.

The source of jpeg.library should be open-source.

Why I ask is because the current version is based on ijg v6a. Current version is v9a and it is 10-50% faster. I also have an Altivec build at hand that is 200-300% faster!

@Deniil
Just keep in mind that libjpegv6 is not 100% compatible with the newer versions. You would end up risking breaking old applications if you just updated the library to v8 or v9.

What is not compatible, and which Amiga software would require those special features that are no longer available in v9?

Does jpeg.library (or datatypes) even export such functionality that is so obscure that libjpeg could just decide to drop them while still being able to call itself libjpeg?

I feel like such application would have compile in their own libjpeg instead of using the shared library...

@Deniil
This is not amiga related, libjpeg v6 is not 100% ABI compatible with V7 and up:
http://upstream.rosalinux.ru/versions/libjpeg.html

@Deniil

You could ask Darius Brewka who made the OS4 port: http://os4depot.net/index.php?functio ... library/misc/jpeg_lib.lha

IIRC the original author was not willing to make it open-source.

@BSzili

Some renamed and added symbols, fine
The code could be adapted to this in a few hours.

@thomas

Darius' website does not exist anymore and presumably not his email either then. The original author didn't want to make it open source a million years ago. That is void now (read: I don't care) if we get the source and he doesn't respond to an e-mail address he probably doesn't even have anymore.

@Deniil
ABI compatibility is not just about renamed or added symbols. Anyway, I didn't bring this up to bother you, you can easily verify my claim if you want. I
Darius Brewka had near-fatal accident around 2007. He is still alive and kicking, but not very active in the amiga scene. I think the last time I've heard of him when he wrote to the AROS ML 2-3 years ago. I can look up the mail address he used, maybe you can get a hold of him.

@Deniil


Please pay attention to what BZilli is saying an *do not* update jpeg.libray.

It's not just a few renamed symbols here and there the sizes of data structures are not the same. Code written for libjpeg6 *will* crash if linked against libjpeg 7 or greater.


If you want a post version 6 lib make a new library.

Or suppose if you're working on solely OS4 lib then you could make a new interface. New software would then open interface version 2.

@BSzili

I see. Hope he didn't suffer to much post-trauma.

I'd like to get hold of him. Maybe I could get the source to have something to build upon.

@broadblues

I would be very surprised (looking at the changes on that link) if the changes were so sever that it would be impossible to adapt to the current jpeg.library API. I mean, it doesn't expose too much detail about the internals of libjpeg. I mean, jpeg.library could theoretically house any implementation, not just libjpeg (or libjpeg-turbo, which is what I will put in there).

But I understand a simple recompile wouldn't work. It wouldn't even compile. Still, I'd rather much get the source to build upon then reinventing the wheel and not being able to use the new library anyway (because no apps would use it).

I mean, making a new library is meaningless for me, then I could just link towards libjpeg directly instead, if it was only a personal project. Much easier.

@broadblues

I have now read the jpeg API more closely, and the changelog for libjpeg from 6a to 9a. I see nothing that would make this incompadible in any way.

Sure 9a has some new switches that can increase lossless compression at the expense of total jpeg incompatibility etc. But that are special switches, not the default mode. The jpeg.library API have no access to these switches.

It's not that major. It's not totally incompatible at all, it just needs some tweaks, and there are new features, if one care to explore... I won't. But I really don't want to reimplement the library Total waste of time.

The big bonus here is libjpeg-turbo with full Altivec-acceleration! With a datatype built on this (WarpDT is already at 9a, just not the turbo version I assume) we could be flipping through digicam picture like a tablet

@Deniil,

Actually I took a look at the jpeg.library API just now and reliased that it doesn't, as I mistakenly thought, expose the original jpeglib API but an abstraction from it, so the changes will be hidden internally, so I retract my earler statement.

@broadblues
Same here. I thought jpeg.library exposed the libjpeg API, which would have made the switch from v6 to newer versions problematic.

That's why you use the library and not the lib

Anyway, I've started reinventing the wheel, if nothing else then for my own use. But a datatype would be more useful than the library.

@Deniil

Could you a add jpeg.library API on top of Fredrik Wikstrom's openjpeg.library (http://a500.org)?

@xenic

openjpeg has nothing to do with jpeg (in the 'traditional' sense of the format) it's for the different jpeg2000 format.

@xenic

Can't find any ref to openjpeg at a500.org. Do you mean the JpegTools? I already have the JpegTools compiled for Altivec.

Edit: Ok, found it. It's the Jpeg2000. Maybe... Jpeg2000 is incompatible with normal jpeg but perhaps I could link with both libs so it supports both :)

@Deniil

Quote:

For programs loading images I tend to agree. Though a datatype is less useful for saving, as you don't have much control over format options at present.

@Deniil

He means this:

http://www.a500.org/downloads/libraries/openjpeg_lib_lha.readme

@broadblues

Yes, and what's most important, is to bring the new speed to existing apps. Then we need to update the datatype.

@Deniil
Do you mean this datatype:
http://www.a500.org/downloads/datatypes/jpeg2000_dt_lha.readme