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.
Related
I'm encoding images as video using FFmpeg using custom C code rather than linux commands because I am developing the code for an embedded system.
I am currently following through the first dranger tutorial and the code provided in the following question.
How to encode a video from several images generated in a C++ program without writing the separate frame images to disk?
I have found some "less abstract" code in the following github location.
https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/encode_video.c
And I plan to use it as well.
My end goal is simply to save video on an embedded system using embedded C source code, and I am coming up the curve too slowly. So in summary my question is, Does it seem like I am following the correct path here? I know that my system does not come with hardware for video codec conversion, which means I need to do it with software, but I am unsure if FFmpeg is even a feasible option for embedded work because I am yet to compile.
The biggest red flag for me thus far is that FFmpeg uses dynamic memory allocation. I am unfamiliar with how to assess the amount of dynamic memory that it uses. This is very important information to me, and if anyone is familiar with the amount of memory used or how to assess it before compiling, I would greatly appreciate the input.
After further research, it seems to me that encoding video is often a hardware intensive task that can use multiple processors and mega-gigbyte sizes of RAM. In order to avoid this I am performing a minimal amount of compression by utilizing the AVI format.
I have found that FFmpeg can't readily be utilized for raw-metal embedded systems because the initial "make" of the library sets up configuration settings specific to the computer compiling, which conflicts with the need to cross compile. I can see that there are cross compilation flags available, but I have not found any documentation describing how to use them. Either way I want to avoid big heaps and multi-threading, so I moved on.
I decided to look for more basic source code elsewhere. mikekohn.net/file_formats/libkohn_avi.php Is a great resource for very basic encoding without any complicated library dependencies or multi-threading. I am yet to implement, so no guarantees, but best of luck. This is actually one of the only understandable encoding source codes that I have found for image to video applications, other than https://www.jonolick.com/home/mpeg-video-writer. However, Jon Olick's source code uses lossy encoding and a minimum framerate (inherent to MPEG), both of which I am trying to avoid.
I have an external function from an opencv dll, cvCreateFileCapture, that should take the path as an input and return a structure.
CV_IMPL CvCapture * cvCreateFileCapture (const char * filename)
I created a vs2010 project for testing purposes from where i call this function with a valid file path and get the structure i was supposed to get returned.
When I call this function from a different program (I'm using labVIEW) I jump into the same function with the same input but it returns 0.
Does anyone have an idea why it works 1 way but not the other?
The C call is CvCapture* p = cvCreateFileCapture("C:/Users/****/Downloads/Disturbedloc.avi");
the labview call looks like this:
Load time debugging
If the library call works in one environment but not another, then there's a difference in the environment. There are two main approaches:
Use depends.exe to make sure that opencv has the correct linkage. Perhaps Visual Studio is inspecting opencv for other libraries (like FFMPEG or GStreamer) and adding extra loader instructions to fetch those binaries on launch. LabVIEW, on the other hand, will do a pure dynamic load, and if the library doesn't correctly advertise its dependencies, then those libraries won't be loaded and you'll get a NULL pointer.
Attach Visual Studio to LabVIEW before your VI makes the first call into opencv then watch the Modules window to see if the support libraries are resident in memory. Comparing against your working Visual Studio program would show if any are missing.
Loading missing libraries by force
That run-time linking doesn't work in opencv is a bug in their project. You should report that to them.
You have two workarounds:
Fix the bug, build opencv yourself, and redistribute it with your application.
Call dummy entry points in each dependency to prompt LabVIEW to bring them into the process. Then start calling into opencv.
Once it's working
Since your opencv dll returns a pointer to a struct, you have two options:
Wrap and adapt the opencv library in another C/C++ library so that the inputs/outputs are simpler data types, like numerics.
Use a cluster and some specific Call Library Function node configuration so that LabVIEW can understand the memory layout of the opencv types. NI has a some good documents describing how LabVIEW interfaces with external libraries, but start here: Calling C/C++ DLLs from LabVIEW.
I've just tried and it is working for me.
Here is the front panel:
And the block diagram:
I'm using Labview 2014 and OpenCV 3.0.
I had problems (i.e. 0 returned) with more complex Paths (including spaces, etc.)
I have a library stack that is not going to change, and an firmware that is going to use only this stack. Firmware will change alot along the way. I don't want to every time release the whole image(including library stack) because of limited memory and resources issue(This is an embedded application not a desktop or server).
I just want to release the application image and that automatically be able to use the library image. I am not sure how to do it. I know in Windows for example this is handled by dll's. But this is an embedded application and has no OS. Binary images loads to memory and processor is going to execute it.
Any experience/suggestions?
Toolchain: IAR 8051
This depends quite a bit on your tool-chain. Here's a possible high-view approach.
Compile your library into an executable image, setting your linker to use a particular portion of your flash memory space. You'll probably need a fake/stub entry function for the linker to be happy.
Once that is done, find all of the addresses of the symbols used by the library and instruct your linker as to those symbol locations when building your normal program, and do not instruct the link process to use the intermediary library objects when linking. Also instruct the linker to place the code into the section of flash that is update-able.
What you will then have is an image for the library, and the ability to build new versions of the main program image using at library.
This could probably be scripted if your linker output format is an unstripped elf (prior to converting to a binary for burning on the flash), and if your linker can accept a plain text file for instructions (both are true if you are using the gnu toolchains). I'd recommend scripting it for your sanity unless the library has very few externally visible functions and variables in it.
I do have to agree with some of the commentors; unless transferring the library is very hard, you should just build a single simple image that includes the library and push the whole thing. You might say the library will never change now, but inevitably something will come up that requires a change to the library code, and if you change the library and cannot keep the symbols in exactly the same spot, all of your application images will not be able to work with the new library. This is a recipe for a nightmare when dealing with compatible software (firmware) updates.
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.
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.