Re: [SLUG] Re: Sharpening an image.
Daniel Bush wrote: wbenn...@turing.une.edu.au wrote: I've a file taken with a mobile phone. The detail is execrable. It's important to identify a couple of faces in the file. I've asked around. The best I have is to go through the file, select a critical frame, download it and use The Gimp to sharpen a given face. First off, can this be done? I haven't tried loading video files into gimp (I'm assuming you mean some sort of video file right?). I know that you can convert frames to pictures using mplayer: mplayer video_file -vo png -ss 1:00:00 -endpos 4 This will approximately play from 1hr to 1:00:04 and capture the frames as png images in the current directory (I haven't actually tested it so you might need to add the compression option in (-vo png:z=0 etc). There's also jpeg which has more options in my version of mplayer. You may need to check which -vo's are supported: mplayer -vo help I think you can also apply filters on the video using -vf including unsharp mask: mplayer -vf help A random example: mplayer video_file -vo png -vf unsharp=l7x7:1.5 -ss 1:00:00 -endpos 4 See the man page for mplayer. Other ways of sharpening the resulting images might include: getting gimp to batch process them (haven't done this); or using imagemagick's 'convert' to sharpen the images using something like the -sharpen option in a simple shell script. Once you have the images (i'd try bmp to preserve as much detail as you can) If there isn't alot of motion you could try stacking the images (adding the frames togther) Its a bit like taking a long exposure with a camera, you can get a brighter/clearer image. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: Sharpening an image.
Hi there, First, I agree with all the comments made about if this relates to any legal issue/incident and do you really want to know. These are eminently sensible and helpful comments. However, if they do not apply, the following information may be of assistance IF the video is 3GP. I saved the information (as is) from a site I visited ages back when I had a mobile which took 3GP video. The site has since disappeared. I can vouch that the images where cleaner. Note my use of the word 'cleaner'. As a moving image it was certainly better, as a still image it was merely better, BUT nothing like you'd see on CSI :) If the video is not in this format, it would be helpful if you can let us know what format it is in. ** Easy steps to improve 3GP video quality August 20, 2006 at 12:25 am · Filed under Gadgets Quality of 3GP movies recorded with my Sagem myX6-2 isn’t pleasing. This is common for every mobile device camera: video has low resolution, H.263 codec makes many artifacts (it is designed for bandwidth below 64kbps), small camera sizes cause shaky image, etc. However 3GP files can be postprocessed and interpolated to higher quality. Here is how I accomplish this using free tools: Basic processing mplayer (http://www.mplayerhq.hu/) allows playing 3GP files. mencoder is an bundled application that allows encoding result into another format. Both applications support video filters, read below about basic usage and compare results applied on a single video frame: 1. Original 3GP file Video has resolution of 176×144 2. Resizing to 346×260. Command used: mplayer -vf scale=346:260 file.3gp Here, compression artifacts are clearly visible. Let’s try to reduce them. 3. 2xsai - 2x scale and interpolate algorithm + noise removal. Command used: mplayer -vf 2xsai,scale,denoise3d file.3gp As you can see, block artifacts are reduced, areas of the same color are smoothed. We’re ready to write result into a new file. 4. Output to file with lavc compression (best quality): mencoder -ovc lavc -o outputfile.avi -vf 2xsai,scale,denoise3d file.3gp Download and compare: original 3GP file (934k), original video in AVI format, lavc codec (2.5M), final result (3.3M). Advanced processing Mobile devices video recordings often suffer from other problems than low quality, that cannot be expeled with mplayer video filters. This is for example luminance variations beetween frames and shaky image. Advanced processing can be archieved using VirtualDub (http://www.virtualdub.org/) - a great video capture/processing utility, released under GPL. It is available only for Windows, but runs smoothly under Wine (Windows Emulator). Note! VirtualDub cannot process 3GP containers. Decompress them with this command: mencoder -o outfile.raw -ovc raw infile.raw. Functionality of this software can be extended with plugins, here are some more useful ones: * Smart Smoother by Donald Graft - filter performs structure-preserving smoothing. Works good for removing video noise and MPG/JPG artifacts. * Deshaker by Gunnar Thalin - eliminates camera shakiness and makes panning, rotation and zooming smoother. * Deflicker - filter that corrects frame luminance variations over time. Regards, Patrick -- Registered GNU/Linux User 368634 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] comments in scripts and source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, recently I've started getting into Python and Django programming as well as shell scripting. I was wondering is there any rule or guide on good practice on how to comment code? For me and my current knowledge state, very low I would say :-), I do a lot of commenting. sometimes more than one line comments on one line code. Now I was wondering if I should place the comments before the actual code line, after or at the end. I like commenting in line after the code as it makes the code more easy to read - for me... But I like commenting lines preceding the code line as it keeps the lines itself short... I think that most would say it comes down to personal preference but I was wondering at the same time if there are some rules I should get used to right from the start. Cheers, seb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: http://getfiregpg.org iD8DBQFJaowNMuBzgG5z7F8RAqZoAJ9Pzw3SRaes6LOdlU4bOqCQSZPFVACghmIG NhFonZutl3aBKUneNvtlDOE= =fJ7n -END PGP SIGNATURE- -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] comments in scripts and source code
Sebastian sebastian.spi...@gmail.com writes: recently I've started getting into Python and Django programming as well as shell scripting. I was wondering is there any rule or guide on good practice on how to comment code? No, You can find an awful lot of opinion out there, but there is no actual rule you can use to guide you. On that basis, what follows is obviously my personal opinion. In my case this is based on ~ 12 years of experience, in a wide range of environments, which means they work for me — but not necessarily for you. For me and my current knowledge state, very low I would say :-), I do a lot of commenting. sometimes more than one line comments on one line code. Now I was wondering if I should place the comments before the actual code line, after or at the end. Generally, before the code, or perhaps on the same line. It is very uncommon to run into code where comments come after the code, and it would be much easier to miss the comment entirely in that case. I suspect you are commenting too much in your code, though, if you have more comments than actual code. (Well, that, or you are writing APL or some equally dense language, in which a statement can comprise hundreds or even thousands of logical operations. ;) As a rule of thumb comments serve two purposes in code: they document the high level design of the code, and they document the intimate detail of implementation. For high level design a single block, at the start or end of the module, is generally best. Something like the manual page structure is generally useful; it covers what a reference manual would reasonably include. This is also where you should include, for example, notes on the overall performance of the module, why you selected the high level algorithms, and so forth.[1] It sounds like you are mostly talking about the intimate details of implementation, though, rather than the high level stuff. At that level you want to explain the *why* of the code: not the high level stuff (this is a shell sort), but the low level stuff (this mangling of the name is to handle quoting for the next three lines...) Your audience here is someone from the future: in six months, when the script needs to change, someone has to come back and make changes. After that time even you will not remember exactly why you did things the way you did, or what the hacks you introduced were. So, you want the comments to guide you there. So, write for someone who needs to know *why* something is done the way it was. Don't comment the obvious; this is never useful: int x = y * z; // x is y multiplied by z This, however, is a critical comment: # baz(1) passes the name to a subprocess via sh -c, performing a # second round of filename expansion. We work around that here. $fname =~ s//\\/gi; What that does is explain, to me, *why* I wrote that code. It doesn't try to tell me what it does — I can read that and see that it introduces some quoted double-quotes — but rather why it matters that I do that. I like commenting in line after the code as it makes the code more easy to read - for me... But I like commenting lines preceding the code line as it keeps the lines itself short... Generally, I have found code readability to be one of the most important factors here. Select a style that enhances the ability of a random third party to read the code, rather than looking for a hard and fast rule. I think that most would say it comes down to personal preference but I was wondering at the same time if there are some rules I should get used to right from the start. Understanding *why* the comments are there is generally the biggest step to getting them right, I find. :) Regards, Daniel Footnotes: [1] If you find that you have too many of those in a single module or script to document at this level that is, in my opinion, a pretty strong hint that you should be writing two separate modules. :) -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] comments in scripts and source code
On Mon, Jan 12, 2009 at 10:47 AM, Sebastian sebastian.spi...@gmail.com wrote: Hi all, recently I've started getting into Python and Django programming as well as shell scripting. I was wondering is there any rule or guide on good practice on how to comment code? Depends upon the programming/software engineering community you're working in. Some people are very anti-comments, others see it as a mandatory. Follow the conventions around you. The key point is that if you do comment, make them worthwhile. Don't just paraphase the code but explain what's going on. i.e. # Increment x by 1 x = x + 1; is most certainly a waste of everyone's time, but // Calculate the Levenshtein distance between s1 and s2 // refer http://www.merriampark.com/ld.htm#REFS for details. insert code here Explains WHAT you're doing, but not HOW you're doing it. You can read the code for the 'how' (although if you're doing something tricky or deviating from a well-known algorithm then that's when explaining the 'how' adds value) i.e. // Calculate the Levenshtein distance between s1 and s2 // refer http://www.merriampark.com/ld.htm#REFS for details. // Note that the inner loop is deviates from the norm since // we're only handling strings less than 5 chars. insert code here For me and my current knowledge state, very low I would say :-), I do a lot of commenting. sometimes more than one line comments on one line code. Now I was wondering if I should place the comments before the actual code line, after or at the end. 'Before' is the typical convention. Although an end of line comment can be useful if not too long. I like commenting in line after the code as it makes the code more easy to read - for me... But I like commenting lines preceding the code line as it keeps the lines itself short... I think that most would say it comes down to personal preference but I was wondering at the same time if there are some rules I should get used to right from the start. As per coding standards in general follow the conventions of the existing code. If this is new code, it's up to you, but the usual advice is to follow the conventions of the language or community you're targeting. That way you'll attract others, and it'll be easier to keep it consistent going forward. If the code is only for your eyes, remember the goal is still to be able to come back and change that code in 6 months time. Note that some communities, such as Python and the Linux Kernel (to name two) have very strong existing coding standards. Always code as if the person who'll be maintaining your code is a violent psychopath who knows where you live is something to remember when you're trying to decide whether you need to comment a piece of code :-) Hope this helps, -- Michael Davies Do what you think is interesting, do something that mich...@the-davies.netyou think is fun and worthwhile, because otherwise http://michaeldavies.org you won't do it well anyway. -- Brian Kernighan -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] MythTV Quite Multi-streaming H.Drives
Hi MythTV Users. In a effort to have the most silent MythTV backend integrated frontends' Those of you with some available dosh may be interested in the following hard drives just released that are specially suited to multi- streaming media data (DTV). That is of course until Solid State Drives become affordable and appropriate sizes for DTV Media Centres, will probably do the best available job of storage. URL -- http://www.crn.com.au/News/92392,seagate-launches-new-pipeline-hd-drives.aspx Cheers. Grahame. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] MythTV Quite Multi-streaming H.Drives
2009/1/12 Grahame Kelly grah...@wildpossum.com: Hi MythTV Users. In a effort to have the most silent MythTV backend integrated frontends' Those of you with some available dosh may be interested in the following hard drives just released that are specially suited to multi-streaming media data (DTV). That is of course until Solid State Drives become affordable and appropriate sizes for DTV Media Centres, will probably do the best available job of storage. URL -- http://www.crn.com.au/News/92392,seagate-launches-new-pipeline-hd-drives.aspx Cheers. Grahame. Hey, I imagine this is to compete directly with the Western Digital 'AV' branded drives which have been around for a while now and have very similar characteristics. http://www.westerndigital.com/en/company/releases/PressRelease.asp?release=%7BB1A99C2C-27CC-4575-9CC3-253DA4AB6A63%7D (N.B. Dated: April 9, 2007) It is also possible on most drives to adjust the acoustic profile using `hdparm -M`. Using this you can sacrifice performance for reduced noise. Even better of course is to have the drives spun down when not in use, then they're very quiet... Cheers, Owen. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] comments in scripts and source code
A quick set of three basic guidelines for comments. I find these get my through most situations. 1. The code says what you are doing, the comments say WHY you are doing it. 2. The code is there to teach people who aren't you (which includes you-in-12-months) about the code, so in general they should be before a block of code, and introduce it. 3. Comments are for humans. Don't leave commented out old code around, they just mess up the comments, and you should be using version control for that anyway. Adam K 2009/1/12 Sebastian sebastian.spi...@gmail.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, recently I've started getting into Python and Django programming as well as shell scripting. I was wondering is there any rule or guide on good practice on how to comment code? For me and my current knowledge state, very low I would say :-), I do a lot of commenting. sometimes more than one line comments on one line code. Now I was wondering if I should place the comments before the actual code line, after or at the end. I like commenting in line after the code as it makes the code more easy to read - for me... But I like commenting lines preceding the code line as it keeps the lines itself short... I think that most would say it comes down to personal preference but I was wondering at the same time if there are some rules I should get used to right from the start. Cheers, seb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: http://getfiregpg.org iD8DBQFJaowNMuBzgG5z7F8RAqZoAJ9Pzw3SRaes6LOdlU4bOqCQSZPFVACghmIG NhFonZutl3aBKUneNvtlDOE= =fJ7n -END PGP SIGNATURE- -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] comments in scripts and source code
On Monday 12 January 2009 12:21:09 Daniel Pittman wrote: 8x As a rule of thumb comments serve two purposes in code: they document the high level design of the code, and they document the intimate detail of implementation. For high level design a single block, at the start or end of the module, is generally best. Something like the manual page structure is generally useful; it covers what a reference manual would reasonably include. This is also where you should include, for example, notes on the overall performance of the module, why you selected the high level algorithms, and so forth.[1] It sounds like you are mostly talking about the intimate details of implementation, though, rather than the high level stuff. At that level you want to explain the *why* of the code: not the high level stuff (this is a shell sort), but the low level stuff (this mangling of the name is to handle quoting for the next three lines...) Your audience here is someone from the future: in six months, when the script needs to change, someone has to come back and make changes. /x8 Well said. (As also your other notes.) I would just add: Use function header documentation! Find a template that suits you and stick to it like glue. Too many times I have caught myself out six months later trying to figure out what the heck the rationale, result and parameters for this function are. I mean, I must have put this code into a function for some reason, usually re-useabilty, and usually when I think I think I've got a routine for that somewhere, I usually also think I hope-to-dog that I documented it. And finally, dont forget the power of //hack and //todo! hth bruce -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
