Re: Displaying 120 Mega Pixels in 256 MB Video RAM

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in
message news:2l0b3459gbl94s1l59u36mc4e3uc0gqja0@xxxxxxxxxx
See below...
On Wed, 21 May 2008 22:24:33 -0500, "Peter Olcott"
<NoSpam@xxxxxxxxxxxxx> wrote:


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in
message news:9sm9341u0vf151l6p3m0qkm6nkrbqsm1cf@xxxxxxxxxx
See below...
On Wed, 21 May 2008 14:12:44 -0700 (PDT), PeteOlcott
<PeteOlcott@xxxxxxxxx> wrote:

On May 21, 3:39 pm, Joseph M. Newcomer
<newco...@xxxxxxxxxxxx> wrote:
See below...





On Wed, 21 May 2008 11:43:25 -0700 (PDT), PeteOlcott
<PeteOlc...@xxxxxxxxx> wrote:
On May 21, 1:12 pm, Joseph M. Newcomer
<newco...@xxxxxxxxxxxx> wrote:
See below...

On Wed, 21 May 2008 10:33:54 -0700 (PDT),
PeteOlcott
<PeteOlc...@xxxxxxxxx> wrote:
On May 21, 10:07 am, Joseph M. Newcomer
<newco...@xxxxxxxxxxxx> wrote:
Not sure what you are asking here.

For examle, suppose I have a window that is
nearly
a full screen on my 1920x1200 display.
That's slightly over 2.3Mpixels. If I ask GDI to
display an image that is 120MPx, it will
display the first 2.3MPx and do nothing more. If
I
change the window or viewport origin
(e.g., pan the image) then it will show the
piece
that fits starting at that origin. It
won't use any more display memory than it needs
to
do this, and will ignore all of the
image outside the area I want to show.

If I change the mapping mode so that there is,
say, a 10:1 ratio of image pixels to screen
pixels, then I have a 12MPx image to show. I can
still only show 2MPx of it, but that now
is a larger percentage of the actual image. It
will not use more video memory than it
needs (physical pixels) to do this. So it
doesn't
matter how big your VRAM is, Windows
only uses enough to physically map your image.
GDI
clips the rest. So it seems unlikely
that you will get an 11KPx x 11KPx image into
VRAM, because, as far as I know, there is no
mechanism that allows you to do that.
joe

On Wed, 21 May 2008 06:44:17 -0700 (PDT),
PeteOlcott <PeteOlc...@xxxxxxxxx> wrote:
The first assumption is that 120 Mega Pixel
image
takes 480 MB, 32
bits per pixel, one byte each for red, green,
and
blue, and one byte
of padding to 32-bits.

I am estimating that displaying a 120 Mega
Pixel
image using a 256 MB
video card should not be an issue because the
actual display window
would only use video memory for that portion of
the image that is
currently displayed. Thus a square image that
is
11,000 pixels on each
side should easily fit within video memory
because most of this image
would be scrolled off the screen.

Can anyone please confirm (or deny) this
analysis, and possibly
provide a few details pertaining to how this
would be implemented?

http://www.codeguru.com/cpp/g-m/bitmap/displayingandsizing/article.ph...
For example would the above code work with a
120
Mega Pixel bitmap
file, even if Video RAM is 256 MB, or less?

Joseph M. Newcomer [MVP]
email: newco...@xxxxxxxxxxxx
Web:http://www.flounder.com
MVP
Tips:http://www.flounder.com/mvp_tips.htm-Hidequoted
text -

- Show quoted text -

Hi Joe:

Can you load the whole image such that you can use
scroll bars to see
any part of the full resolution image, even though
video RAM does not
have enough room?

No. What you do on scrolling is use ScrollWindow,
which will typically do an internal (on
the display card) BitBlt to move the image around,
and invalidate the area that is
uncovered. In your OnPaint (particularly with such
a
large image) you would not redraw
the entire bitmap image, but only the part that has
been invalidated. To do this, you
have to DPtoLP the invalidated rectangle (to figure
out where the pixels are on your
bitmap--note that if you are using MM_TEXT, then
the
mapping is 1:1), and then BitBlt the
area that was invalidated (and only that area) into
the DC. This gives the best
performance. Because you can be invalidating only
one
axis at a time (scrolling either
horizontally or vertically) the invalidated
rectangle
is the recently-uncovered area,
which gives you what you need to know to optimize
drawing.

Other than that, you would have to look into
DirectX
technologies to see if they support
this, but it is not clear the investment of time
produces anything useful over clever GDI
optimization (which most introductory books cover).
joe
Joseph M. Newcomer [MVP]
email: newco...@xxxxxxxxxxxx
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm-Hide
quoted text -

- Show quoted text -

Ah yes this makes perfect sense. I only did this sort
of thing once,
and then I used some example code as the basis. It is
only easy to do
using the Doc/View architecture. So the whole image
is
stored in a
memory bitmap, and only a portion of it is BitBlt()ed
to the window,
as needed. Is the whole image stored in a MemDC ? I
forgot the exact
syntax.

