| Author |
 Topic  |
|
|
ZubastiK
Ukraine
9 Posts |
 Posted - Jul 03 2013 : 02:34:09
|
Hi guys,
I tried your old versions of ImageEn and found that this library is really great for my needs.
But I have one problem. I plan to write simple photo editor and consider using image adjustments via TImageenProc. You know that you can dynamically adjust Brightness, Contrast, Saturation, Tint, Temperature and other parameters with track bars in software like Lightroom or Aperture on Mac. But is it possible to do with ImageEn? I tried for example such code:
procedure TSingleFrame.RenderImage;
begin
SingleView.LockUpdate;
SingleView.Proc.AdjustBrightnessContrastSaturation(20,20,0);
SingleView.Proc.GammaCorrect(2, [iecRed,iecGreen,iecBlue]);
SingleView.Proc.IntensityRGBAll(20,20,20);
SingleView.Proc.Sharpen(12);
SingleView.Proc.AdjustLumSatHistogram(0.8,0.5);
SingleView.Proc.AdjustTemperature(3200);
SingleView.Proc.AdjustTint(45);
SingleView.UnLockUpdate;
end;
It's working extremely slow when you put such one on track bar OnChange event, especially on large images. Is it possible to speed up or optimize it in such situation?
I hope to get solution, because only your library possibly can work with my needs and I'm considering to buy it.
Roman |
|
|
xequte
39076 Posts |
Posted - Jul 03 2013 : 03:53:23
|
Hi Roman
Firstly, don't update it directly in OnTrackChange call a TTimer as follows:
tmrUpdateView.Enabled := False;
tmrUpdateView.Enabled := True;
Then in the OnTimer event update the view (perhaps with an interval of 500ms).
This way changing the controls would not be slowed down.
If you need it to be faster then don't operate on the full image but a
reduced one for display only.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
 |
