You are not logged in.
Pages: 1
Hi Arnaud, I'm testing your jpegdec unit, it's a very good work but it isn't compatible with multithreading...is there a way to adapt it ? I've also tried GDI+ to read my jpg, but its slower than your unit and GDI+ raise some "GDI+ Out Of Memory" errors randomly...I would be verry happy with a multithreaded version of your unit which I use with Graphics32, here is a ToBitmap32 function that you may add to your unit :
function TJpegDecode.ToBitmap32: TBitmap32;
var
BMI: TBitmapInfo;
begin
result := TBitmap32.Create;
ToBMI(BMI);
result.SetSize( abs( BMI.bmiHeader.biWidth ), abs( BMI.bmiHeader.biHeight ) );
CopyMemory( @Result.Bits[0], pRGB, result.width*result.height*(bitsPixel div 8));
end;
Thanks for your great work,
Regards,
Yann
Offline
I don't know why jpegdec is not compatible with multithreads...
In the code, there is no global variables, only memory allocated via VirtualAlloc, which is thread-safe AFAIK...
I confess I've no idea why it's not thread-safe...
What is your exact issue? Are you sure the error is inside jpegdec?
Offline
Yes Arnaud I'm sure...I use your unit to make thumbnails (in a background thread) and display them (in the main app thread). If I use your unit in the 2 threads it raises an access violation. If I use it only in one thread (to make thumbs OR to display them) it works flawlessly. Or if I call you unit from the background thread through Synchronize (which calls it from the main thread) it works again...but has obviously no interest.
The EAccessViolation message is "Access violation at address xxxxxxxxxx. Write of adress 00000001."
I think that your unit allocate memory from one thread which is not accessible from the other one...
Thanks again.
PS : your email address abouchez-AT-magic.fr shared on your website http://bouchez.info/ is no more available (error 550 from the smtp server). Not found another way to contact you (I'm french also !)
Offline
For the benefit of anyone wanting a thread safe version of JpegDec, I've made an updated version of the library available here:
The original code wasn't thread safe because it used a global variable to store a value - trying to use the code from multiple threads caused an exception. I've modified the assembler code to instead store the value on the stack.
Some performance statistics:
CPU: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz
Core Count: 4
Thread Count: 8
Iterations: 1000
Thread Count: 8
JpegDec:
Single Threaded Performance: 138 images per second
Multithreaded Performance: 439 images per second
Relative Performance: 318%
SynGdiPlus:
Single Threaded Performance: 117 images per second
Multithreaded Performance: 131 images per second
Relative Performance: 112%
Standard Delphi:
Single Threaded Performance: 26 images per second
Multithreaded Performance: 151 images per second
Relative Performance: 581%
Offline
Offline
No problem - sharing is all in the spirit of open source!
I've copied your zip file over to my web site as a backup and added a link back to your server in case there are any future updates.
Thanks for all your work in adapting this library for Delphi in the first place!
Offline
@MarkTG
Did you know about libjpeg-turbo? I think, that this is the fastest library to work with jpeg.
You can find Delphi wrapper and helper classes (feel free to optimize it!) here: https://bitbucket.org/sas_team/sas.plan … s/LibJpeg/
It would be great to see performance statistics for it
Last edited by zed (2017-01-15 06:36:54)
Offline
@zed
Thanks for the suggestion.
I haven't fully tested it yet, but in my initial testing, single threaded performance with LibJpeg is only a bit over half that of JpegDec - and that's without converting the end result to a TBitmap which would slow it down even further (There doesn't appear to be any included code to convert to TBitmap so I'll need to add some code to convert from Scanlines)
Even when multithreaded, JpegDec is still about 50% faster, and again, the difference will only get bigger once I add code to convert to a TBitmap!
Of course, YMMV on different hardware...
Offline
OK, it turns out that in my previous testing, I was only using the standard LibJpeg and not LibJpeg-Turbo.
With some optimizations of my own code, I've now got the following results:
Iterations: 1000
Thread Count: 8
CPU: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz
Core Count: 4
Thread Count: 8
LibJpeg-Turbo:
Single Threaded Performance: 205 images per second
Multithreaded Performance: 801 images per second
Relative Performance: 391%
JpegDec:
Single Threaded Performance: 166 images per second
Multithreaded Performance: 593 images per second
Relative Performance: 357%
SynGdiPlus:
Single Threaded Performance: 149 images per second
Multithreaded Performance: 147 images per second
Relative Performance: 99%
NativeJPG:
Single Threaded Performance: 22 images per second
Multithreaded Performance: 91 images per second
Relative Performance: 414%
Standard Delphi:
Single Threaded Performance: 26 images per second
Multithreaded Performance: 165 images per second
Relative Performance: 635%
If I disable the conversion to TBitmap, I get the following results:
Iterations: 4000
Thread Count: 8
CPU: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz
Core Count: 4
Thread Count: 8
LibJpeg:
Single Threaded Performance: 232 images per second
Multithreaded Performance: 1082 images per second
Relative Performance: 466%
JpegDec:
Single Threaded Performance: 179 images per second
Multithreaded Performance: 728 images per second
Relative Performance: 407%
I'm planning to update the files on my web site some time tomorrow.
Offline
Offline
I haven't done any recent testing on Jpeg Compression. I don't have a huge requirement for fast compression, so I wasn't thinking about doing testing for that, but it might make sense to do that as well.
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...
Offline
Pages: 1