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

By the way,
maybe a 64bit processor with more virtual memory available
would solve the problem.

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)
    ... second is that even if you want only to see the image, you need to load all of it's pixels. ... smaller sample for display. ... BEFORE loading it. ...
    (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)