Handling large jpg image files and pdfs which contains jpeg encoded bitmaps is a great bottleneck for our underpowered systems.

I found that even showing a pdf page is depends largely on how can the code handle jpg images. Currently amipdf loads the whole image and puts the whole image to a bitmap even if you wanted to show it in a scale of 25%.

If we can find a solution to load and display only the needed part of an image or scale it extremely fast to a needed size then it would be a gain in severeal areas.

I found this opensource attempt to create thumbnails from jpg extremely fast.
I can't check it myself because there is no Amiga port and I don't bother other systems.

So please somebody make a port of this to check the value of the algorithm.
As I can see, it shouldn't be a tough job for an experienced porter.

Here is the archive:
https://github.com/mattes/epeg/archive/v0.9.1.042.zip

Or, do you have a better idea?

@Lazi

There's no point in porting the library if nothing uses it, though.
The real question is: can someone please improve AmiPDF (perhaps with epeg library)?

@Spirantho

Maybe it could be ported like a cli command to check it's performance.

Amipdf is just an example, it could be useable in other places too.

@Lazi

https://dl.dropboxusercontent.com/u/26599983/libepeg.7z

I haven't tested it since I don't have a usable Amiga system at the moment.

@salass00

Thanks!

It requires libjpeg.so.12
Renamed the libjpeg.so.9 to 12, so it can run. (I'm not sure it is OK)

8.Over4G:h/epeg/bin> epeg --width=10% --height=10% --quality=70
Usage: epeg [options] input.jpg thumb.jpg
-v, --verbose
-w, --width=[%] set thumbnail width [% of input]
-h, --height=[%] set thumbnail heigth [% of input]
-m, --max= reduce max(w,h) to maximum, with aspect preserved
-c, --comment= put a comment in thumbnail
-q, --quality= set thumbnail quality (1-100)
8.Over4G:h/epeg/bin> epeg --width=10% --height=10% --quality=70 kerekpar1.jpg thumb.jpg
epeg: cannot open kerekpar1.jpg


Here is what snoopy can see:

00001 : Shell Process : o.k. = GetVar("_pchar",0x67E78D18,32,0x00000200) [18uS]
00002 : Shell Process : o.k. = GetVar("_mchar",0x67E78D18,32,0x00000200) [2uS]
00003 : Shell Process : o.k. = GetVar("_pchar",0x67E78D18,32,0x00000200) [2uS]
00004 : Shell Process : o.k. = GetVar("_mchar",0x67E78D18,32,0x00000200) [1uS]
00005 : Shell Process : FAIL = FindSegment("epeg",0x00000000,USER) [17uS]
00006 : Shell Process : FAIL = FindSegment("epeg",0x00000000,SYSTEM) [2uS]
00007 : Shell Process : CurrentDir("")
00008 : Shell Process : o.k. = Lock("epeg",SHARED) [125uS]
00009 : Shell Process : o.k. = ExamineObject(0x67E78C88) [42uS]
00010 : ENV/env-handler 52.2 : FAIL = Lock("ENVARC:ELF.LazyBinding",SHARED) [43uS]
00011 : ENV/env-handler 52.2 : FAIL = Lock("ENVARC:ELF.LazyBinding",SHARED) [19uS]
00012 : ENV/env-handler 52.2 : FAIL = Lock("ENVARC:ELF.LazyBinding",SHARED) [22uS]
00013 : ENV/env-handler 52.2 : FAIL = Lock("ENVARC:ELF.LazyBinding",SHARED) [31uS]
00014 : ENV/env-handler 52.2 : FAIL = Lock("ENVARC:ELF.LazyBinding",SHARED) [21uS]
00015 : Shell Process : o.k. = LoadSeg("epeg") = [0x1A2B1825] [104985uS]
00016 : Shell Process : o.k. = Lock("epeg",SHARED) [16uS]
00017 : Shell Process : DIR = ParentDir("epeg") [7uS]
00018 : Shell Process : CurrentDir("")
00019 : epeg : o.k. = Open("CONSOLE:",OLD) = [0x19EE5E70] [138uS]
00020 : epeg : o.k. = IsInteractive("CONSOLE:")
00021 : epeg : 0 = FindSegmentStackSize("epeg") [67uS]
00022 : epeg : -----> RunCommand(0x1A2B1825 "epeg",,"--width=10% --height=10% --quality=70 ",62)
00023 : epeg : 0 = FindSegmentStackSize("epeg") [2uS]
00024 : epeg : o.k. = [exec] OpenLibrary("newlib.library",52) [10uS]
00025 : epeg : o.k. = IsInteractive("")
00026 : epeg : o.k. = IsInteractive("")
00027 : epeg : o.k. = IsInteractive("CONSOLE:")
00028 : epeg : o.k. = IsInteractive("CONSOLE:")
00029 : epeg : FAIL = GetVar("EXEC_IMPORT_LOCAL",0x67B76D18,8,0x00000200) [12uS]
00030 : epeg : o.k. = Lock("Over4G:h/epeg/bin",SHARED) [23uS]
00031 : epeg : CurrentDir("Over4G:h/epeg/bin")
00032 : epeg : o.k. = Open("kerekpar1.jpg",OLD) = [0x19EE5D90] [36uS]
00033 : epeg : o.k. = ExamineFH("kerekpar1.jpg") [12uS]
00034 : epeg : FAIL = IsInteractive("kerekpar1.jpg")
00035 : epeg : o.k. = IsFileSystem("") [11uS]
00036 : epeg : o.k. = ExamineFH("kerekpar1.jpg") [4uS]
00037 : epeg : DIR = ParentOfFH(0x19EE5D90) "kerekpar1.jpg" [8uS]
00038 : epeg : o.k. = ExamineFH("kerekpar1.jpg") [3uS]
00039 : epeg : CurrentDir("")
00040 : epeg :

@Lazi

Quote:

It requires libjpeg.so.12 Renamed the libjpeg.so.9 to 12, so it can run. (I'm not sure it is OK)

Different libjpeg versions aren't necessarily binary compatible so that may be why it doesn't work for you.

Use this .so file instead:
https://dl.dropboxusercontent.com/u/26599983/libjpeg.so.12.7z

@salass00

That .so is solved the problem. It works now, and it works really fast!

I took a 4960x3507 pixel sized image and scaled to 10% of the original size with epeg and with Roland Florac's Amithumbs 1.0 from OS4Depot.

Epeg time is measured with a tool from Aminet's time-ma.lha

Epeg: 0.36 sec
Amithumbs: 6 sec

Wow! This is what is needed for jpg scaling!

(That was an image what I extracted from a 1 page 1 image PDF file which is opens in AmiPDF in 9 seconds.)

Salass, you made the first step!

The next step maybe an amiga shared library. Anyone?

Last edited by Lazi on 10-Jun-2013 at 04:48 PM.

@Lazi
I just took a peek into that epeg source. The scaling function inside is super-trivial, and actually not optimized at all. And of course lacking features like smoothing or so. I cannot imagine how to do image-scaling LESS optimal so I wonder why Amithumbs appears to be so much slower.
When you did the comparism, did you disable smoothing for Amithumbs, to get a somewhat fair result?
Anyway, I don't think that this sourcecode is worth bothering, it does not contain any magic.

_________________
AmigaOS 4.1 FE (sam460ex Radeon 9200 / RadeonHD), MorphOS 3.8 (PowerMac G4 733MHz Radeon 9000), AROS (x86), A1200 (060 80MHz Indivision MK2), A500, A600, CDTV
Wings Remastered Development Diary

@Daytona675x

Quote:

did you disable smoothing for Amithumbs

No, because I can't see such an option.

This is from the epeg readme:

Quote:

It makes use of libjpeg features of being able to load an image by only decoding the DCT coefficients needed to reconstruct an image of the size desired. This gives a massive speedup. If you do not try and access the pixels in a format other than YUV (or GRAY8 if the source is grascale) then it also avoids colorspace conversions as well.

While I don't know what this all means, my spur tells me, this is the difference.

Can't fairly compare it, because it looks like other implementations takes the whole image (consumes a lot of memory) and after then scales it.

Tried eastern from os4depot too. It creates the thumbnail in about 3 seconds for the same image. Epeg made it to the same size in just 0.33 sec.

So I can't see your point.

@Lazi

Quote:

It makes use of libjpeg features of being able to load an image by only decoding the DCT coefficients needed to reconstruct an image of the size desired. This gives a massive speedup.

Definitely interesting! And as the license seems to be very permissive, perhaps the thumbnailing algorithm can soon find its way into Amiga apps as well?

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@Lazi
Well, this time I took a not-so-quick look And yes, I missed the key part

Okay, so this whole thing is a wrapper around jpeglib (load, save, encode, decode). Plus a little scaler (the one I looked at) and a command-line-interface.

The idea is to let jpeglib do the rough scaling with its scale_num / scale_denom attributes (essentially only decoding the blocks that will contribute to the scaled image, "rough" because only a limited range of up- and down-scaling factors are supported, namely 1/8, 2/8,..., 16/8, at least in current jpeglib, older version only supported 1/2, 1/4 and 1/8 it seems).
Afterwards that additional self-made scaler does the remaining fine-scaling.

For applications like thumbnail-creation this approach is very interesting, especially if size difference between original picture and thumbnail is large, which is usually the case.
So Amithumbs could really benefit from this.

For AmiPDF, I don't know. There are many factors that influence the performance here and it also largely depends on how AmiPDF handles JPGs internally.

The thing is: if the output-image is not significantly smaller than the original image then there is no significant performance gain. So if somebody just puts a screenshot or an already downscaled photo in your favorite PDF you won't gain anything unless you want to watch a 25% downscaled PDF-page. If that PDF contains high-res pictures targetted to printing, then you would probably gain a lot.

Anyway, regarding epeg itself:
it's pretty, hm, unspectacular. As being said: the interesting stuff is in the jpeglib and not in epeg, epeg is simply a small wrapper around jpeglib's features. And if you do a scaling to anything >50% then jpeglib won't do anything in that epeg-implementation here and you're left alone with epeg's bad own scaler (which is most likely slower than anything else if doing a fair comparism (which means no smoothing and such)).

So all in all I'd say:
if there's somebody involved with AmiPDF it may be very intersting to take a look at jpeglibs already existing scale feature. But better don't look at epeg, since you can do a better fine-scaler for sure

_________________
AmigaOS 4.1 FE (sam460ex Radeon 9200 / RadeonHD), MorphOS 3.8 (PowerMac G4 733MHz Radeon 9000), AROS (x86), A1200 (060 80MHz Indivision MK2), A500, A600, CDTV
Wings Remastered Development Diary

@Daytona675x

Thanks for the in depth look!

Quote:

The thing is: if the output-image is not significantly smaller than the original image then there is no significant performance gain.

So in the case of thumbnails it should give good performace. And in my opinion this is not the best experience on OS4. The picture viewers that lists thumbnails sweats a lot under the pressure of currently regular sized pictures.

The PDF viewer is certainly is an other case because the bitmap encoding is not always jpg, however I am working a lot with network scanned pdfs which contains large resolution jpg images which I want to display on the lower resolution screen. So in this case epeg/jpeglib would help.

Last edited by Lazi on 10-Jun-2013 at 10:13 PM.

@Lazi

I just rebuilt epeg with libjpeg.so.9 and uploaded it to OS4Depot:
http://os4depot.net/?function=showfile&file=development/library/graphics/libepeg.tar.bz2

Last edited by salass00 on 11-Jun-2013 at 01:31 PM.

Ive been confused, ever since JPEG came out, just why you need to generate a thumbnail, given teh DCT method pixelises the image. Each most significant, DC value in any give macroblock, is a straight summation of all the values in that macroblock. That is, a linear scaled thumbnail of 1/4, 1/8, 1/16.

Given the more information you have, the greater the compression ratio possible, I wonder if teh reason noone applies a second pass, or recursive to average over entire image, is that the resultant compression ratio isnt competative for the linear scaling processing time required?

Then again, Ive been trying for years to script a simple piece of code as a check. Take a square million pixel image, scan it with a fractal Hilbert line to convert the 2D array into a 1D array, then just do a single million point transform on it. Given high frequencies are mostly zero, and shouldnt there be an actual cut off, this should give rise to some very impressive compression, and most of the information in the first few hundred samples, the size of the thumbnail?

Think like IFF Chunk encoding, You have your meta data, you then have a sequence of chunks, the first contains the base DC data, the smallest thumbnail, the next chunk contains the data that expands to the next 400% pixels, the next chunk the next 400% etc. Theoretically, if the fractal method truely works, these subsequent chunks will just be scaled versions of the first chunk.

Lets pull the FFT routines out, so that when FFT hardware support is included, it can just call that instead?

After 30 years, it would be nice for a fundamental mathematical function to be supported as such.

Anyone up for including such in the MiniMig core?

_________________
The older and more respected a scientist is, the longer it takes to prove him wrong.

@salass00

I tried to make epeg resident. Here is what I got:


8.Workbench:> resident ?
NAME/K,FILE/M,REMOVE/S,ADD/S,REPLACE/S,PURE=FORCE/S,SYSTEM/S,QUIET/S: name epeg file c:epeg add
c:epeg: object is not of required type

8.Workbench:> resident name epeg file c:epeg add pure
RESIDENT: Resident command 'epeg' added.

8.Workbench:> epeg --max=150 Media:Photo/3/DCIM/113_PANA/P1130191.JPG ram:a.jpg
***Impure resident command 'epeg'!
epeg: Unknown command
epeg failed returncode 10

Is there some requirements to a command to be able to add resident?

@Lazi

Is the pure bit set? One requirment is that they be reentrent. That is the code can be restarted in memory as another process and not use self modifying code IIRC. In modern terms you could say it has to be thread safe.

But that is really up to the code. If it isn't really pure and you force it to be running another instance may crash if it trashes the variables.

@Lazi

Most programs will not be able to be made resident because the requirements for it are very strict. Basically the program needs to be re-entrant so you can't really use any writable global or static variables and you cannot use the standard C startup code either.

The reason that resident programs need to be re-entrant is because they are loaded into memory and relocated only once and then reused every time the program is run, meaning that there can be multiple instances of the program running using the same code and global data areas at any time.

@Hypex

Quote:

Is the pure bit set?

It's not and it shouldn't be.

Last edited by salass00 on 23-Jun-2013 at 05:38 PM.

@Daytona675x

the thing i am wondering about right now is the actual memory usage as i know other formats gobble up all the memory there is just to do "simple" stuff like this and then free it afterwards.

_________________
See my blog and collection website! . https://www.blog.amigaguru.com

@All

If you want to see some really fast picture scaling check out this thumbnailer then pester the author. when he released the first version and I compared it to photoalbum, it was more than 10 times faster... it's 68k code but it beats anything ppc I've tried. pity it's so awkward to use

http://aminet.net/package/gfx/show/PictureOverview

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

@Lazi

Quote:

Lazi wrote: Amipdf is just an example, it could be useable in other places too.

If the epeg example program could save as png it would made a very fast icon creator...

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.