This is the sample file:
And this is how it's decoded:
At the moment, I don't see much point in using the TurboJPEG C API - as far as I can tell, the TurboJPEG C API for LibJpeg-Turbo is just a wrapper around the standard LibJpeg API, so it's unlikely to give any performance benefits - I expect that it's more likely to hinder performance slightly.
I haven't found a Delphi conversion for the TurboJPEG API and since I don't expect there to be any benefit from using it, I don't think it's worth the effort to do the conversion as the existing LibJpeg Pascal interface code that Zed linked to seems to work. Converting to TBitmap wasn't straight forward though with that API which is probably why I hadn't tried it previously - I'm thinking about modifying the existing library code to make it easy to convert to TBitmap since I've already done most of the work...
]]>I intend to make a small app to create/modify/view animated jpegs. Maybe even a dll to use in other app.
Why ajpgs and not apngs? Because highres highdetail apngs are very big so it loads slow and take a lot of RAM memory.
For example this one: https://drive.google.com/open?id=0ByKxA … mg5OGFjM0E
It was compressed with APNG Assembler so it has maximum compression. But it's still very big.
But most of the times the jpeg quality is enough.
For now I made a small project to test decoders/resizers/viewers: https://drive.google.com/open?id=0ByKxA … jFvYzNhNXc
It uses these frames: https://drive.google.com/open?id=0ByKxA … XZJVVBQcWs
And it builds this ajpeg file: https://drive.google.com/open?id=0ByKxA … nl2NW5oM00
Your decoder is very fast indeed, good job.
In my tests I got a 48.5 fps using on-the-fly decompression on 768x768 70 KB frames.
I intend to implement a decompression buffer and multithreading. Also a fast but good resize algorithm (for preview).
You said your component it's not thread-safe. Could you modify it to be?
I noticed that, when using the JpegDecode function on the same bitmap, I have to free the bitmap before each decoding. Is there a way to not free/create it every time? It may be faster this way...
Regarding resize: I would prefer a resize algorithm implemented BEFORE decompression. Jpegs are scaled much better than bmps, so why don't we use that?
Is it possible?
Thank you for your help.
Regards,
David
This kind may not be supported: it expects color JPEG.
]]>You have to find the op-codes of the asm commands. Then replace the asm by the op-codes.
Of course, this will work, but will be definitively not worth it IMHO.
This library was proof of concept, and has some limitations about progressive jpegs.
But you are perfectly right, with some search and replace, it may be possible to make it work with Delphi 5.
]]>I can confirm that jpegdec works well for 90% of the jpeg images. It would be very nice to add the SSE/SSE2 IDCT assembler code in NativeJpg, since some ppl stated that it is about 30% faster than the 8x8 IDCT version of the Independent Jpeg Group (IJG), which NativeJpg uses.
However, the Delphi debugger I use is very barebones, so the debugging of asm is really a pain (eg the Delphi7 debugger tells me that 02CH is 2, while I thought 2C hex is 2x16+12=44, for example). Therefore I cannot reliably extract *just* the IDCT part(s) of jpegdec. I have for now put this idea in the fridge.
If you have ideas on how to separate the IDCT code so the jpegdec IDCT can be just a drop-in replacement, please tell me.
Kind regards, Nils
]]>This library was a try of using SSE2 in order to speed up the decoding.
See http://synopse.info/forum/viewtopic.php?pid=425#p425
But on most benchmark, the default gdiplus library is as fast as this Fast Jpeg decoder.
So I'll let you use SynGdiPlus instead of this one.
The code of the Fast Jpeg decoder could be in all cases of some pedagogical interest, about asm and SSE2 use in a Delphi unit (especially the 16 bit alignment trick).
]]>