Since you had said it was an image, I assumed it was a
bitmap. You might want to rethink
that 32-bit representation and consider 24 bits,
because
the extra byte in an 11Kx11K
image costs you another 100MB of storage, and that's
nontrivial. You would store it in a
bitmap (all bitmaps are in memory), but to BitBlt it
you
would select that bitmap into a
memDC. Note that for an image this massive, you might
want to keep it on disk and
CreateDibSection as needed; it all depends on
performance. You're at a scale where
optimization techniques will definitely start to have
a
payoff. If it wasn't a bitmap,
you would have to figure out what parts to draw using
MoveTo, LineTo, Rectangle, TextOut,
etc., so doing things like keeping a display list
handy
in sorted order helps optimize
this (I was doing graphics in realtime on a 286 using
optimized display lists, and half my
effort was figuring out how to make the redraw
computations blindingly fast)
joe
Joseph M. Newcomer [MVP]
email: newco...@xxxxxxxxxxxx
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm- Hide
quoted text -

- Show quoted text -

On disk it is It is 120 MB of 8-bit pixel values that
represent shades
of grey. These are already stored in ZIP files to
conserve
space. The
main issue that I needed to definatively resolve was
whether or not
any reasonable scenario for displaying this data would
actually
require a hardware upgrade of the video card to 512 MB
VRAM.

From your prior explanation this answer would seem to be
no. There
would exist no reasonable scenarios where displaying an
image of this
size would actually require an upgraded video card.
(from
256 MB to
512 MB) All of the data could be stored in conventional
RAM (memory
device context) and small portions of it could be
BitBlt()ed to the
window as needed. The whole image would still be
available
at full
resolution by scrolling the scroll bars.

Is all of this analysis an accurate paraphrase of what
you
are saying?
****
Note that if you store data compressed, zip compression
(compared to, for example, jpeg)
might not be the optimal compression. It depends on
whether your "shades of gray" are
representing continuous-tone images (such as
photographs).
In that case, why are you
using 32-bit color when 8-bit color will suffice? Seems
like you are creating a massive
file (32-bit color) to represent something that has no
more than 1/4 of that as useful
information. If it is continuous-tone data, jpeg is
going
to be a LOT more efficient than
zip. If there are large blocks of gray, it is possible
that RLE can do better.

There are many more details that I left out for clarity. I
would suppose that using an 8 bit indexed image might make
more sense and use GIF or possibly PNG compression.. (The
problem requirements stipulate lossless compression) I
have
always avoided 8 bit indexed images because they add too
much complexity.
****
You have a choice: mild complexity or massive performance
hit. 480MB vs. 120MB is a BIG
difference in your memory footprint! Wasting 360MB of
data to save a few lines of code
is not a good tradeoff. Remember: optimization matters
only when it matters, and in this
case, it matters.

Note that if you have grayscale, 8-bit is not lossless.
There is no information lost if
RGB(192,192,192) is represented by the 8-bit color 192.
For that matter, the extra byte
of the 32-bits is also useless, and other than costing you
120MB of useless information,
it is harmless. But why waste massive amounts of space.
Therefore, representing
grayscale as 8-bit values is lossless.

Scale matters, and at the scale you are working at, it is
worth spending a little effort
to do things like avoid unnecessary page faults, which
will kill your performance.
****

The primary issue that must be addressed here is video RAM.
It seems like the current architecture actually requires
that the whole image fit in video RAM. Before we even begin
to look at optimizing disk space or memory use we must first
address unnecessary hardware upgrades. Are you completely
sure that there is no good reason why a 120 mega pixel image
could not be displayed on a machine with a 256 MB video
card?



If the only color is gray, there is absolutely no reason
to store more than 8-bit color as
grayscale.

The VRAM on the video card would buy precisely nothing,
because there is no way to use it.
Most large video cards have advantage only when there
are
large texture maps involved, or
double-buffering of large images via DirectX.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm


.

Relevant Pages

  • Re: Text overlay on image then Save to JPEG with reasonable DPI for Online printshop
    ... > Let's suppose I have an image of 1500 X 1500 pixels of which I ... picture at the top right of the card, or whether it is actually the card ... memory (an invisible VB picture box or a memory bitmap or DIBSection or ... What you "display to the user" while he is ...
    (comp.lang.basic.visual.misc)
  • Re: Will F1 be on BBC HD?
    ... video monitors used in video editing. ... display, so you have to scale the incoming video to fit the display ... pixels are *not* square, even for 4:3 displays so you need to scale ... than just about any CRT. ...
    (rec.autos.sport.f1)
  • Re: Draw Performance Improvement
    ... > same bit depth and bit masks as the primary display driver. ... > and not the display card's video memory. ... For the display hardware to ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Displaying 120 Mega Pixels in 256 MB Video RAM
    ... a full screen on my 1920x1200 display. ... won't use any more display memory than it needs to ... pixels, then I have a 12MPx image to show. ... video card should not be an issue because the ...
    (microsoft.public.vc.mfc)
  • Re: still no resolution solution..
    ... & still unable to achieve 1600x1200 display, ... motherboard w/ sapphire radeon 4650 video card. ... driving a dell m782 monitor (same monitor was ... Module "ddc" already built-in ...
    (Fedora)