|
|
w2m
USA
1990 Posts |
Posted - Jul 03 2013 : 05:49:36
|
The best way to handle time consuming image processing is to run the processing in a secondary thread. My EBook has a new demo that shows how to handle image processing in a thread. The thread prevents "Application not responding" and the processing can be canceled by the user at any time. Development and testing of the thread took several weeks of effort it is not available for free. If you are a registered user of my EBook I can send you the new demo upon request. If you are not registered, order my book and, I'll send you the Image Processing in a Thread demo in the email.
Unfortunately some other demos include new ImageEn procedures that have not been released yet so the EBook itself will not be updated until the next release of ImageEn.
William Miller
Adirondack Software & Graphics
Email: w2m@frontiernet.net
EBook: http://www.imageen.com/ebook/
Apprehend: http://www.frontiernet.net/~w2m/index.html |
|
|
|
ZubastiK
Ukraine
9 Posts |
Posted - Jul 03 2013 : 11:56:51
|
| Thank you for responds! But if I use secondary thread it won't increase performance. I'm thinking is it possible to use several cores or apply this in conveyor style (add image processing task to buffer and apply all together). Someway Lightroom developers managed such high performance. So it's the question how did they... |
|
|
|
Uwe
284 Posts |
Posted - Jul 03 2013 : 13:04:40
|
quote:
Someway Lightroom developers managed such high performance. So it's the question how did they
What Nigel said: don't display the original image, but a smaller version of it to reflect the changes you've made. That's how it's done in Lightroom and Photoshop.
-Uwe |
|
|
|
w2m
USA
1990 Posts |
Posted - Jul 03 2013 : 13:36:40
|
While processing a smaller image will reduce processing time, I suspect that a thread will still be required to prevent a non- responsive GUI unless the images are quite small because you are doing a lot of different processing each with its own time demands.
In my testing here, the delay in processing is not very noticeable with threads because the GUI remains active. A thread for each image processing type using the trackbar approach with one imageenproc per thread is quite fast.
A combination of both approaches would be very speedy.
William Miller |
|
|
|
ZubastiK
Ukraine
9 Posts |
Posted - Jul 04 2013 : 00:27:38
|
Well, I've made such temporary solution. It can be optimized using Begin/EndProcessing in Proc, but still it's increases performance up to 3x - 4x times. Here it is:
procedure TSingleFrame.RenderImage;
var Proc:TImageenProc;
begin
Proc:=TImageenproc.CreateFromBitmap(SingleView.BackBuffer);
Proc.AdjustBrightnessContrastSaturation(20,20,0);
Proc.GammaCorrect(2, [iecRed,iecGreen,iecBlue]);
Proc.IntensityRGBAll(20,20,20);
Proc.Sharpen(12);
Proc.AdjustLumSatHistogram(0.8,0.5);
Proc.AdjustTemperature(3200);
Proc.AdjustTint(45);
Proc.Free;
end;
This procedure I put in OnDrawBackBuffer event.
I have another question, not about this topic. How do I get custom scrollbars to ImagesMView or ImageView? For example I want to use DynamicSkinForm and standard windows scrollbars aren't acceptable. Have anybody try DynamicSkinForm and ImageEn in one application? |
|
|
|
xequte
39076 Posts |
Posted - Jul 04 2013 : 02:50:33
|
Hi
There is no functionality for customizing the scrollbars in ImageEn. Though there is a FlatScrollbars option.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
|
|
|
w2m
USA
1990 Posts |
|
|
ZubastiK
Ukraine
9 Posts |
Posted - Jul 04 2013 : 06:38:21
|
| BackBuffer - it's image that is paint on component ImageenView, so it's lot smaller than original image that you loads, because of this it's so quick. |
|
|
|
w2m
USA
1990 Posts |
Posted - Jul 04 2013 : 06:43:56
|
Thanks, But if it is smaller how is the image quality maintained?
William Miller |
|
|
|
Prg
7 Posts |
Posted - Jul 04 2013 : 06:45:54
|
For faster image processing you need set
Proc.AutoUndo := False;
When you call
Proc:=TImageenproc.CreateFromBitmap(SingleView.BackBuffer);
AutoUndo sets to False by default (look source).
Thats all.
|
|
|
|
w2m
USA
1990 Posts |
Posted - Jul 04 2013 : 07:21:14
|
In my tests with threaded backbuffer processing with all the procedures shown only takes 480 ms. measured by a high-resolution performance counter regardless of the dimensions of the original image. The processed image in the backbuffer bitmap is always 551 x 612 pixels regardless of the dimensions of the original image.
iImageEnProc.AutoImageEnhance3();
iImageEnProc.AdjustBrightnessContrastSaturation(20, 20, 0);
iImageEnProc.GammaCorrect(2, [iecRed, iecGreen, iecBlue]);
iImageEnProc.IntensityRGBAll(20, 20, 20);
iImageEnProc.Sharpen(12);
iImageEnProc.AdjustLumSatHistogram(0.8, 0.5);
iImageEnProc.AdjustTemperature(3200);
iImageEnProc.AdjustTint(45);
William Miller
Adirondack Software & Graphics
Email: w2m@frontiernet.net
EBook: http://www.imageen.com/ebook/
Apprehend: http://www.frontiernet.net/~w2m/index.html |
|
|
|
Prg
7 Posts |
Posted - Jul 04 2013 : 07:59:27
|
| BackBuffer is like ClientRect have size of current ImageEn control |
|
|
|
w2m
USA
1990 Posts |
Posted - Jul 04 2013 : 08:36:45
|
Understood about ClientRect.
Because the processed image is usually much smaller than the original image the processing must be run again on the original image before the file is saved.
When are you processing the original image? If you process the original image just before a save it still will take significant time.
William Miller |
|
|
|
Uwe
284 Posts |
Posted - Jul 04 2013 : 13:21:15
|
William,
quote:
When are you processing the original image?
Have you worked with Photoshop before? If you open a camera RAW file for example, ACR (Adobe Camera Raw) will be started automatically. You make your corrections (white balance, temperature, contrast, saturation and so on) on a small copy of the original image, and when you're done you click 'OK'. The moment you do that, your changes are applied to the in-memory copy of the original image. Depending on the size of the file that can take quite some time, although I believe that some calculations are done in the background already before you close ACR.
-Uwe |
|
|
|
w2m
USA
1990 Posts |
Posted - Jul 04 2013 : 13:35:25
|
No.. I have never used Photoshop... but thanks.
William Miller |
|
|
|
klausdoege
Germany
389 Posts |
Posted - Jul 09 2013 : 04:24:29
|
Hello,
I have the example: ThreadingTheImageEnWay tested.
The Procedure TProcessingThread.Execute; is not faster,
as if I realize it with following Procedur conventionally.
It is therefore no solution for a faster Process.
procedure TForm1.Button1Click(Sender: TObject);
begin
zeit:=now;
ImageEnView1.Proc.AutoUndo := False;
ImageEnView1.Proc.UndoLimit := 5;
ImageEnView1.Proc.AutoImageEnhance3;
ImageEnView1.Proc.SaveUndoCaptioned (' car image Enhance Filter');
ImageEnView1.Proc.AdjustGainOffset;
ImageEnView1.Proc.SaveUndoCaptioned (' Filterx');
ImageEnView1.Proc.AutoSharp;
ImageEnView1.Proc.SaveUndoCaptioned (' Filterxx');
ImageEnView1.Proc.HistAutoEqualize;
ImageEnView1.Proc.SaveUndoCaptioned (' Filterxxx');
ImageEnView1.Update;
zeit1:=now;
label1.Caption:=timetostr(zeit1-zeit);
end;
Klaus
www.klausdoege.de |
|
|
|
w2m
USA
1990 Posts |
Posted - Jul 09 2013 : 05:50:38
|
What makes you think a thread makes any process faster? All the thread does is prevent "Application not responding" and allows the user to maintain an active GUI... otherwise when you run your procedures the GUI does not respond until the last procedure you call is finished.
With your RenderImgage method, you mouse does not respond to clicks and the window can not be resized. The threaded processing allows both to proceed when the thread is running.
So you are correct, a thread does not speed up the actual processing.... only improvements to the actual processing code in imageenproc can do that.
When I was referring to faster processing I was discussing
Proc:=TImageenproc.CreateFromBitmap(SingleView.BackBuffer);
This Proc is faster not because of the thread, but because the image being processed is smaller than the original image. The backbuffer image is the size of the client area of imageenview, and is a lot smaller than the original image.
William Miller
Adirondack Software & Graphics
Email: w2m@frontiernet.net
EBook: http://www.imageen.com/ebook/
Apprehend: http://www.frontiernet.net/~w2m/index.html |
|
|
|
klausdoege
Germany
389 Posts |
Posted - Jul 10 2013 : 03:48:06
|
Hello William,
thank you for the info.
I have thought obviously incorrectly there.
I had hoped, that to make procedure somehow more quickly.
Klaus
www.klausdoege.de |
|
|
|
w2m
USA
1990 Posts |
Posted - Jul 10 2013 : 06:53:54
|
You can increase the speed of the processing if you use a smaller copy of the image. The smaller the copy the faster the processing will be. This would show a preview of the changes as they are made. If the changes are satisfactory after the preview then you have to run the procedures on the full image of course. If you run the procedures in a thread, then the GUI will remain active so it will not cause your users to think the system is not responding.
I made you a quick demo which I will email.
William Miller
Adirondack Software & Graphics
Email: w2m@frontiernet.net
EBook: http://www.imageen.com/ebook/
Apprehend: http://www.frontiernet.net/~w2m/index.html |
|
|
| |
Topic |
|
Search
Real-time adjustments in ImageEnProc
