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.
Related
I'm writing a DirectX 11 OpenXR app. OpenXR creates the DX11 swapchain with a format of DXGI_FORMAT_R8G8B8A8_UNORM_SRGB (the device doesn't support non sRGB formats).
The problem I have is that I need to render a video texture. And IMFMediaEngine::TransferVideoFrame() won't work unless the texture is in a non sRGB format like DXGI_FORMAT_R8G8B8A8_UNORM. So if I use the UNORM texture format for the video frame it works.
The problem is that in the headset the colors of the texture are off. They are too bright. I suspect converting them from sRGB->Linear inside the pixel shader would make them look like they are supposed to. But I'm not sure what is happening.
I'm a bit confused about how to handle this situation where the swapchain (sRGB) is created by OpenXR and it does the presenting but I have to sample from UNORM textures.
Can anyone provide guidance?
I have a PNG-Image with alpha values and need to reduce the amount of colors. I need to have no more than 256 colors for all the colors in the image and so far everything I tried (from paint shop to leptonica, etc...) strips the image of the alpha channel and makes it unusable. Is there anything out there that does what I want ?
Edit: I do not want to use a 8-bit palette. I just need to reduce the numbers of color so that my own program can process the image.
Have you tried ImageMagick?
http://www.imagemagick.org/script/index.php
8-bit PNGs with alpha transparency will only render alpha on newer webbrowsers.
Here are some tools and website that does the conversion:
free pngquant
Adobe Fireworks
and website: http://www.8bitalpha.com/
Also, see similar question
The problem you describe is inherent in the PNG format. See the entry at Wikipedia and notice there's no entry in the color options table for Indexed & alpha. There's an ability to add an alpha value to each of the 256 colors, but typically only one palette entry will be made fully transparent and the rest will be fully opaque.
Paint Shop Pro has a couple of options for blending or simulating partial transparency in a paletted PNG - I know because I wrote it.
i am trying to read an image with ITK and display with VTK.
But there is a problem that has been haunting me for quite some time.
I read the images using the classes itkGDCMImageIO and itkImageSeriesReader.
After reading, i can do two different things:
1.
I can convert the ITK image to vtkImageData using itkImageToVTKImageFilter and the use vtkImageReslicer to get all three axes. Then, i use the classes vtkImageMapper, vtkActor2D, vtkRenderer and QVTKWidget to display the image.
In this case, when i display the images, there are several problems with colors. Some of them are shown very bright, others are so dark you can barely see them.
2.
The second scenario is the registration pipeline. Here, i read the image as before, then use the classes shown in the ITK Software Guide chapter about registration. Then i resample the image and use the itkImageSeriesWriter.
And that's when the problem appears. After writing the image to a file, i compare this new image with the image i used as input in the XMedcon software. If the image i wrote ahs been shown too bright in my software, there no changes when i compare both of them in XMedcon. Otherwise, if the image was too dark in my software, it appears all messed up in XMedcon.
I noticed, when comparing both images (the original and the new one) that, in both cases, there are changes in modality, pixel dimensions and glmax.
I suppose the problem is with the glmax, as the major changes occur with the darker images.
I really don't know what to do. Does this have something to do with color level/window? The most strange thing is that all the images are very similar, with identical tags and only some of them display errors when shown/written.
I'm not familiar with the particulars of VTK/ITK specifically, but it sounds to me like the problem is more general than that. Medical images have a high dynamic range and often the images will appear very dark or very bright if the window isn't set to some appropriate range. The DICOM tags Window Center (0028, 1050) and Window Width (0028, 1051) will include some default window settings that were selected by the modality. Usually these values are reasonable, but not always. See part 3 of the DICOM standard (11_03pu.pdf is the filename) section C.11.2.1.2 for details on how raw image pixels are scaled for display. The general idea is that you'll need to apply a linear scaling to the images to get appropriate pixel values for display.
What pixel types do you use? In most cases, it's simpler to use a floating point type while using ITK, but raw medical images are often in short, so that could be your problem.
You should also write the image to the disk after each step (in MHD format, for example), and inspect it with a viewer that's known to work properly, such as vv (http://www.creatis.insa-lyon.fr/rio/vv). You could also post them here as well as your code for further review.
Good luck!
For what you describe as your first issue:
I can convert the ITK image to vtkImageData using itkImageToVTKImageFilter and the use vtkImageReslicer to get all three axes. Then, i use the classes vtkImageMapper, vtkActor2D, vtkRenderer and QVTKWidget to display the image.
In this case, when i display the images, there are several problems with colors. Some of them are shown very bright, others are so dark you can barely see them.
I suggest the following: Check your window/level in VTK, they probably aren't adequate to your images. If they are abdominal tomographies window = 350 level 50 should be a nice color level.
Is it possible to use color pallettes in openGL ES 1.1?
I'm currently developing a game which has player sprites, and the player sprites need to be able to be changed to different teams' colors. For example, changing the shirts' colors but not the face colors, which rules out simple hue rotation.
Is this possible, or will this have to be implemented manually (modifying the texture data directly)?
Keep in mind that anything other than non-mipmapped GL_NEAREST will blend between palette indices. I ended up expanding paletted textures in my decompression method before uploading them as BGRA32. (GLES 2.0)
It's not a hardware feature of the MBX but a quick check of gl.h for ES 1.x from the iPhone SDK reveals that GL_PALETTE4_RGB8_OES, GL_PALETTE8_RGBA8_OES and a bunch of others are available as one of the constants to pass to glCompressedTexImage2D, as per the man page here. So you can pass textures with palettes to that, but I'll bet anything that the driver will just turn them into RGB textures on the CPU and then upload them to the GPU. I don't believe Apple support those types of compressed texture for any reason other than that they're part of the ES 1.x spec.
On ES 2.x you're free to do whatever you want. You could easily upload the palette as one texture (with, say, the pixel at (x, 0) being the colour for palette index x) and the paletted texture as another. You'll then utilise two texture units to do the job that one probably could do when plotting fragments, so use your own judgment as to whether you can afford that.
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/