Re: Next Version of GDI+ (maybe GDI+ 2.0)

Alejandro Lapeyre wrote:
> We are not talking about speed. Just to be able to work with
> "large" images.
> You don't need to load the full image to apply an effect on it.

the main issue IS speed:
> My last hope was with the release of Visual Studio 2005 and .NET 2.0,
> but my testings yesterday with the Beta 2 showed the same slowness as
> before.
> Big mono TIF drawings with a size of more than 10.000x10.000 (around
> 300-500kb) pixel can't load if other applications are open and eating
> ram.
> Smaller Images are working fine like before :/
i'm not sure, but comon image formats does not allow you to read only parts of an images. that's first problem. second is that even if you want only to see the image, you need to load all of it's pixels. and you need time for that. no mater if you read in pices or whole image at once.
maybe it is possible to do it in parts but it is probably very very complicated.

Even if you insist that you must load the full image to apply an effect on it,
what are you going to use to apply the effect? A giga-matrix-processor that
will simultaneously work on all pixels at the same time?
i did not ment workinkng with all the pixels at the same time. as i said it earlier, to process whole image you need to read it all. it doesn't matter if it is done in parts or at once. and if it is 400mb it must take some time. come on, how fast can you read from hard drive?

now, in this case even if this is a mono image but still huge, methods provided by .net need to load whole image. period. if you really need you can write your own methods. .net is not a ultra complicated imaging framework. it's just generel purpouse framework, so don't expect highly specialized algorytms and methods. it works like this: you want an image? sure no problem just do Image.FromFile("file"); and you have one. but that's all. if they went deeper with imaging, they would have to go deeper with all other stuff. and if they did that, well probably today you would only have .net framework 0.3 beta, and the team behind it would be a half o microsoft eployes :D only what for? how often general user needs to do some complicated imgae, sound or video procesing?

oh and last thing: does this images (that are the broblem) are disposed after use? if no, it is nothing wired that app eats all the ram.



You do thinks sequentially, you read a bunch of pixels, process them,
save the result and repeat. It doesn't matter for the algorithm where the
other pixels are.

First make it work - then make it faster.

Best regards
Alejandro Lapeyre

"SharpCoderMP" <csharp_mp@xxxxxxxxxxxxxxxx> escribió en el mensaje news:eqmx5FsbFHA.2212@xxxxxxxxxxxxxxxxxxxxxxx

you're right. but:
loading and manipulating of such files isn't lightning fast unless you have really powerfull dedicated hardware (but still i dubd that you'd be able to do it in miliseconds).
don't count on .net to handle all this in nanoseconds - it takes alot of hard work in lover level languages to achive considerably good perfomance in these extreme cases.
look. even builtin windows xp image viewer needs some time to display images larger than few megabytes. why you'd expect to have the same api do it faster? it's not about GDI+ itself but what is inside (or beneath).



also with images i'ts a bit different than with sound or video. to see whole image you need to read whole image, and then eventualy generate a smaller sample for display. BUT to have this smaler sample you need to load ALL the pixels of oryginal image.
when you work with sound - it's different. you don't have to load whole file to start listening. only thing you need is few seconds of buffered read. that's all. BUT when you want to manipulate whole sound file, you need to process all the data inside. so it will ALSO take ALOT of time. just like with huge image.

in theory there is posibility to work with images in the same way - but in that case you'd have to specify wich part of an image you want to display BEFORE loading it. it also won't be possible to do with certain formats. as far as i can remeber you can't see lower right pixel of jpeg file before loading whole image.
despite that, still if you'd like to apply let's say filter to whole image you'd have to process the whole image. and that will take time.
anyway i think that work only with parts of image files is imposible with .net unless you go deep inside raw byte data.

despite all i said i don't see the point of using such a huge images. what do this images contain? schematics of new p4 processors? what do you want to do with them? print in sizes of 10x10 meters? :)
if so, maybe it's better to use vectors? if these images aren't photos and you need them so huge you surly need to consider vector images instead of bitmaps.


Alejandro Lapeyre wrote:

Wave files and video files are larger in size, but there are myriads of program to handle them, edit them, apply fx on them, etc. since DOS times. I work with SONAR (a music production system) and a song can easily consist of 1 giga bytes in raw wav data. The data is buffered.

The problem with images is that the trend was to load the image completely from disk, to provide a fast display. Its time to change this trend a bit.

In the meantime, you can only use the framework Image class only for small images (or not that large images, if that pleases you).

For everything else you should look for other libraries.

Best regards
Alejandro Lapeyre


"SharpCoderMP" <csharp_mp@xxxxxxxxxxxxxxxx> escribió en el mensaje news:eQpp1epbFHA.720@xxxxxxxxxxxxxxxxxxxxxxx


i don't get it. why you need such a huge images???
i work in publishing brand. boy, it is really rare to need an image that is biger than 70-80mb. are you sure you need something of this size (400mb)?
look at proffesional imaging software, even photoshop will have problems only with loading this giant! no matter what you do, if you want to load this image you still need alot of memory. not mentioning manipulating this monster.

how much ram do you have? even 1gb won't be too much. and remember that this image needs to be loaded from disk. your os dosen't load 400mb in a wink of an eye even from superfast scsi hardrive.



Benny wrote:


My technical images are having often more than 300 DPI and 10k px.
They must be displayed very accurate and detailed, so I can't do any
big rescaling or such things.

The memory usage is to much for my project.
Now I have to try to load the image by myself in tiles. Thats what I
don't wanted to do.

But back to the topic, does anyone know something about the next GDI+
release?




.

Relevant Pages

  • Re: Next Version of GDI+ (maybe GDI+ 2.0)
    ... loading and manipulating of such files isn't lightning fast unless you have really powerfull dedicated hardware. ... to see whole image you need to read whole image, and then eventualy generate a smaller sample for display. ... BUT to have this smaler sample you need to load ALL the pixels of oryginal image. ...
    (microsoft.public.dotnet.framework.drawing)
  • Re: Next Version of GDI+ (maybe GDI+ 2.0)
    ... Alejandro Lapeyre ... > loading and manipulating of such files isn't lightning fast unless you ... > smaller sample for display. ... > load ALL the pixels of oryginal image. ...
    (microsoft.public.dotnet.framework.drawing)
  • Re: Next Version of GDI+ (maybe GDI+ 2.0)
    ... You don't need to load the full image to apply an effect on it. ... You do thinks sequentially, you read a bunch of pixels, process them, ... > loading and manipulating of such files isn't lightning fast unless you ... > smaller sample for display. ...
    (microsoft.public.dotnet.framework.drawing)
  • Using Multi-threading
    ... I am designing an interface which allows users to load certain files ... I want to display a ... want the form to be displayed during the loading process and the ...
    (microsoft.public.dotnet.languages.vb)
  • fetch a manay URLs
    ... when they are all downloadded I parse the data and display some results ... loading the next one is loaded. ... any suggestions would be good all I realy want is a way to load all the ...
    (comp.lang.perl.misc)
Loading