views:

416

answers:

4

Hi All,

as developer of industrial vision applications I frequently have rather clunky images like 6000x4000Pixels and bigger.

While the camera and imageprocessing is working on a steady stream of new images (and this processing is the main task) I would like to allow the user to comfortably view some other image in parallel.

Doing this on the processor (GDI etc.) steals way too much performance. For example it takes us 0.2 seconds to analyse the image but 0.8 seconds to show it with a single zoom (resized to fit some control), let alone let the user move on and dive into it.

Since Photoshop allows to show and zoom by the help of the graphic card's very fast memory and processing I wondered if anyone can give me an idea if and how I can experiment on this in my own code: push data to graphic card (how long may this take for my 76MB of rgb-data?) and let it show in some control without much effort to zoom and move in it by user to the control/card for user interaction.

No need for 3D looks, just moving and resizing in a 2D-rgb-image. Aim is to enable fast and comfortable viewing with low processor load.

==> Is this possible (as texture or something the like)? ==> Are there limitations with current low-end-3D-cards of >=256MB? ==> can somebody suggest some durations to expect (copy data, zooming)?

Thanks for any hint!!

A: 

What is the pixel format? Your size number seems to work with this being 8-bit RGB, a single image at 6000x4000 pixels should then need roughly 69 MB of space. So it should fit in the texture memory of a lower-end graphics card, assuming there's not too much overhead from Windows and other apps. Sure, it will take a while to upload to the graphic card's memory; hard to provide an estimate though since it will very likely vary with system load and of course your hardware/bus configuration.

I'd be more worried by the max limit on texture sizes. I think today's higher-end cards max out at 4096x4096 texels in a texture, meaning you would be unable to fit your image into a single texture.

Setting up DirectX to test this out shouldn't be too hard, there are plenty of tutorials around. Here is a quick link showing how to render with texture; check out the previous parts of the same tutorial series to see how to initialize stuff.

unwind
the image is available as three single planes of 8-bit-gray for R,G and B. To mix it up some other way won't be an issue.So the memory fits into the memory but not onto a single texture? Is Placing two planes side by side an option or will it bring in artefacts?Thanks for link and idea!
Placing one or more planes next to each other, subdividing the image data to match, is the obvious solution. It should be possible to set texture filtering modes to avoid artefacts. You're welcome to upvote the answer if it helped you. :)
unwind
A: 

I'd recommend that you use format designed specifically for that kind of task. It's JPEG2000. The features you want are called ROI (Regions of Interest) and progressive transmission. It can be lossless if you need it.

vartec
Thanks for the idea, but coding the data into JPEG2000 takes about full five seconds. This is not an option as it takes way too much time and processor load.
Can't you store or cache that data in JPEG2000?
vartec
BTW. you can GPU-accelerate that. See e.g. http://www.cse.cuhk.edu.hk/~ttwong/software/dwtgpu/dwtgpu.html
vartec
+1  A: 

You're going to be limited by max texture size (which varies from card to card), so you'll have to subdivide your big image into several smaller textures. Getting the actual texture data to your video memory should be plenty fast as long as the card is AGP or PCI-E.

snemarch
A: 

You can do this with Direct3D. It will easily handle large images for panning and zooming by drawing a textured quad.

Due to the size of your images and the size of the screen (you don't have a 6Kx4K display, do you?), you'll want to create a system for paging your large image into textures on demand. Given the size of your input data, I think you'll find that the dominating factor in how fast you can get stuff into the card is the I/O bandwidth between the disk and the card. You may find that it is worthwhile to create a way of storing the images on disk that exploits spatial coherence in two dimensions (i.e. a tiled storage layout, not a scanline storage layout) as well as calculating point-sampled lower resolution versions. You can do all this yourself with uncompressed RGB, you don't need JPEG2000 in order to do this. You could do this data storage as a low priority background process once they select an image. First get what's going to be visible on screen into the card ASAP and then start reorganizing it on disk for faster streaming/zooming.

legalize