I am editing a large batch of photos using the same steps, and want to create a program to run through terminal that will run the process for me. I am comfortable with writing in C, but I am unsure of how to start on the code/what commands to use.
When I am in GIMP, I start by opening a .xcf file, and importing the photo I wish to edit in as the bottom layer. Next, I resize the layer to 1000px wide. After that, I edit the curves with a preset I have saved, and then do the same with the brightness controls. Finally, I export the file as a .png with a specific name: 01-0xx.png, based on the number of the photo in the set.
This sounds like a job for macros or the automation tools available in Gimp:
Ref: Gimp Automate Editing https://www.gimp.org/tutorials/Automate_Editing_in_GIMP/
This tutorial will describe and provide examples for two types of
automation functions. The first function is a tool to capture and
execute “Macro” commands. The second function is a set of Automation
Tools to capture and run a “Flow” or “Process”. The code for this
tutorial is written using Gimp-Python and should be platform portable
– able to run on either Linux or Windows operating systems. *
The goal of these functions is to provide tools that speed up the
editing process, make the editing process more repeatable, and reduce
the amount of button pushing the user has to do. Taking over the
button pushing and book-keeping chores allows the user to focus on the
more creative part of the editing process.
I haven't ever used GIMP, but programs of this sort typically have automation scripting support, and this is the right place to start.
Could be done with C, but the learning curve is steep.
You can write Gimp scripts in Scheme (Lisp) or Python, and if you know C you can learn enough Python in a couple of hours. See an example of a Python batch script here.
Side note #1: Curves+Brightness contrast can be done in one single call to Curves (with a different curve of course). Each operation entails some color loss, so the fewer, the better.
Side note #2: It may be simpler to do this with without Gimp using:
The ImageMagick tool box (command called from a shell script)
An image library with any language ("pillow" for python).
Your Curves preset is just what is called a "CLUT" (Color Look-Up Table).
Related
I have 7 testsuites that are specific to languages something like German, Finish, Italy etc., I would like to execute all at one time. Kindly provide me solution on this. Referred to many materials, but having confusions that how we should work with RED Editor.
AFAIK the only possibility to add parallel execution to robot tests is to
parallelize code inside python classes or
make each test suite a
separate test call (i.e. with ctest execution) and call several of
them separately (ctest -j)
RIDE does not provide this, nor does robotframework natively.
In the recent releases of RED it is possible to use a custom script to launch robot from RED. The documentation shows some examples in the Launch Scripting section. In the section about launching using Gradle there is a nice Windows batch example.
This could be used to have RED launch Pabot to run several Robot sessions in parallel. This would allow you to achieve the parallelisation from RED you seek.
The Selenium Grid can help with this, but I'd consider it if the testing load needs to be spread across multiple machines. If only running locally, then pabot itself is sufficient.
I'm trying to get some automator script going but I have no clue how to achieve it. It's like this:
in Processing I exported a batch of 1850 SVG's. These SVG's now have to be opened in an application called Cenon. This application can save SVG's as .hpgl files.
It's no problem to open a file in a specific application like Cenon when it's added to a folder. That works fine.
But how do I save this file in a specific extension like .hpgl and create a variable name? Because Cenon always opens a file with the name 'UNTITLED'.
So I need to do:
automatically open file one by one in Cenon
save file as .hpgl file
save file with variable name like (0001, 0002, 0003, 0004, 0005, etc.)
I hope someone can help me!!
Thanks in advance,
Fons.
First of all, let me make a distinction between two related technologies:
AppleEvents which are messages that can be used for different applications to communicate with each other, asking each other to do tasks.
AppleScript which is one kind of scripting language that can send and receive AppleEvents to and from Mac applications.
You can't use AppleEvents with Cenon but you still may be able to use AppleScript with Cenon. I know that you can't use AppleEvents with Cenon because I downloaded Cenon version 4.0.1 from the web and I tried to open up it's AppleEvent dictionary with the "AppleScript Editor.app" application that comes with OS X.
So, AppleEvents are out. This means the "tell" command in AppleScript can't tell the Cenon.app to do anything with AppleEvents, but you may still be able to use AppleScript.
AppleScript can be used by simulating user menu-selections and key strokes instead of using AppleEvents. Using AppleEvents would be better, but sometimes, using AppleScript, you have to go through the user interface.
An alternative to resorting to using AppleScript to simulate the user-interface (UI) would be to use a shell-command. It just seems to me that this would be a better solution, but you would have to find a Unix shell command that was compiled for Mac that would convert from .svg to .hpgl
If you really want to use AppleScript and Cenon.app, here is a link to study about using AppleScript going through the UI of an app:
http://www.macosxautomation.com/applescript/uiscripting/
AppleScript was originally designed to be a scripting language to take some of the functionality with application A, and then take some of the functionality of application B, etc, and glue it together with a little logic from AppleScript and empower the user to more easily automate their tasks.
AppleScript was designed to be an alternate user-interface, going through AppleEvents, but AppleEvents are not as widely supported as they could be by applications, so this kludgy solution of having AppleScript go through the GUI is commonly done.
Again, I think that a shell script would be a better solution for this problem and you could call is "solution.command" or you could embed the shell script into an Automator Workflow saved as an Application or embed the shell script within an AppleScript saved as an application. Either one work work.
I have always used winforms to do my projects but I have never really explored the console application. I have seen some videos of different programs done in console applications for example, games, engines, display images using the keyboard keys and more but what exactly is a console app for?
More backend types of things, typically for apps that require no user interaction (backup jobs, etc… that run on a scheduled basis).
This question is in danger of being closed ... but I'll try to answer.
Really console applications have a history - in the days when a console, which may have been a teletype with a single output line, to a tty style console with a several line screen was the main UI for computers from mainframes to personal computers running CP/M, DOS or one of almost hundreds of different operating systems.
Whilst #james_schorr is parially correct, some technical people still find console apps to be efficient ways of performing certain sorts of operations - even with user interaction. For example I use git and mercurial from the command line in preference to a UI like tortoise.
They have some advantages (especially on Unix and Linux) because you can combine the commands in scripts using pipes (i.e. where standard out of one is fed directly into standard input of the next) to form very powerful operations.
I use them primarily for command line apps that perform repetitive tasks. You can support input parameters through the args array parameter to the Main method.
Simplicity. Throwawy apps. Test apps. Logging consoles. Ensuring it will work on Mono and/or from a command line. Or just laziness. Take your pick.
Specifically text-based programs, which represent decades of our programming heritage.
Before Windowing came about mainstream, users were quite happy to work in in console based text programs.
I can remember when we could write real business/financial apps in DOS or green-terminal UNIX that people actually wanted.
They could be used for virtually any task, but are mainly used for automated tasks, tasks that don't require too much advanced user intervention, tasks where a GUI would consume too much CPU power, tasks where large amounts of data are used as inputs or outputs that the user doesn't need to view, etc.
I have a C program that runs a scientific simulation and displays a visualisation in an OpenGL window. I want to make this visualisation into a video, which will eventually go on YouTube.
Question: What's the best way to make a video from a C / OpenGL program?
The way I've done it in the past is to use a screen capture program, but this is very labour-intensive (have to start/stop the screen capture program, save the video file, etc...). It seems like there should be a way to automate the process of making a video from within the C program. Then I can leave it running overnight and have 20 videos to look through in the morning, and choose the best one to put on YouTube.
YouTube recommend "MPEG4 (Divx, Xvid) format at 640x480 resolution".
I'm using GLUT 3.7.6_3, if that makes a difference. I can change windowing system if there's a good reason.
I'm running Windows (XP), so would prefer answers that work on Windows, but Linux answers are ok too. I can use Linux if it's not possible to do the video stuff easily on Windows. I have a friend who makes a .png image for each frame of the video and then stitches them together using "mencoder" on Linux.
you can use the glReadPixels function (see example)
But if the stuff you are trying to display is made of simple objects (i.e. spheres, rods, etc..), I would "export" each frame into a POV-ray files, render these, and then make a video out of these pictures. you will reach a much higher quality like that.
Use a 3rd party application like FRAPS to do the job for you.
Fraps can capture audio and video up
to 2560x1600 with custom frame rates
from 1 to 120 frames per second!
All movies are recorded in outstanding
quality.
They have video samples on the site. They seem good.
EDIT:
You could execute a tool to record the screen from your C application by calling it like system("C:\screen_recorder_app.exe -params"). Check camstudio, it has a command line version.
Which configuration management tool is the best for FPGA designs, specifically Xilinx FPGA's programmed with VHDL and C for the embedded (microblaze) software?
There isn't a "best", but configuration control solutions that work for software will be OK for FPGAs - the flow is very similar. I use Subversion at work and git at home, and wrote a little on 'why' at my blog.
In other answers, binary files keep getting mentioned - the only binary files I deal with are compilation products (equivalent to software object and executables), so I don't keep them in the version control repository, I keep a zipfile for each release/tag that I create with all the important (and irritatingly slow to reproduce) ones in.
I don't think it much matters what revision control tool you use -- anything that you would consider good in general will probably be OK here. I personally use Git for a sizable Verilog + software project, and I'm quite happy with it.
What will bite you in the ass -- no matter what version control you use -- is this: The Xilinx tools don't generally respect a clean division between "input" and "output" or between (human edited) "source" and (opaque) "binary." Many of the tools like to store some state information, like a last-run time or a hash value, in their "input" files meaning that you'll get lots of false changes. Coregen does this to its .xco files, and project navigator (the main GUI) does this to its .xise files. Also, both tools have a habit of inserting or removing lines for default-valued parameters, seemingly at random.
The biggest issue I've encountered is the work-flow with Coregen: In many cases, at least one of the following is true:
You have to manually edit the HDL files produced by Coregen.
The parameters that went into Coregen are stored somewhere other than the .xco file (usually in what looks like an output file).
You have to copy-and-paste the output from Coregen into your top-level design.
This means that there is no single logical source/master location for your input to the core-generating process. So even if you have the .xco file under version control, there's no expectation that the design you're running corresponds to it. If you re-generate "the same" core from its nominal inputs, you probably won't get the right outputs. And don't even think about merging.
I suggest CM tools that support version labeling and binary files. Most Software CM applications are fine with ASCII text files. They may just store a "difference" file rather than the entire file for updates.
My recommendations: PVCS, ClearCase and Subversion. DO NOT USE Microsoft SourceSafe. I don't like it because it only supports one label per revision.
I've seen Perforce and Subversion used in a couple of FPGA-intensive companies.
We use Perforce, and its great. You can have your code that lives in Linux-land checked in side-by-side with your Specs and Docs that live in Windows-land. And you get branching, labels, etc.
I've seen everything from Clearcase to RCS used, and it is really all okay for this kind of thing. The important thing is to get a good set of check-in policies established for your group, and make sure they stick to it.
And have automated nightly regressions. That way, when someone breaks the rules, they can be identified and publicly shamed.
I have personally used Perforce, Subverion, git and ClearCase for FPGA projects. Since VHDL and C are just text files, any works fine. However be sure to capture the other project and contraint files and any libraries you use.
Also think about what to do with the outputs, e.g. log file and bitstreams. Both tend to be big and the bitstreams are binaries.
Previously I used Subversion but have switched to git two years ago. Git handles FPGA design files just as well as it handles every other text and binary file. Git is all you need for version controlling your files and artifacts.
For building the designs, I recommend just using a single ISE project called "ise" (living in a subdirectory called "ise/"). You can take a look at my (very modest) FPGA open-source project on github for the file layout. I don't bother storing the ISE files at all since they are easy to regenerate. The only things I save are the Verilog files and some ISIM waveform config files. In other projects that use coregen I save the coregen.cgp project file and all of the *.xco scripts for regenerating cores. Then I use a Makefile for actually running coregen on the *.xco files. There are a few other Xilinx-specific files you should version control too: *.ucf, *.coe, *.xcf, etc.
I experimented with using Makefiles and the Xilinx command-line tools but found that ISE did a much better job tracking dependencies and calling the tools with the right arguments. Just don't make the mistake of trying to version control your ise/ project files or you will go mad. Xilinx has something like 300 different file types which change every release. If you want to save a file, you can try the ISE project file itself with a .xise extension. Anything that is hard to recreate, like the golden bitfile that you know works and took 6 hours to build, you might want to copy that and configuration manage it explicitly.