I want to create a 2-D pulse in Octave. It will consist of
a box in the middle with value 1.0 and 0.0 outside. The size of the 2-D array is 512. How can I do this in Octave?
Given the width and height of this box stored in width and height, and assuming that they are both odd for symmetry, it's very simply:
row_half = floor(height/2);
col_half = floor(width/2);
pul = zeros(512,512);
pul(256-row_half:256+row_half, 256-col_half:256+col_half) = 1;
The first two lines of code determine what half the width and height of the defined box is. Next, we use the middle (256,256) and make sure we span from half the width both left and right, and half the height both top and bottom. This fills up the total area of your box and that is done by the indexing on the fourth line and we set these locations to 1.
The output 2D "pulse" is stored in the variable pul. A pre-condition of the above code is to make sure that your width and height are fully contained within the 512 x 512 grid. If not, Octave will give you an error going out of bounds.
Example
Let's say my width and height were both 101. We get this pulse, if we did imagesc(pul);
Related
I have a dataset that provides bounding box coordinates in the following format.
height- 84 width- 81 x - 343 y - 510. Now, I want to normalize these values (0-1) to train them using the yolov5 model. I have looked online and found that I can normalize these values in 2 ways. Way 1:
Normalized(Xmin) = (Xmin+w/2)/Image_Width
Normalized(Ymin) = (Ymin+h/2)/Image_Height
Normalized(w) = w/Image_Width
Normalized(h) = h/Image_Height
Way 2: divide x_center and width by image width, and y_center and height by image height.
Now, I am not sure which way I should follow to normalize the values in the given dataset. Can anyone suggest me any solution? Also, the size of the given images in my dataset is 1024 x 1024. Now, if I convert the images in 512 x 512 size, how do I figure the new bounding box coordinates i.e what will be the value of height widht x and y?
First, Yolov5 will resize your images and bounding boxes for you, so you don't have to worry about that. By default, it will resize the longest side to 640px and the shortest side will be resized to a length that preserves the proportion of the original image.
About the normalization [0-1]. Yolov5 expects the center points of the bbox, not the minimum points, so if your box dimensions areheight = 84px and width = 81px and those x and y are the minimum points of the bbox (i'm not sure from your post), your formula works, because you're computing the center points:
Normalized(**x_center**) = (Xmin+w/2)/Image_Width
Normalized(**y_center**) = (Ymin+h/2)/Image_Height
...
About the resizing:
https://github.com/ultralytics/yolov5/discussions/7126#discussioncomment-2429260
I read the following code:
https://github.com/endernewton/tf-faster-rcnn/blob/a3279943cbe6b880be34b53329a4fe3f971c2c37/lib/model/config.py#L63
600 is the pixel size of an image's shortest side, and 1000 is the max pixel size of the longest side of a scaled input image.
Could anybody explain this? and how to determine these sizes? Shall we change these sizes?
These are used in prep_im_for_blob function in here. Where target_size is __C.TRAIN.SCALES = (600,), and max_size is __C.TRAIN.MAX_SIZE = 1000. What it does is scales the image so that the minimum size of the resized image is equal to __C.TRAIN.SCALES. However if the resulting image becomes bigger than __C.TRAIN.MAX_SIZE it scales so that maximum size of resized image is equal to __C.TRAIN.MAX_SIZE. If your input image typically falls within 600~1000 pixels in range, you don't need to change these values.
I'm wondering why flash does not support exact value of box sizing.
When I try to set dimensions of a box with "850.54" of width and "1624.71" of height,
The real box size's set to "850.50" of width and "1624.70" of height by automatically.
I lost my decimal points(float) value in my box.
What happened to me?
Width and height are internally measures in 1/20ths of a pixel, so reading width will return a value that's a multiple of 0.05. The solution is not to use width to store values with precision.
I'm writing a script to output things to a window comprising a Tkhtml widget and a text widget displayed above each other in a ttk::panedwindow. Both widgets are scrollable both vertically and horizontally. There's also a button allowing the user to clear the text widget.
I'm doing some of the development on a laptop running Ubuntu. The window manager allows for four desktop workspaces in a 2x2 array, and when the GUI is first displayed, the bottom fifth or so bleeds from the workspace I'm using into the one below. It's irritating to have to muck around resizing the window to make it short enough to fit onto the screen so I want to resize it.
(I think) I know approximately how to do this, i.e bind to an appropriate event so that I can run a script when the window is first displayed. (Reset the binding from within the script so that it only fires once.) I believed that the "appropriate event" was <Map>, but when the window was first mapped, the two widgets had zero height (as reported by [winfo height]). I tried binding to <Expose> and this seems to work, ([winfo height] returns sensible numbers,) so:
Question 1: Which event should I bind to?
When the binding fires, [wm geometry] reports the geometry as 815x1029+49+24, [winfo height] reports the two heights of the two widgets as 600 and 366, and [wm screenheight] returns a height of 800. I know there are various other bits and pieces in the GUI so I'm not surprised that there are 63 pixels unaccounted for in the initial layout. I assume that I need the same amount of space after resizing, so I should request a geometry of 815x737+49+24, but when I do, a sliver (approximately the lower horizontal scrollbar) still bleeds onto the next workspace.
By mucking around manually, I know that when everything fits nicely onto the screen the geometry should be 815x717+49+24, so I've added a fudge factor of 20 to the amount of space I allow for the "other bits and pieces of the GUI". This works fine but seems a little inelegant (massive British understatement :-) ), so:
Question 2: What have I missed, requiring use of a fudge factor?
I'm using Tk 8.6.1 on Ubuntu 12.04.5 LTS. I'm using version 0.9.7.12 of the Compiz window manager.
Update
It struck me that I ought to find the height of the various panes, rather than the Tkhtml and text widgets as that would account for the scrollbars and the "Clear" button. The pane heights are 615 and 409 initially, but this just means that I have to increase my fudge factor from 20 to 78 to get the request height to my desired value of 717. Is there any way to predict what height to request for the toplevel containing my paned window in order to get that toplevel to fill the screen?
I recommend binding to <Map>. I would wait for all of: the paned window, the main tkhtml window, the text window and the scrollbars to be mapped before trying to adjust heights.
For Linux, the [winfo screenheight .] does not know about any panels that are configured, so you have to subtract those. You can get the actual screenheight available by creating a window, doing a wm attributes . -zoomed 1, then getting the geometry of the window.
The title bar and borders of the window take up space. The space needed for these can be calculated by comparing the output from [winfo geometry .] and [wm geometry .].
There is also the panedwindow sash height and any margins and padding.
You can calculate the total of these by subtracting the panedwindow heights from [winfo height .].
Here is one method that would always work, however, it is not very attractive, as the user would see the windows flashing as they change size.
Maximize the window (wm attributes . -zoomed 1)
Get the window geometry and parse out the screenheight.
De-maximize the window (wm attributes . -zoomed 0)
Get the window geometry and replace the screenheight
with the maximized screenheight.
Set the window geometry.
Maybe I am wrong, I learn Easeljs for a week only.
The Container has no width and height to set the size.
I have 2 questions:
1. is the size of Container, dynamically change with the child.
2. if question 1 answer is yes, can I add a big bitmap or shape to it, eg. a background image...etc. to control the size of Container?
Consider a container as a group of objects, not a physical container. Containers give you the ability to transform, translate, cache, and otherwise control multiple items as a single item. They do not really have a physical size, except that of their collective children.
There is no width or height mainly due to the cost of calculating the size, especially considering transformations, sub-containers, etc. There may be support added in the future for width/height, but for now its not available.
[UPDATE]: Containers do have bounds, based on the bounds of children (retrieved using container.getBounds() (docs) that have bounds. For example, a Container that has Sprite, Bitmap, Text, objects with manually set bounds, or cached DisplayObjects will report bounds using those children. Shapes do not have auto-calculated bounds currently, so will not contribute to container bounds.
This is a very bad hack, but if you absolutely must fix the size of the container, you can use something like this:
var blank = new createjs.Shape();
var width = 1;
var height = 400;
blank.setBounds(0, 0, width, height);
container.addChild(blank);
This will set the size of container to the blank image and now any background you draw on it will be visible.