On Sunday 16 March 2014 02:34:56 Ivanko B wrote:
What do you get with smaller 'width' and 'height' settings?
===
4999x2999 is processed instantly but +5000x3000(+1+1 to it) takes 10
minutes.
This changes the order of rotation-scaling. 4999x2999 first scales down so
This changes the order of rotation-scaling. 4999x2999 first scales down so the
later rotated image fits 4999x2999.
==
Just rechecked - it doesn't matter whether the source image is
5000x3000 (to be downscaled) or 1920x1080 (to be upscaled).
But the problem really applied to resizing to the same or a large
image from the 5000x3000 image only.
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases
With the newest GIT, upscaling to 5000x3000 is instant. 5000x3000 to
5001x3001 and to 5500x3300 are instant (1.5 sec) too. But 5000x3000
to 6000x4000 is improportionally slow (114 sec) as long as taking the
same memory (340..570 MB). There's seems to be a scalability problem.
On Friday 14 March 2014 21:04:36 Ivanko B wrote:
Which are best setting for this (and any) mode mode ? With the updated
MSEgui benchmark me have 640 sec on the default settings, see the
atachment.
As we know now the slow GM-rotatation with big images is caused by memory
shortage. bmk_gray
What do you get with smaller 'width' and 'height' settings?
===
4999x2999 is processed instantly but +5000x3000(+1+1 to it) takes 10 minutes.
--
Learn Graph Databases - Download FREE O'Reilly
On Sunday 02 March 2014 07:20:11 Martin Schreiber wrote:
Linux XRender supports rgb masks and should be faster. It is planned to add
gray scale masks which probably is supported by gdi+ but it is a big
change.
Gray scale mask branch has been merged to master (experimental).
Martin
It's also possible to follow the exact (in sources) way GM MOGRIFY
-ROTATE goes.
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that
Or maybe there has to be some initiation for Open MP to work properly.
BTW, me use the x86_64 version of Win7.
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get
# gm mogrify -resize 5000x3000 1920x1080 img = 1 sec
# gm mogrify -rotate 45 5000x3000 img = 1..2 sec
So the slow rotation problem seems to be in MSEgui.
--
Subversion Kills Productivity. Get off Subversion Make the
On Monday 03 March 2014 13:23:30 Ivanko B wrote:
# gm mogrify -resize 5000x3000 1920x1080 img = 1 sec
# gm mogrify -rotate 45 5000x3000 img = 1..2 sec
Are you sure with the 5000x3000 img? For me the gm tool with convert and
the MSEgui test program have same timing under same conditions. The
Trying GMTEST to GM's produced 5000x3000:
1 deg = OK.
45 deg = fails with AV.
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that
The AV stack is :
#0 10055247 :0 DestroyImage()
#1 1008D3B8 :0 RotateImage()
#2 0001 :0 ??()
#3 0005 :0 ??()
#4 0001 :0 ??()
#5 :0 ??()
--
Subversion Kills Productivity. Get off Subversion Make
GMTEST eats 470+ MB memory on the AV.
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version
May be it worths to look at the rotaton code used by GM.
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster
Am 03.03.2014 14:57, schrieb Ivanko B:
GMTEST eats 470+ MB memory on the AV.
I experience the same. How much memory does the gm-tool use for the same
task?
Martin
--
Subversion Kills Productivity. Get off Subversion
How much memory does the gm-tool for the same task?
==
114MB. And all 4 CPU cores.
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle-free
On Monday 03 March 2014 13:50:46 Martin Schreiber wrote:
On Monday 03 March 2014 13:23:30 Ivanko B wrote:
# gm mogrify -resize 5000x3000 1920x1080 img = 1 sec
# gm mogrify -rotate 45 5000x3000 img = 1..2 sec
Are you sure with the 5000x3000 img? For me the gm tool with convert
and the
No AV , but 130+seconds on 45deg. 570MB RAM is consumed as long as
free RAM is 1GB.
It seems that You'll have to grab a multicore CPU machine for futher
GM polishing :)
--
Subversion Kills Productivity. Get off Subversion
On Monday 03 March 2014 19:15:36 Ivanko B wrote:
No AV , but 130+seconds on 45deg. 570MB RAM is consumed as long as
free RAM is 1GB.
It seems that You'll have to grab a multicore CPU machine for futher
GM polishing :)
Please read the conversation on graphicsmagick-help.
Please read the conversation on graphicsmagick-help
How to do it w/o subscription ?
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get
MSEgui to RaspberryPi
=
To ARM CPUs.
The wonders of computing! ;-)
===
Or bugs of using openMP :) 4 cores are slower than 2 ones. But only
scaling is 3 times as faster.
Can you make tests on Linux too?
Unfortunately no - me'm unable to recover
On Sunday 02 March 2014 10:29:04 Ivanko B wrote:
MSEgui to RaspberryPi
=
To ARM CPUs.
IIRC Koenraad Lelong successfully used MSEgui on ARM:
http://article.gmane.org/gmane.comp.ide.mseide.user/8928/
http://thread.gmane.org/gmane.comp.ide.mseide.user/8846
The wonders of
AMD Athlon XP 3000+ has a single core only
So no work for openMP = no openMP bugs :)
Boot from a Linux life CD/DVD and restore it.
Tried a lot of times - the LINUX+Grub2 installation and/or the
motherboard seem to be too up-to-date to be
IIRC Koenraad Lelong successfully used MSEgui on ARM:
===
Will it be possible to switch on openGL backend for GUI drawing on ARM ?
--
Flow-based real-time traffic analytics software. Cisco
On Sunday 02 March 2014 11:45:07 Ivanko B wrote:
AMD Athlon XP 3000+ has a single core only
So no work for openMP = no openMP bugs :)
There are problems, please compare the Linux and win32 rotation times.
Boot from a Linux life CD/DVD and restore it.
On Sunday 02 March 2014 11:48:30 Ivanko B wrote:
IIRC Koenraad Lelong successfully used MSEgui on ARM:
===
Will it be possible to switch on openGL backend for GUI drawing on ARM ?
Yes, although OpenGL for 2D GUI rendering is a nightmare to work with.
Martin
although OpenGL for 2D GUI rendering is a nightmare to work with.
===
Is it possible to activate it right now ?
Where is the money? ;-)
===
Ones wait till You'll need some ARM/AVR programming for Youself :)
On Sunday 02 March 2014 12:29:43 Ivanko B wrote:
although OpenGL for 2D GUI rendering is a nightmare to work with.
===
Is it possible to activate it right now ?
On Linux yes, I don't know the state on Windows.
Martin
attachment:
I don't know the state on Windows.
===
Me can check on win7 :). How to activate ?
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc.
On 03/02/2014 05:45 AM, Ivanko B wrote:
AMD Athlon XP 3000+ has a single core only
So no work for openMP = no openMP bugs :)
Boot from a Linux life CD/DVD and restore it.
Tried a lot of times - the LINUX+Grub2 installation and/or the
On Sunday 02 March 2014 10:29:04 Ivanko B wrote:
MSEgui to RaspberryPi
=
To ARM CPUs.
The wonders of computing! ;-)
===
Or bugs of using openMP :) 4 cores are slower than 2 ones. But only
scaling is 3 times as faster.
Can you make tests on Linux too?
1920x1080-5000x3000 = 1..2sec
5000x3000-5000x3000 = 0.7sec
5000x3000-5000x3000x45degrees = 130sec
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc.
On Sunday 02 March 2014 20:14:31 Ivanko B wrote:
1920x1080-5000x3000 = 1..2sec
5000x3000-5000x3000 = 0.7sec
5000x3000-5000x3000x45degrees = 130sec
This is with gm not with MSEgui? Can you show the command line? How much
memory do you have? How long lasts 1920x1080 rotating 1°?
Martin
On Friday 28 February 2014 22:25:29 Ivanko B wrote:
Now it works and me can compare FPIMAGE GM versions. GM is approx
2.5 times as faster in the testcase.
Both versions load CPU cores similarily, BTW. So GM wins by better
alghorithms.
Another testcase is here:
At a glance, the delays are most likely not GM related. Even without
downscaling GM wins approx 2 times anyway in this testcase.
But with upscaling GM looses FPImage wiuthout scaling.
Double upscaling - 1920x1080 (the pic me sent)- 3000x2000 -
5000x3000x45rot.deg GM performs very slow - 140
5000x3000x45deg, sure.
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and
On Saturday 01 March 2014 15:44:48 Ivanko B wrote:
At a glance, the delays are most likely not GM related. Even without
downscaling GM wins approx 2 times anyway in this testcase.
But with upscaling GM looses FPImage wiuthout scaling.
Sure, because the amount of pixels which must be
On Saturday 01 March 2014 15:47:46 Ivanko B wrote:
5000x3000x45deg, sure.
On Linux, AMD Athlon 64 X2 4000+,reading and displaying a 4800x3000 png:
magick 1.78s (one core loaded)
builtin9.215 (one core loaded)
Reading the 4800x3000 png, rotating 5°, backgroundcolor cl_white,
On Saturday 01 March 2014 17:46:35 Martin Schreiber wrote:
On Saturday 01 March 2014 15:47:46 Ivanko B wrote:
5000x3000x45deg, sure.
On Linux, AMD Athlon 64 X2 4000+,reading and displaying a 4800x3000 png:
magick 1.78s (one core loaded)
builtin9.215 (one core loaded)
Just checked - Paint.NET XNview don't cause any serious load to CPU
(some load) GPU (frequencies of the idle state) while performing the
operations.
(me test on win7 = GDI32+).
--
Flow-based real-time traffic analytics
On Saturday 01 March 2014 19:02:08 Ivanko B wrote:
bottleneck is the GPU and videoram in this case?
===
ATI/AMD HD6850 1GB DDR5 is a powerful GPU and the whole test machine
is a powerful machine.
Lte's see related sensors data. The GPU it's not loaded at all (see
On Saturday 01 March 2014 21:07:52 Ivanko B wrote:
It seems that only rotation loads both cores
[..]
You probably misinterpret the times. Please read my previous mails.
==
Upscaling performs fast - 1 sec.
But combined with rotation - 130 sec or even AV.
Yup, rotating with
simulated by MSEgui in memory
==
Anyway 130+ is too slow.
cl_white = 145 sec white result image
rotmonomask = 141 sec white result image
=
Please present an exact setting set for fast 1920x1080-5000x3000
upscaling 45deg rotating.
On Saturday 01 March 2014 21:07:52 Ivanko B wrote:
It seems that only rotation loads both cores
[..]
You probably misinterpret the times. Please read my previous mails.
==
Upscaling performs fast - 1 sec.
But combined with rotation - 130 sec or even AV.
I was wrong, there
On Sunday 02 March 2014 08:25:23 Ivanko B wrote:
simulated by MSEgui in memory
==
Anyway 130+ is too slow.
cl_white = 145 sec white result image
rotmonomask = 141 sec white result image
=
Please present an exact setting set for fast 1920x1080-5000x3000
There's a discussion about GUI-performance
http://freepascal.ru/forum/viewtopic.php?f=5t=9710p=80014#p80014
The hardware is:
The SoC is a Broadcom BCM2835. This contains an ARM1176JZFS, with
floating point, running at 700Mhz; and a Videocore 4 GPU@ 250 MHz. The
GPU is capable of BluRay quality
MS WINDOWS:
---
mseclasses.pas(1182,13) Warning: Symbol PBOOLEAN is deprecated
mseclasses.pas(1182,23) Error: Incompatible types: got Boolean expected Byte
mseclasses.pas(5720) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error:
On Friday 28 February 2014 10:58:49 Ivanko B wrote:
MS WINDOWS:
---
mseclasses.pas(1182,13) Warning: Symbol PBOOLEAN is deprecated
mseclasses.pas(1182,23) Error: Incompatible types: got Boolean expected
Byte mseclasses.pas(5720) Fatal: There were 1 errors compiling module,
Now works with GraphicsMagick but fails (JPEG erorr) with FPIMAGE:
---
#0 0040AC16 :0 fpc_raiseexception()
#1 0054B438 :0 FPREADJPEG_JPEGERROR$J_COMMON_PTR()
#2 0054CD9E :0 JERROR_ERREXIT2$J_COMMON_PTR$J_MESSAGE_CODE$LONGINT$LONGINT()
#3 0054F538 :0
On Friday 28 February 2014 13:18:00 Ivanko B wrote:
Now works with GraphicsMagick but fails (JPEG erorr) with FPIMAGE:
It works
---
#0 0040AC16 :0 fpc_raiseexception()
#1 0054B438 :0 FPREADJPEG_JPEGERROR$J_COMMON_PTR()
#2 0054CD9E :0
Do you read a JPEG?
Now works with GraphicsMagick but fails (JPEG erorr) with FPIMAGE:
It works
---
#0 0040AC16 :0 fpc_raiseexception()
#1 0054B438 :0 FPREADJPEG_JPEGERROR$J_COMMON_PTR()
#2 0054CD9E :0
Do you read a JPEG?
The attached testcase fails if switched to
On Thursday 27 February 2014 21:10:17 Martin Schreiber wrote:
On Thursday 27 February 2014 07:11:47 Martin Schreiber wrote:
On Wednesday 26 February 2014 23:21:28 Ivanko B wrote:
GraphicsMagick is very fast (just tasted) but how cat it (multiple
DLLs of 10+ Mb size) be set up once for
On Friday 28 February 2014 16:26:01 Ivanko B wrote:
---
#0 0040AC16 :0 fpc_raiseexception()
#1 0054B438 :0 FPREADJPEG_JPEGERROR$J_COMMON_PTR()
#2 0054CD9E :0
Do you read a JPEG?
The attached testcase fails if switched to FPIMAGE, on same file set.
On Friday 28 February 2014 19:20:15 Ivanko B wrote:
With a JPEG? Can you post the image somewhere?
Sure, here atatached.
Please try again with git master c5af3c1852f3f45685ff536d18ab1733a4d71f1b.
Martin
--
Now it works and me can compare FPIMAGE GM versions. GM is approx
2.5 times as faster in the testcase.
Both versions load CPU cores similarily, BTW. So GM wins by better alghorithms.
--
Flow-based real-time traffic
On Friday 28 February 2014 22:25:29 Ivanko B wrote:
Now it works and me can compare FPIMAGE GM versions. GM is approx
2.5 times as faster in the testcase.
Both versions load CPU cores similarily, BTW. So GM wins by better
alghorithms.
Most likely the time to transfer the image from GM memory
It is thought as extension with a register unit.
=
Since GraphicsMagick is installed on WINDOWS with an installer
program, then probaly it needs including search path when loading DLLs
from MSEgui apps.
on X86:
HKEY_LOCAL_MACHINE\SOFTWARE\GraphicsMagick\Current\LibPath
on
On Thursday 27 February 2014 07:11:47 Martin Schreiber wrote:
On Wednesday 26 February 2014 23:21:28 Ivanko B wrote:
GraphicsMagick is very fast (just tasted) but how cat it (multiple
DLLs of 10+ Mb size) be set up once for using by any MSEgui in MS
WINDOWS...
It is thought as extension
What should me put in msemagickstream.registerformats([],[],[]) for
PNG JPEG formats ?
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with
On Thursday 27 February 2014 23:37:11 Ivanko B wrote:
What should me put in msemagickstream.registerformats([],[],[]) for
PNG JPEG formats ?
registerformats(['png','jpeg'],
[stockobjects.captions[sc_PNG_Image],
stockobjects.captions[sc_JPEG_Image]],
pngfilter,jpgfilter
=
There're no these idents in the MSE* tree.
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
On Friday 28 February 2014 08:24:42 Ivanko B wrote:
pngfilter,jpgfilter
=
There're no these idents in the MSE* tree.
const
pngfilter: array[0..0] of msestring = ('*.png');
jpgfilter: array[0..0] of msestring = ('*.jpg');
Martin
On Friday 28 February 2014 08:33:21 Martin Schreiber wrote:
On Friday 28 February 2014 08:24:42 Ivanko B wrote:
pngfilter,jpgfilter
=
There're no these idents in the MSE* tree.
const
pngfilter: array[0..0] of msestring = ('*.png');
jpgfilter: array[0..0] of msestring
It
[...]
initialization
msemagickstream.registerformats(['png','jpeg'],
[stockobjects.captions[sc_PNG_Image],
stockobjects.captions[sc_JPEG_Image]],
[]
);
[...]
causes exception Range Check Error :
#0 0040ABF6 :0 fpc_raiseexception()
#1 00457D65 :0
GraphicsMagick is very fast (just tasted) but how cat it (multiple
DLLs of 10+ Mb size) be set up once for using by any MSEgui in MS
WINDOWS...
--
Flow-based real-time traffic analytics software. Cisco certified tool.
On Wednesday 26 February 2014 23:21:28 Ivanko B wrote:
GraphicsMagick is very fast (just tasted) but how cat it (multiple
DLLs of 10+ Mb size) be set up once for using by any MSEgui in MS
WINDOWS...
It is thought as extension with a register unit. Add msemagickstream to uses
and call
There's also
https://github.com/CRVI/OpenCLIPP
based on the standar-de-facto OpenCL (provided by video hardware
drivers for maximum pcocessing drawing accelaration) with headers at
http://www.khronos.org/registry/cl//
There's also http://imlab.sourceforge.net/features.html but it doesn't
seem
On Sunday 23 February 2014 12:45:11 Ivanko B wrote:
There's also
https://github.com/CRVI/OpenCLIPP
based on the standar-de-facto OpenCL (provided by video hardware
drivers for maximum pcocessing drawing accelaration) with headers at
http://www.khronos.org/registry/cl//
Does it read and
Looks very good!
Rather useless (using 1% of power of modern hardware still being slow)
unless h/w accelerated.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has
On Sunday 23 February 2014 15:05:38 Ivanko B wrote:
Looks very good!
Rather useless (using 1% of power of modern hardware still being slow)
unless h/w accelerated.
Maybe for image manipulation but for reading/writing image formats? I assume
it is 10 times faster than fpimage
Maybe for image manipulation but for reading/writing image formats?
=
As a non-accelerated fallback and for the ARM arch) ?
I assume it is 10 times faster than fpimage anyway
==
Unless rewriten to Pascal ?
For image editors etc software h/w accelaration of vector
Like fpimage but faster? A big task if it should handle all the different
image formats and variations.
i start writing codes for image decoding , and the format is only jpg
, png , tga . so don't expect too much.
in fact this is the image part of my 2D engine . which its not finished yet .
so
disappointed with some filters , gcc was alot faster
===
Maybe because FPC doesn't generate SSE/AVX instructions at all - but
external h/w optimized C DLLs for vector and/or parallel operations
may help.
What's OpenCL appp is (it has run-time code stored in CL-resource
files) and how it behaves on different settings, You may see
http://www.likan.uz/uploads/amd_teapot.rar
(SHA1 = 00f20f6d37e405ff49936aeed59894a59e864f51).
At me, with 128x128x265 smoke there're CPU's FPS=1.5 with 100%
There's also http://opencv.org - it can read/write image files, can
work with OpenGL/OpenCL h/w acceleration, can perform a lot of
operations, exposes both C C++,..
http://docs.opencv.org/,
On Sunday 23 February 2014 20:02:27 Ivanko B wrote:
Maybe for image manipulation but for reading/writing image formats?
=
As a non-accelerated fallback and for the ARM arch) ?
I search a replacement for the slow and incomplete fpimage image format
loading and writing
On Sunday 23 February 2014 21:23:17 misu kun wrote:
Like fpimage but faster? A big task if it should handle all the different
image formats and variations.
i start writing codes for image decoding , and the format is only jpg
, png , tga . so don't expect too much.
in fact this is the
GraphicsMagick has OpenMP support AFAIK.
Wow, it's excellent since in this case image processing even if slow
won't slow down GUI :)
And since it's compiled by GCC then it has some SSE optimizations
(though not inline ASM) - may be it's a one more cause why FPIMAGE
(lacks any SSE)
just from some open source projects , like zengl or joim
https://github.com/XProger/joim/blob/master/src/jimg.pas
http://code.google.com/p/zengl/source/browse/#svn%2Fbranches%2F0.3.x%2Fsrc
also seems http://nothings.org/stb_image.c looks much complete but its
writen in C , so it could be
On Saturday 22 February 2014 09:56:29 misu kun wrote:
just from some open source projects , like zengl or joim
https://github.com/XProger/joim/blob/master/src/jimg.pas
http://code.google.com/p/zengl/source/browse/#svn%2Fbranches%2F0.3.x%2Fsrc
also seems http://nothings.org/stb_image.c looks
i don't know about this one , but seems a huge library there is no
pascal port for it
if i will use external dll library , i'll choose freeimage
(http://freeimage.sourceforge.net/) less size and powerful.
btw : i am writing a library for such thing in fpc .
i am writing a library for such thing in fpc .
Will it be hardware and/or SSE/AVX accelerated ?
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer -
the first implementation would be pure pascal i'll let the
optimization to the last stage .
i'll show you the library as soon as finished
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the
Ok, without h/w acceleration image manipulations libs are rather useless.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
yes you're right
i am not good assembly programmer , the only thing i can do is write
computation code in C language then compile it with gcc with sse2
enabled , then see the output assembly , then copy/past with some
tweaking to pascal code . or just using the output C object directly.
There's also a freeware open-source multiplatform x86-targeted
hw-accelarated lib:
http://sourceforge.net/projects/framewave/ and
http://framewave.sourceforge.net/ and
http://framewave.sourceforge.net/Manual/aa_000_frames.html
About Framewave
Derived
On Saturday 22 February 2014 13:13:06 misu kun wrote:
i don't know about this one , but seems a huge library there is no
pascal port for it
MSEgui has the infrastructure to dynamically load libraries and I am trained
in making pascal interfaces for C-libs.
if i will use external dll
Hi Martin
dose msegui support images format like png , jpg , if so , whats the
fast way to load images on timage component ?
another thing , are there some thing like ScanLine property so i can
access image data in a faster way .
thanks
On Friday 21 February 2014 22:56:03 misu kun wrote:
Hi Martin
dose msegui support images format like png , jpg , if so , whats the
fast way to load images on timage component ?
At designtime click on the ... button in objectinspector in 'bitmap' row.
At runtime use
thank you very much.
indeed fpimage is slow .
on windows there are alot of options , gdi+ is one , also
OleLoadPicture function which IPicture interface , it is much faster
than fpimage . but it can load only jpg , gif , bmp .
On Saturday 22 February 2014 08:30:32 misu kun wrote:
thank you very much.
indeed fpimage is slow .
on windows there are alot of options , gdi+ is one , also
OleLoadPicture function which IPicture interface , it is much faster
than fpimage . but it can load only jpg , gif , bmp .
I more
92 matches
Mail list logo
