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.
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 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 was just discussing if there was an alternative windows graphics library to GDI & Direct X in a forum. Someone mentioned WinDIB. Sadly, he didn't explain more about it.
Now I've searched google.
There seems to be no Wikipedia article on Windows DIB.
It appears that some graphics libraries such as SDL use a WinDIB backend.
So what exactly is WinDIB? Is there any documentation to it? Where can I learn more about it?
Windows Embedded CE and DirectX use the device-independent bitmap (DIB) as their native graphics file format.
A DIB is a file that contains information describing the following:
An image's dimensions,
The number of colors the image uses,
Values describing the colors used,
Data that describes each pixel.
A DIB also contains lesser-used parameters, like:
Information about file compression,
Significant colors (if all are not used),
Physical dimensions of the image (in case it will end up in print).
DIB files usually have the .bmp file extension, although they can use a .dib extension.
Because the DIB is so pervasive in Windows programming, Windows Embedded CE contains many functions you can use with DirectX.
SOURCE
http://msdn.microsoft.com/en-us/library/aa917106.aspx
DIB stands for Device Independent Bitmap. It is a Windows-specific general bitmap format. Essentially it is the format of a Windows [.bmp] file. It is very useful as an intermediate format in order to e.g. present OpenCV pictures in native Windows windows.
As an example, my ColorDib.h file, from the last few days, supports a limited subset of the DIB formats, namely palette-free RGB pictures. I have used that to display OpenCV video in a native Windows window. Actually, complete source for that is at the Bitbucket repository that the link goes to.
Microsoft does not offer very much Windows API level functionality for reading or writing BMP/DIB files. In the old days all that was there was OleLoadPicturePath and friends, plus reusing the web browser if you liked to do in very inefficient, complex and weird ways, plus some horrid code presented in the documentation. Then came GDI+, which, although far from perfect, simplified a lot. And nowadays it’s no problem except when programming purely at the API level, where a class such as the one I linked to above comes in very handy.
DIB is Device Independent Bitmap. More details on MSDN and Wikipedia. I expect that what was being referred to.
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.
How can I use zlib library to decompress a PNG file? I need to read a PNG file using a C under gcc compiler.
Why not use libpng? The PNG file format is fairly simple, but there are many different possible variations and encoding methods and it can be fairly tedious to ensure you cover all of the cases. Something like libpng handles all the conversion and stuff for you automatically.
I've code once a basic Java library for reading/writing PNG files: http://code.google.com/p/pngj/
It does not support palleted images but apart from that[Updated: it supports all PNG variants now] it's fairly complete, simple and the code has no external dependencies (i.e. it only uses the standard JSE API, which includes zip decompression). And the code is available. I guess you could port it to C with not much effort.
If this is a homework assignment and you really are only restricted to the standard C library, you to be looking at the official PNG file format specification: http://www.w3.org/TR/PNG/. However, are you sure you really need to be decoding the PNG file? If all you need to do is display it somehow, you're headed on the wrong path.
It will be rather complex and time consuming to write a decoder for any general PNG file, but not too bad for simple ones. In fact, because the PNG format allows for pieces of it to be compressed, to do it with only standard C libraries would require you to implement gzip decompress (a reasonable homework assignment for a mid-level undergrad course, but my guess is that you would have spent a lot of discussing compression algoirthms before this was assigned to you)
However, it isn't terribly difficult if you restrict yourself to non-compressed, non-interlaced PNG files. I wrote a decoder once in Python that handled only the easy cases in a couple of hours, so I'm sure it'll be doable in C.
You should probably read up on how a binary file-format works and use a hex-editor instead of a text-editor to look at the files. Generally you should use libpng to handle png-files as stated earlier but if you want to decode it yourself you have alot of reading to do.
I recommend reading this http://www.libpng.org/pub/png/book/chapter13.html