This question is about use of evas_object_image_data_set function. Say, I have some pixel array in RGBA format. I make a transformation on it to become ARGB, suitable for Evas Image Object. Next thing I create a window with elm_win_add. Then I create image object with evas_object_image_add(evas_object_evas_get(window)). After that I call to evas_object_image_fill_set, then evas_object_image_size_set. Then I call evas_object_image_data_set and finally I call evas_object_image_data_update_add with approriate region for my image. After all this done I see nothing but black box. Am I doing something wrong?
P.S.: using efl version 1.7.7
Setup the image object as described in the question.
Get a void pointer to the raw image data with evas_object_image_data_get, with EINA_TRUE in argument for_writing.
Modify the data as needed.
Call evas_object_image_data_set with the void pointer as argument.
Related
I want to be able to input an image and get out an Array such as {{55,132,97},{55,125,97},} for an image, 1 Array per pixel
what I need help with is how would I go about this? I would prefer lua but I could also use C# and python
also what libraries or whatever they are called would I need?
I am trying to find out how i can read back data from fragment shader to application but specifically fragment shader in built variables
Here is an example of what i am trying to do, in this fragment shader below i am trying to read back to the application the fragment shader variable gl_FragCoord.y
#version 330
out vec4 outputColor;
void main()
{
gl_FragCoord.y??????
outputColor = vec4(0.2f, 0.2f, 0.2f, 1.0f);
}
How would i pass this value back to the application, is it done through uniform variable? buffer object? or some other way? or can it be done at all?
i am specifically trying to get the gl_FragCoord.y value for each time the fragment shader runs
Okay i have found a few ways to do this in case anybody needs to know and since nobody provided the answer i searched for it myself and found it(besides the one that was provided by the person who commented)
First way was mentioned by one of the commentators to the question, which is to create a framebuffer/renderbuffer object as an image, write data to it directly from the shader and read back the data as an image or to read back in general from framebuffer using glReadPixels() to currently bound framebuffer object
Second way is to create buffer object/array in fragment shader to write from the variable mentioned above and to map the buffer data using glMapBuffer*() and get a pointer to the buffer and read back the value in application
Another was to also create a buffer object and then use glGetBufferSubData to read back everything that is written to it from shader (obviously you declare the buffer object as read/write also)
And finally you can use image units texture data to also store from shader to these buffer objects and read back from them , if anyone needs exact details leave a comment and i will provide
See it IS possible and more then one way to do it, however it wont be run for each time the fragment shader runs, but rather the fragment shader will store the information to buffer object and those aforementioned and read back to application after execution , however the result will still be the same, in that the gl_FragCoord.y for each fragment will be stored and accessed as a chunk of memory
We create a matlab gui for registration.In that form we have to see each images from an array on the buttons clicks. we need to be implement two pushbuttons ie 'next' and 'previous'. when we click previous we have to see previous image on the axis and vice versa. plz help us. Thank you in advance.
Well, the steps are pretty straightforward:
In your GUI's OpeningFcn you should add code to load the images from the folder:
create a cell array filed in handles, e.g. handles.img_store;
load images one by one in handles.img_store{:} using imread();
create a current image index, e.g. handles.img_index, and initialize it to 1;
display the current image using display_current_image() function—see 4.;
Write the callback for the pushbutton "Next" to increment handles.img_index, reset it to previous value if it goes out of bounds of handles.img_store, then call display_current_image()—see 4.;
Write the callback for the pushbutton "Previous" to decrement handles.img_index, reset it to previous value if it goes out of bounds of handles.img_store, then call display_current_image() function—see 4.;
Create a function, e.g. display_current_image() that will take handles as argument and, using the image() function, displays the image with the index handles.img_index in the cell array handles.img_store
I will not write code, not until you try to write some code first. :-)
I am trying to take screenshots in the most efficient way. I thing using a FrameBuffer is the most efficient way of taking screenshots because i can process the data in different thread than rendering thread.
How can i get the information from FrameBUffer and transfer it to a file?
FrameBuffer m_fbo;
render(){
m_fbo = new FrameBuffer(Format.RGB565, (int)(w * m_fboScaler), (int)(h * m_fboScaler), false);
m_fboRegion = new TextureRegion(m_fbo.getColorBufferTexture());
m_fboRegion.flip(false, true);
m_fbo.begin();
...rendering...
m_fbo.end();
writeTextureRegionToFile(); - i need some lines of code for the implementation of this method
}
The FrameBuffer contents reside in memory managed by OpenGL, so you will (as far as I understand things) still need to fetch those bytes using OpenGL APIs on the render thread. Specifically, you want the ScreenUtils class
to get a byte[] containing the RGBA8888 contents of your FrameBuffer.
Once you get the raw bytes, you can do any compression/conversion/output on a different thread, of course. There is a forum post that has a quick and dirty PNG writer. The Libgdx-specific (?) CIM format is also an option (see the PixmapIO class), but you'll have to convert the bytes into a Pixmap first.
I know one can use SetWindowLongPtr + GWLP_USERDATA to store a pointer which points to some data.
But could one store the data directly, for example "a handle", "a bool, an "int" or other larger data.
From http://msdn.microsoft.com/zh-tw/library/windows/desktop/ms644898%28v=vs.85%29.aspx, it says:
Sets new extra information that is private to the application, such as handles or pointers.
, so I guess to store a handle is OK. I also used this method to store an RGB value without problem.
But I don't know if this is a good idea to do things like this. And can we store other data which is large (for example, a structure)?
p.s: The motivation of this question is: When I create a dialog window, I want to store data for each of its controls. Of course I can use static variables in the window procedure and pass pointer (to them) to SetWindowLongPtr function. But this is not "perfect" in theory, because when the dialog window is closed, I don't need these data anymore. Of course, in practice, the data I need to use is very small, and I should not care about the usage of memory. But I still like to know if there is a better way.
You only need one pointer to store anything you want. Declare a struct with the data you want to store. Allocate it before the CreateWindowEx() call and pass the pointer as the last argument. You get it back in your window procedure for the WM_CREATE message, CREATESTRUCT.lpCreateParams field. Now call SetWindowsLongPtr to store that pointer.
Anytime you need it back, use GetWindowlongPtr to recover the pointer to the struct. You'll need to cleanup again, use the WM_NCDESTROY message to release the pointer.
Note that this is a standard technique used in C++ class libraries that wrap the winapi. Do consider using one of them instead of spinning this yourself.
The SetWindowLongPtr function can store a piece of data which has the same size as LONG_PTR (most likely 32bit or 64bit). If your data can be stored in that size, you're fine. I.e. a bool would be fine, so would most handles (since handles tend to be pointers, too).
A typical RGB value would work as well since it's stored as three bytes (one byte per color component) or four bytes (an extra byte for the alpha channel).
If you need more space than this, you should allocate a structure somewhere else and store a pointer to that structure.