My Mac's hard drive failed and I had a replacement drive installed. All R related programs were installed as if my computer was brand new.
Prior to the failure, if I inserted a graphic into a RMardown document, the rendered size of the graphic was consistent and directly related to the actual size of the screen shot image.
Now, relatively small screen captures render large in size. I attempt to add a pic to show the problem. Not certain what I need to do to fix this situation. This is a book that will soon go to publication. As is stands, the publication is delayed unless I am able to somehow return to 'normal.' A Time Machine restore is out of the question for reasons I cannot go into, even though that was attempted. Several Apple senior advisors with whom I spoke do not recommend the 'Time Machine' restore option. As such, I seek another solution - hopefully not individually resizing 1,200+ text images. pic of mis-sizing
Related
for my game project I want to include a "camera mode".
This means, that on a press of a button the current camera view gets saved in an in-game gallery.
After some search, I only found ways to save a screenshot on the disk (BP for saving Screenshot, semi functional)
, but I want the picture to be still available in my game, maybe as a texture or in a struct. So I can later use it, well in an in-world picture frame or newspaper.
I did try SceneCaptureComponent2D, but I never got that one really working and searching online got no satisfactory results.
By the way, I'm fine with C++, I'm just building my current prototype with BP for faster testing and altering.
I hope you can help me.
I would have commented on your question, but I do not have enough reputation to do so, because this answer I am providing you is more a hint on how you could do it rather than a straight solution for your problem.
Check out this repository on how to capture images with C++ during a running application which is actually meant for recording data.
Here at work we have plenty of experience developing image processing applications for the TI DSP platform using an old version of code composer (CC 3.3). We are transitioning to the ARM platform using Eclipse (flavored and distributed by Xilinx).
In the old code composer, a feature we used a lot was to look was an IDE widget that could display a certain area of memory as a bitmap image. It had a properties grid where you would define things like size, pixel format and stride orientation to properly interpret the blob of memory as a picture. The tool also had some nice features like zooming, a grayscale counter, line profile, histogram and etc.
Is there something similar for eclipse? If not, how difficult would it be to create one? I mean, how difficult it is to create a barebones plugin for eclipse that draws information from a location of memory in a jtag interface?
Gdb can call python script. If gdb is used for debugging then please use this. You can use OpenCV or PIL or any image library to show the image.
Updated on 2 Apr 2014:
Let 'data' be the pointer to the image.
Inside gdb run "python data = gdb.parse_and_eval("data")". This will give access to inferior's memory pointed by data.
e.g., "python print(data[35])" will show the 35th element of 'data'.
As the image data can be read in python, it can be displayed or analysed.
Following links will help in getting things done:
http://www.cinsk.org/wiki/Debugging_with_GDB:_How_to_create_GDB_Commands_in_Python
https://sourceware.org/gdb/onlinedocs/gdb/Python.html#Python
Note: Please ignore the comment I added. Hit enter key before writing the actual info.
Hope this helps.
Eclipse has no such feature; personally, I work in a similar environment (image processing on a DaVinci architecture + Eclipse IDE). Writing a Eclipse plugin is not a overly complicated task - there a loads of tutorials(like this one). But maintaining it may become one. We have referece Code in QT so we don't need such features. but if you really want something similar I guess you can always do a memdump in a binary file and interpret hat as an image. As long as the format isn't anything spacial (e.g. you are dumping jpeg format) it should be fine.
That is a great idea for static objects but what if your memory is created temporarily on the heap or on the stack? Is isn’t it easier in dynamic environments (using openCV) just to put a three lines of code whenever you need to see some buf content as an image and use Qt to do image scaling and histogramming?
Mat I(h, w, CV_8U, buf);
imshow(“winname”, buf);
waitKey(-1);
I heard that the latest version of openCV highgui module has the options you talked about but I personally see only very limited use of it in a dynamic programming environment. And yet I visualize data all the time. Moreover, I like to interact with my images, for example, rotate them in 3D, click and get values, or to mark a certain segment. I guess it will be hard to do this with a specific plug-ins.
I just found this; haven't tried it yet:
https://github.com/cuekoo/GDB-ImageWatch
If eclipse is calling gdb, maybe there is a way...
Just to start off, thanks for making ZXing freely available.
I have been working in the barcode field since '98, and have a fair bit of experience decoding barcodes from images.
I consult now, and one of my products in a program that tests barcode decoders. This is an extremely CPU intensive test, with literally millions of images being tested per symbology. I test with different amounts of blur, different angles, different brightness and contrast, different sizes (pixels per module), curvature, perspective distortion, ripple, varying illumination ... the whole shebang. I am testing the C++ implementation on a Linux machine.
I have come across a few issues that may interest the developers:
1) Aztec has a bug that crashes sometimes. In AztecDecoder.cpp, in Decoder::correctBits, sometimes numECCCodewords takes on a negative value. Bad things happen after that. I was able to patch with a simple test and a "throw" to complete my testing.
2) Aztec has a huge memory leak. In no time at all, my program is taking over one GB of RAM, and the number steadily increases over time. It gets bad enough that the OS starts bogging down and reboots after a while. I don't seem to have this problem with other symbologies.
3) You don't seem to make the version number available in the code. I know, you should keep track of which version you downloaded. Life isn't always like that, sometimes you inherit code, and you had nothing to do with downloading it. Even a simple #define in a header file would suffice. I like to display the version number of the decoder in my test program. I get this value directly from the decoder so that if I upgrade decoders, the reported version automatically changes. Just a nice thing to have.
4) Aztec appears to be extremely weak. I know, it's only alpha, but it hardly ever decodes. I am not meaning to pick on aztec, but it gave me the most issues.
5) The entire UPC family misdecodes (returns incorrect information for a correctly encoded barcode) extremely frequently. You may want to put some protection in there. ITF does a fair bit as well. All well-known weaknesses.
6) Aztec misdecodes as well. This should pretty well never happen with a Reed-Solomon error correction system. I haven't taken the time to look into this yet.
Those were the major problems, now for comments:
1) There is no support for barcodes at angles (omnidirectional decoding). This is supported by all major commercial packages.
2) Decoding appears to be weak overall in terms of handling blur, and low pixels per module. Yes, I realize that it is a free package, but just stating the weak points.
That's about all that I found now. I'll update when I have more information.
I am writing a windows program (no mfc) and need to output a status line to the operator every few seconds or so. I tried using rich text boxes but after so many hours it seems to hang up. Does anybody have an suggestions on what I can use instead?
People mentioned that my buffers might have been exhausted. I thought I had planned for that. After I had about 1000 lines displayed I would take the first 500 and remove them using the select and cut options in rich text boxes. I still ran into the same problem.
This question appears relevant, and this one too. But they don't give any concrete recommendations for an alternative to rich text boxes.
You might try the Scintilla control (scintilla.org) which does not appear to have any hard limitations on text size. It has a permissive license. It is used by many text editors such as Notepad++, Notepad2, Code::Blocks, FlashDevelop. I haven't tried it personally but there from the documentation it looks easy to use it in a Windows API application. Of course, it might be overkill for your purposes.
If you keep appending to the text in the control every few seconds for hours then you are probably running into some memory constraint on the control or the process. I think you would have this problem with any control you choose given update frequence and how long you're running the program.
Have you considered implementing a simple circular buffer for the content of the text box? Say only keep the last hour's messages. You could maintain a separate log file for history if the operator needed to go back in time for hours.
I ended up writing my own control to do this, essentially duplicating the Output window in Visual Studio. It was a success, but it ended up being much more code than I thought it would be when I started - I insisted on features such as auto-scrolling when the cursor was on the last line, select/copy, bold text, etc. It was backed by a std::deque so I could limit the number of lines stored for the window.
Unfortunately the code belongs to a former employer so I can't share it here.
First, some backstory:
I'm making what may amount to be a "roguelike" game so i can exersize some interesting ideas i've got floating around in my head. The gameplay isn't going to be a dungeon crawl, but in any case, the display is going to be done in a similar fasion, with simple ascii characters.
Being that this is a self exercise, I endeavor to code most of it myself.
Eventually I'd like to have the game runnable on arbitrarily large game worlds. (to the point where i envision havening the game networked and span over many monitors in a computer lab).
Right now, I've got some code that can read and write to arbitrary sections of a text console, and a simple partitioning system set up so that i can path-find efficiently.
And now the question:
I've ran some benchmarks, and the biggest bottleneck is the re-drawing of text consoles.
Having a game world that large will require an intelligent update of the display. I don't want to have to re-push my entire game buffer every frame... I need some pointers on how to set it up so that it only draws sections of the game have have been updated. (and not just individual characters as I've got now)
I've been manipulating the windows console via windows.h, but I would also be interested in getting it to run on linux machines over a puTTY client connected to the server.
I've tried adapting some video-processing routines, as there is nearly a 1:1 ratio between pixel and character, but I had no luck.
Really I want a simple explanation of some of the principles behind it. But some example (psudo)code would be nice too.
Use Curses, or if you need to be doing it yourself, read about the VTnnn control codes. Both of these should work on windows and on *nix terms and consoles (and Windows). You can also consult the nethack source code for hints. This will let you change characters on the screen wherever changes have happened.
I am not going to claim to understand this, but I believe this is close to the issue behind James Gosling's legendary Gosling Emacs redrawing code. See his paper, titled appropriately, "A Redisplay Algorithm", and also the general string-to-string correction problem.
Having a game world that large will
require an intelligent update of the
display. I don't want to have to
re-push my entire game buffer every
frame... I need some pointers on how
to set it up so that it only draws
sections of the game have have been
updated. (and not just individual
characters as I've got now)
The size of the game world isn't really relevant, as all you need to do is work out the visible area for each client and send that data. If you have a typical 80x25 console display then you're going to be sending just 2 or 3 kilobytes of data each time, even if you add in colour codes and the like. This is typical of most online games of this nature: update what the person can see, not everything in the world.
If you want to experiment with trying to find a way to cut down what you send, then feel free to do that for learning purposes, but we're about 10 years past the point where it is inefficient to update a console display in something approaching real time and it would be a shame to waste time fixing a problem that doesn't need fixing. Note that the PDF linked above gives an O(ND) solution whereas simply sending the entire console is half of O(N), where N is defined as the sum of the lengths of A and B and D.