I have an 8bit tiff thats 14406x9606 pixels that when loaded via BitmapImage throws a System.OutOfMemoryException. As a full depth bitmap its about 400 megs in size. Is there a way to partition the image into more manageable chunks? I've tried using DecodePixelHeight to load it at a lower resolution and this works, but then I need to reload whenever the zoom level changes. Are there any established tools for dealing with really large images in WPF at differing zoom levels?
There is nothing built-in that handles this directly. DecodePixelHeight, as you mentioned, is probably the best option in the framework itself.
However, you could use something like the C# wrappers for GDAL. GDAL handles very large TIFF files, including ones with pyramids, and allow you to (very quickly) open up the TIFF at varied resolutions without loading the entire file into memory. This will still require a refresh/reload on resolution change, but the speed of their TIFF loading is quite a bit faster than the framework's imaging classes, as it's designed to handle extremely large imagery.
You may want to try LibTiff.Net library. It's written in pure C# code, free, open source (commercial-friendly BSD license).
LibTiff.Net can handle TIFF files up to 4 GB in size and may be used to open files without decoding all the samples. The library also supports multi-strip and tiled TIFF files.
Disclaimer: I am one of the maintainers of the library.
Related
I want to be able to load/save jpeg files on Windows via api, specifically gdi32.dll because it looks to universally exist in all versions of Windows.
But I'm unable to find any information on how to do this from an array of pixels with 4 bytes per color (rgba, bgra, rgb would be ok to since jpeg doesn't support alpha etc.)
Not interested in an external library or gdi+. gdi32 should have the ability, but I can't seem to find enough information on how to implement it.
I am going to ignore your refusal to use anything outside of gdi32.dll, because that kind of requirement is not likely to help anyone, and as #David Heffernan said, there is no JPEG support in gdi32.dll.
There are a number of ways to load/save JPEG pictures built into winapi, and supported all the way back to Windows 2000 (and earlier...).
OleLoadPicture / OleSavePicture - though I am not sure if it's very easy to save your own JPEG files this way.
Gdiplus::Image allows loading & saving JPEG files.
Plain GDI does not have any support for JPEG.
If you won't countenance using a library other than GDI, then you will have to write your own JPEG library. Allow me to recommend that you reconsider your requirements.
The GDI is the Graphical Device Interface. It's responsibility includes rendering primitives to the screen or offscreen device contexts. Encoders and decoders are not included.
The standard Windows encoders and decoders are provided through the Windows Imaging Component. This component is available starting with Windows XP SP2. It is also available for Windows Store apps.
I have a WPF application that acquires images from a camera, processes these images, and displays them. The processing part has become burdensome for the CPU, so I've looked at moving this processing to the GPU and running custom CUDA kernels against them. The basic process is as follows:
1) acquire image from camera
2) load image onto GPU
3) call CUDA kernel to process image
4) display processed image
A WPF-to-CUDA-to-Display Control strategy is what I'm trying to figure out.
It seems natural that once the image is loaded onto the GPU that it would not have to be unloaded in order to be displayed. I've read that this can be done with OpenGL, but do I really need to learn OpenGL and include it in my project in order to do a fast display of a CUDA-processed image?
I understand (I think) the issues of calling CUDA kernels from C#. My plan is to either build an unmanaged library around my CUDA calls, which I later wrap for C# -- OR -- try to decide on which one of the managed wrappers (managedCUDA, Cudafy, etc.) to try. I worry about using one of the prebuilt wrappers because they all appear to be lightly supported...but maybe I have the wrong impression.
Anyway, I'm feeling a bit overwhelmed after days of researching the possible options. Any advice would be greatly appreciated.
The process of taking a result of CUDA computation and using it directly on the device for a graphics activity is called "interop". There is OpenGL "interop" and there is DirectX "interop". There are plenty of CUDA sample codes demonstrating how to interact with computed images.
To go directly from computed data on the device, to display, without a trip to the host, you will need to use one of these 2 APIs (OpenGL or DirectX).
You mentioned two of the managed interfaces I've heard of, so it seems like you're aware of the options there.
If the processing time is significant compared to (much larger than) the time taken to transfer the image from host to device, you might consider starting out by just transferring the image from host to device, processing it, and then transferring it back, where you can then use the same plumbing you have been using to display it. You can then decide if the additional effort for interop is worth it.
If you can profile your code to figure out how long the image processing takes on the host, and then prototype something on the device to find out how much faster it is, that will be instructive.
You may find that the processing time is so long you can even benefit from the double-copy arrangement. Or you may find the processing time is so short on the host (compared to just the cost to transfer to the device) that the CUDA acceleration would not be useful.
WPF has a control named D3DImage to directly show DirectX content on screen and in the managedCuda samples package you can find a version of the original fluids sample from Cuda Toolkit using it (together with SlimDX). You don’t have to use managedCuda to realize Cuda in C#, but you can take it to see how things can be realized: managedCuda samples
I am trying to develop a YUV image viewer. The objective is it read YUV images and displays the image in a window.I am using C to develop this application.
After transforming YUV information to RGB data, to view the image i am using cvShowImage and cvResize functions from OpenCV. To use this application in other systems i need opencv to be installed in them as i am using precompiled dll's. I fixed this issue by re-compiling the program with static libraries basing on the guide provided in "How to embedd openCV Dll's in Executable" and generated a fresh executable which is portable across machines. This resulted my application file size to grow from 100KB to 2350KB. This growth is enormous. I suspect this is because of several unnecessary functions are getting linked to my final executable
for this i used the switch Eliminate Unreferenced Data (/OPT:REF). But this did not solve anything.
Is there any way to solve this issue?
The linker automatically removes all the unneeded code from you exe.
But if you remember that your program incorporates
all the code to read all kinds of image formats (bmp, jpg, tiff, etc, etc, etc),
a good part of the OpenCV core (matrix handling)
some OS-specific windowing and message handling (to display the image and be able to resize/click/etc)
some other utilities that you use and do not know
That's it... a few MB of code.
EDIT
Do not forget to build your program in Release mode. In Debug mode, to the standard code there is added some more info related to debugging.
I work with satellite radar, and have been provided with a (very) large TIFF file containing 32 bpp greyscale data. Unfortunately, libtiff, the standard Linux library for working with TIFF files, doesn't support SampleFormat TIFF files, which means no support for high bit depth greyscale images or floating-point images.
Does anyone know of a FOSS C library which provides support for these types of images? Failing that, can anyone suggest of an appropriate file format to convert to, and a FOSS library that can load that? (Ideally, it should be generally accepted by the scientific community for data interchange, and supported by IDL/ENVI).
Well libtiff should be able to handle the format, although you may be limited to the low-level apis and doing the conversion to an image yourself. If the size of the images are >4Gb, there is bigtiff, a port of libtiff which handles extremely large images.
For a web project I need the possibility to generate jpg and animated gif images very fast. As server platform I will use Linux and the NekoVM (behind a apache via mod_tora). As there is no library for image generation for Haxe and neko I am about to write a own one.
Neko itself is written in c, and you can simply extend the VM writing shared libraries with c. At the moment we playing arround with libGD, which offers all the features we need (resizing, sampling, copying images, adding text, save as jpeg or animated gif) and of course a lot of stuff we don't need.
At the moment this works great, but it seems to be a little bit slow. Is there another popular open library that I could try to use for my purposes (and that is maybe faster)?
Have you tried Magick++ and/or MagickCore?
Your next best bet is to run NekoVM under pprof to figure out which function(s) are the most costly in libGD, and try to avoid or optimize your use of those by changing your calling code.
There is imlib2, I doubt that it support animated gif's.