I have a 64x64 image and I want to resize it just as I want within my program (make it 32x32 or 86x86 for exemple). How can I do it? I use SDL 1.2 in C.
Related
I have difficulties to understand the icon system in GTK 4 (I work in C language).
In GTK 2 and 3 that was easy to instruct the OS about the icon to use for displaying the apps.
In GTK 4 the set_icon functions have been removed which let us with the theming system.
I understand that, by default, gtk want us to follow the Freedesktop Icon Theme Specification and so to put the icons during the installation in directories like /usr/local/share/icons/hicolor/ and setting it in the application via function like gtk_window_set_default_icon_name or gtk_window_set_icon_name. But I didn't really manage to make this system work.
Moreover, it remains obscure to me what happens on other systems that are not gnome-based like Windows (or even KDE desktop)...
So, well, I have a few questions that stem from theses previous points :
How the system work on other OS or DE that do not follow the Freedesktop Icon Theme Specification ?
Is this possible to have a very short working example that illustrates how to use, in GTK4, a new application icons that, for example, was just copied in /usr/local/share/icons/hicolor/
And my real question for my use case : is this still possible, by one way or another, to include applications icons in the binary or in the binary directory to have a simple portable application which do not need installations and work on every system ?
(edit : edited to include nielsdg precision)
Ok, I have found a (partial) answer to my second question and third question, sort of.
In fact, it's pretty simple, but I made a few mistakes.
You simply have to have a directory with this structure exactly (I made a mistake in the structure) :
my_ressource_directory/hicolor/apps/48x48/my-icon.png
my_ressource_directory/hicolor/apps/256x256/my-icon.png
my_ressource_directory/hicolor/apps/512x512/my-icon.png
Only the 48x48 size is necessary, there are a lot of other sizes which seems to be : 8x8 16x16 22x22 24x24 32x32 36x36 42x42 44x44 48x48 64x64 72x72 96x96 128x128 150x150 192x192 256x256 310x310 512x512 and "scalable".
I don't know in which context the system use all of them and I don't know if personalised size is possible.
I equally don't know in which context the svg icons in scalable can be used by the system...
In the code, then, you simply have to include a thing like that :
icon_theme = gtk_icon_theme_get_for_display (gdk_display_get_default ());
gtk_icon_theme_add_search_path(icon_theme,path_to_my_ressource_directory);
if(gtk_icon_theme_has_icon(icon_theme,"my-icon")!=1)
{
// manage error
}
gtk_window_set_default_icon_name("my-icon"); // default icon for all windows if nothing is set explicitly if I understand well.
window = gtk_application_window_new (app);
gtk_window_set_title (GTK_WINDOW (window), "Your app");
gtk_window_set_icon_name(GTK_WINDOW (window),"my-icon"); // set explicitly the icon for the min window
And tadaaa; it works :) .
Please also notice that some post seems to say that the call to gtk-update-icon-cache is important to make the system works. This command creates a "icon-theme.cache" file in the directory that is used by GTK to accelerate the opening/processing of icons.
In practice I can't say if this is efficient or really used by GTK but after checking, even without the icon-theme.cache it works. So the call of this command seems not to be mandatory.
That said, it cost nothing to call the command in the Makefile. The exact command is :
gtk-update-icon-cache -f -t my_ressource_directory/
EDIT
The solution is incomplete because the resulting icon is fuzzy in certain context. See this question : Why GTK4 seems to use only 48x48 icons for displaying minimized application in all context?
And the answer, to have the full solution.
Works fine for me (under FedoraCore 35). Needed to have custom icon shown when running exampleapp1 (A trivial application) of GTK 4 doc. https://docs.gtk.org/gtk4/getting_started.html
I'm loading 32 bit RGBA normalmap textures, with a heightmap encoded in the alpha channel, via SDL2 2.0.7 and SDL2_image 2.0.2 on OS X Sierra.
Every pixel in these textures has a non-zero RGB value, encoding a directional normal vector. A directional vector of (0, 0, 0) (i.e. black) is invalid.
And yet, when I load such a texture via SDL2_image, the areas of the texture with an alpha value of 0 also yield RGB values of 0. I think SDL is perhaps pre-multiplying the alpha value for these pixels?
Attached is one of these normalmap textures. You can confirm it is valid by opening the texture in e.g. GIMP and using the color picker on one of the transparent areas. You'll see that, indeed, the transparent areas still have an RGB color that is blue-ish (an encoded normal vector).
And below is a minimal test case illustrating the issue for the attached PNG file:
#include <SDL_image.h>
#include <assert.h>
int main(int argc, char **argv) {
SDL_Surface *s = IMG_Load("green3_2_nm.png");
assert(s);
for (int i = 0; i < s->w * s->h; i++) {
const Uint32 *in = (Uint32 *) (s->pixels + i * s->format->BytesPerPixel);
SDL_Color color;
SDL_GetRGBA(*in, s->format, &color.r, &color.g, &color.b, &color.a);
assert(color.r || color.g || color.b);
}
SDL_FreeSurface(s);
return 0;
}
I'm compiling this test case with gcc $(pkg-config --cflags --libs sdl2_image) test.c
The assertion on line 15 will fail several rows into the image -- i.e. exactly where the alpha value drops to 0.
I have tried both TGA and PNG image formats, but SDL does the same thing to both of them.
Is this a bug in SDL, or am I missing something? I'm curious if folks see this same issue on other platforms as well.
===
Answer: Core Graphics, the default image loading backend for SDL2_image on Apple OS X, does indeed pre-multiply alpha -- always. The solution is to recompile SDL2_image without Core Graphics support, and instead enable libpng, libjpeg, and any other image codecs you require:
./configure \
--disable-imageio \
--disable-png-shared \
--disable-tif-shared \
--disable-jpg-shared \
--disable-webp-shared
On my system, I had to disable Core Graphics (imageio) and also the shared library loading of the other codecs, as you can see. This produced a fat SDL2_image.so that was statically linked against libpng, libjpg, etc.. but worked as expected.
SDL_image is a wrapper around platform-specific image loading code, rather than using the same image loader on all platforms.
Linux: LibPNG, LibJPEG
macOS, iOS: Core Graphics
Windows: WinCodec
This has the advantage of reducing the size of SDL_image, since it doesn't have to ship with any image decoding code, and can instead link dynamically against something that's likely installed on your system already. However, on macOS and iOS, Core Graphics does not support non-premultiplied alpha, so SDL_image has to reverse it.
See: mac-opengl - Re: kCGImageAlphaFirst not implemented (Was: (no subject)) from May 2007 (from the Wayback machine):
Honestly, I wouldn't expect CGBitmapContextCreate() to support non- premultiplied alpha any time soon.
...
I'm not sure if using ImageIO + CoreGraphics was ever really targetted at being used for an image loading scheme for OpenGL applications.
This behavior was discovered in LibSDL bug #838 - OSX SDL darkens colours proportional to increase in alpha and a workaround was introduced in SDL_image changeset 240.
You can see that the workaround merely un-premultiplies the alpha, this is a horribly lossy process.
To address this, you could build your own version of SDL_image on macOS that uses LibPNG. This should be possible just through configuration, you should not have to make any changes to the SDL_image code itself. To do this, use the --disable-imageio option. SDL_image ships with its own copy of the LibPNG code, so you should not need to install LibPNG in order to get this to work.
Quick question, is there a way to show an image(ex. bmp) from file using C? It's not in graphics.h apparently, and I can't use Allegro because it does not support Borland(or so I've read). I need to use the very old compiler for a school project. I would like to ask if anyone had any experience of doing this using other libraries? If yes, which library was it? Thanks a lot.
I hope you have visual (windows) borland like Borland C++ builder 3++ or turbo C++ not the MS DOS one. in that case it is quite easy because you can use bitmap which is part of VCL so no additional include is needed.
here you can find some hints on rendering under borland
now how to visualize picture from file to your window:
// this will create and load your bitmap
Graphics::TBitmap *bmp=new Graphics::TBitmap;
bmp->LoadFromFile("image.bmp");
bmp->HandleType=bmDIB;
bmp->PixelFormat=pf32bit;
// on paint you can draw your image to form,paintbox,another bitmap or whatever...
Form1->Canvas->Draw(0,0,bmp); // also you can use stretch draw or copy rectangle GDI functions
// before exiting delete the bmp
delete bmp;
[Notes]
You can also save image by bmp->SaveToFile("out.bmp"); In case you need jpg then add:
#include <jpeg.hpp>
TJPEGImage *jpg=new TJPEGImage;
jpg->LoadFromFile("image.jpg");
bmp->Assign(jpg);
delete jpg;
this will load jpg to your bmp also you can save jpg as well in the same way. Beware older Borlands has a bug in TJPEGImage and will crash if the jpg resolution is too big**
I'm using libjpeg-turbo to open jpeg pictures in a C program. Pictures in RGB colorspace are detected as YCbCr. Grayscale and CMYK colorspaces are correctly detected.
I though about a problem related to 2 different versions of jpeglib.h (where J_COLOR_SPACE enum is defined) or libjpeg conflicting with libjpeg-turbo, but there is just one jpeglib.h on the environment I'm using for compiling libjpeg-turbo and my program.
Any idea much appreciated.
there is a command to move a window (probably showing image captured from camera) in OpenCV which is cvMoveWindow. But, is there a command in OpenCV which allows window rotation?
if OpenCV does not have one, is there any library doing so?
I've googled for several days but could not find one
You can't rotate the window itself since OpenCV provides no feature for this task, but you can rotate the image instead.
A solution that might be faster than warpAffine is: call cvTranspose() followed by cvFlip() to rotate the image 90 degrees.
The following code uses the C++ interface of OpencV to demonstrate this operation:
cv::Mat src = imread("image.png", 1);
cv::Mat dst;
cv::transpose(src, dst);
cv::flip(dst, dst, 1);
There is no command in opencv to rotate a window. However you can rotate the image and display it in a window. I think it will be hard to find any library which can do this because it has something to do with OS.
Check this link to do away with image rotation