I want to put a watermark on my video. IS it possible to do with directshow filter.
Want to overlap an image on video like channel logo. so that image will be fixed when video is playing.
Please provide some valuable help or samples (VC++)
I've done this before. You have two options.
Use VMR-7 or VMR-9's mixer capabilities. I guarantee you this will look real ugly, because VMR filters can't do alpha blending at all. Your watermark will have rough edges.
Implement a filter class that derives from CTransInPlaceFilter.
You implement the following methods:
CheckMediaType (accept all RGB formats)
SetMediaType (accept all RGB formats)
Transform (this is where you do the overlay)
In your filter's constructor (or on some other method that gets called before the graph runs), load your watermark from file or resources. Save the bitmap bits of the image file into a buffer.
When Transform gets called, crack open the IMediaSample that's passed in, access its buffer, and have a double-nested-for loop to copy each pixel of the watermark onto the buffer of the image.
One problem with all of this is that your input source may not be native RGB. Most webcams for example are YUV sources (or worse, MJPG). By constraining your filter to only accept RGB types will force the DShow color converter filters to load. As such, extra latency may get added to your graph. As for alpha blending (if you want it), you are on your own here - the source buffer you are blitting on top of will likely be RGB24 with no alpha channel.
Related
I'm currently developing new file format, it's a video with custom color representation. Every color is a single byte; there's a constant RGBA colors array, every byte of the frame is the index of color in this array. Therefore every pixel in a single byte.
So I'm looking for a way to compress videos with such format. My first idea was is create this video format myself (which unfortunately failed), second idea is H.264, but I don't know if there's any way to use H.264 this way. So is there? Or maybe there's another way to compress such video data? (except gzip, lzma, bzip2, 7zip and so on)
Please, don't close this question. I'll add all asked details if needed.
The best I can suggest for such idea would be to encode it in 4:0:0 (mono) colorspace in lossless mode in H.264. For x264 this would mean options: --input-csp i400 --output-csp i400 --qp 0. But I doubt motion compensation would be good in such palette colorspace.
All other possible values of VkColorSpaceKHR specify a recognised colour space encoding, and I assume that creating a swapchain with those values would mean that the final pixel data submitted by the application to the presentation queue would be transformed, somewhere down the line, into a decoded space, through a known EOTF.
The specification defines VK_COLOR_SPACE_PASS_THROUGH_EXT as follows:
"VK_COLOR_SPACE_PASS_THROUGH_EXT specifies that color components are used 'as is'. This is intended to allow applications to supply data for color spaces not described here."
What would this mean for my application? Let's say (entirely hypothetically) that I was building some fancy spectrum renderer and I was using a custom system for representing colours, and then that would all be transformed into a final RGB format, with just the three channels of intensity values, independent of colour space or any encoding.
Would my image really just be blitted to the screen "as is", as the specification claims? If so, how does the implementation know what to do with the given pixel data? Would it result in every pixel on my display being set to those raw RGB intensities, with no transfer functions being applied?
Thanks, and as always, I do not really know what I'm talking about so please bear with me.
Pass-through means pass it through. In terms of display presentation, the Vulkan implementation is an intermediary between the user and the display engine (ie: the part of the OS that deals with how a window accesses and manipulates the screen). Pass-through means for Vulkan to pass the data through as-is. The user is providing the data in the color space that the display engine expects it to be.
I am making this C++ program that has buttons, button containers, chat boxes, etc., and I want to wrap it around by textures.
I want to generate a smooth edge for all the rectangles I made, and I don't want vertex plotting method to do the work for it, since it consumes more CPU usage and not that looks pretty good, and I don't know if it can work with texture coordinates(i.e. glTexCoord(u, v) with glVertex2f(x, y) w/c should only be 4 since it is a quad)
I use to load textures using SDL_LoadBMP() w/c can load only a format of .bmp.(I'm not that sure because it says only LoadBMP there).
So my questions are:
can a .bmp format handle transparency? if so, how to do it?
can you show me some code samples using SOIL to load image of format .gif or any other formats that can handle image transparency?
can a quad handle an irregular/polygons shape like hexagon or star without drawing its background?
additional question
*how to import a primitive textbox that renders through c++ opengl so I can copy the texts there into clipboard? as for chatting session in my program.
I made my own library that draws the text using GL_POINTS and doesn't look good when resizing the window because the points were spread-out. It takes const char* for the text to avoid #include <*string*> because I want my program to be not dependent on core functions of C++.
So the better solution is to draw it using bitmaps.
Some suggest to draw it using images so I really need the transparency thing because I want it to draw using quad only.
Yes, the bitmap format does support transparency.
It depends on the compression method, the default RGB method supports 24-bit color, but BITFIELDS compression supports 32-bit color (24-bit + alpha channel).
You can read more at http://en.wikipedia.org/wiki/BMP_file_format
I am using it successfully in the Lime project, here is an implementation written in Haxe: https://github.com/openfl/lime/blob/4adb7d638d15612e2542ae3a0ef581a786d21183/src/lime/_internal/format/BMP.hx
This answer only addresses whether a bmp file can handle transparency, and how to load a png file using SOIL, and I think if you look further by inference it shows you how to load a gif file also. According to this wikipedia article, bmp is one file type that supports transparency through an alpha channel. But according to this SO article it doesn't. In my own experience I have not found a way to make bmp transparency work. So theoretically 32bit bmp files are supposed to support transparency, but I doubt it. (Maybe I will eat my words?)
Ok, from the SOIL website, this code tells how to load a png file which handles transparency:
/* load an image file directly as a new OpenGL texture */
GLuint tex_2d = SOIL_load_OGL_texture
(
"img.png"
SOIL_LOAD_AUTO,
SOIL_CREATE_NEW_ID,
SOIL_FLAG_MIPMAPS | SOIL_FLAG_INVERT_Y | SOIL_FLAG_NTSC_SAFE_RGB |
SOIL_FLAG_COMPRESS_TO_DXT
);
BMP transparency is possible in Photoshop, with a 24 bits depth, at least.
It doesn't appear as an option of "imwrite" in Matlab.
In my jpeg file there are few FFDA markers. From which marker my data starts, and how do I know from which marker I decode the file?
The JPEG standard has many options that are not used very often. A typical color image will have 3 color components (Y, Cr, Cb) interleaved in a single scan (one FFDA marker). They can also be stored in any combination in separate scans. A progressive JPEG image encodes multiple scans with more and more detail (AC coefficients) in each successive scan, but the standard allows any combination of color components and coefficients to be mixed in different scans. I have only seen one case of a non-progressive JPEG with separate scans for each color component; it came from an IP camera.
Your JPEG is probably progressive which means you have to decode the data after at least the first FFDA marker, which will bring you an intermediate result.
If this is your first attempt at making a JPEG decoder you should choose another image and try to implement a baseline decoder instead. Progressive images adds a lot of complexity to the problem.
how can I see the color space of my image with openCV ?
I would like to be sure it is RGB, before to convert to another one using cvCvtColor() function
thanks
Unfortunately, OpenCV doesn't provide any sort of indication as to the color space in the IplImage structure, so if you blindly pick up an IplImage from somewhere there is just no way to know how it was encoded. Furthermore, no algorithm can definitively tell you if an image should be interpreted as HSV vs. RGB - it's all just a bunch of bytes to the machine (should this be HSV or RGB?). I recommend you wrap your IplImages in another struct (or even a C++ class with templates!) to help you keep track of this information. If you're really desperate and you're dealing only with a certain type of images (outdoor scenes, offices, faces, etc.) you could try computing some statistics on your images (e.g. build histogram statistics for natural RGB images and some for natural HSV images), and then try to classify your totally unknown image by comparing which color space your image is closer to.
txandi makes an interesting point. OpenCV has a BGR colorspace which is used by default. This is similar to the RGB colorspace except that the B and R channels are physically switched in the image. If the physical channel ordering is important to you, you will need to convert your image with this function: cvCvtColor(defaultBGR, imageRGB, CV_BGR2RGB).
As rcv said, there is no method to programmatically detect the color space by inspecting the three color channels, unless you have a priori knowledge of the image content (e.g., there is a marker in the image whose color is known). If you will be accepting images from unknown sources, you must allow the user to specify the color space of their image. A good default would be to assume RGB.
If you modify any of the pixel colors before display, and you are using a non-OpenCV viewer, you should probably use cvCvtColor(src,dst,CV_BGR2RGB) after you have finished running all of your color filters. If you are using OpenCV for the viewer or will be saving the images out to file, you should make sure they are in BGR color space.
The IplImage struct has a field named colorModel consisting of 4 chars. Unfortunately, OpenCV ignores this field. But you can use this field to keep track of different color models.
I basically split the channels and display each one to figure out the color space of the image I'm using. It may not be the best way, but it works for me.
For detailed explanation, you can refer the below link.
https://dryrungarage.wordpress.com/2018/03/11/image-processing-basics/