Saturday, December 22, 2012

Browser - Adobe Flash

Links: Slackware Flash update :: Opera plug-in page

Like most reasonable people, I dislike Adobe's proprietary obsfucation. It's most oppressive in the Linux environment, where its intrusive modules don't interact well with Linux's more transparent libraries.

A recent Adobe Flash update1 screwed my Iceweasel installation and, in turn, destabilized a previously 3-years' stable Zenwalk install. That is, immediately following the update of (libflashplayer.so), including complete deletion of all prior versions, etc, the previously rock-solid Iceweasel intermittently crashed at Flash intensive sites. A new installation of FlashBlock did not stop the crashes. Reinstallation of all three applications did no better. I eventually had to move to ArchLinux from Zenwalk, due to these Adobe-related Flash crashes. In other words, I had to change my entire OS structure thanks to Adobe's closed-sourced, DRM intensive elements, which are so-far impossible for average users to ignore for a typical browsing environment.

1Pop-up windows demanding Adobe Flash Player updates began to appear in sponsored YouTube videos December 2012. Prior to this update ads could be bypassed. Following the update, they could not.

Saturday, September 29, 2012

EXIF data, renumbering, cropping, rotating (lossless)

Links: ExifTool :: "rename" command notes :: PDF merging

A common activity is stripping annoying JPEG EXIF data and/or renumbering shots into a reasonable schema. Of course, pulling the EXIF, say with imagemagick, typically means reducing the file quality, since any program which opens a JPG slightly reduces its quality. As for renaming, for many users, this means the prospect of a Perl or Bash script which includes the mv command.

Instead, most batch stripping and renaming can be done without a script. Two CLI applications exiftool and rename handle most situations.

renumbering

A typical problem is a set of files with the same prefix, say, "blue", but a mixture of places in their numbers. So, eg, "blue9.jpg", "blue109.jpg", "blue43.jpg". To put these in order, we want the same number of digits, say three digits. We want blue009.jpg, blue043.jpg and blue109.jpg(as-is). Suppose we have hundreds of these files. We could write a script, but are there simple commands instead? Yes. In a terminal, cd to the folder with the files and:

$ rename blue blue00 blue?.jpg
The one question mark locates the one digit file, and adds two zeros. This means blue9 will be changed to blue009. What about the two digit file, blue43.jpg? We only need to add one zero to files with two digits:
$ rename blue blue0 blue??.jpg

Now we have blue043.jpg. This is the template for any numbering system: decide on a number of digits and then one or two commands should manage it.

Exif - ExifTool

Available at the link at top. Easily extracts, writes, deletes EXIF data. I don't even recall compiling, I think all I had to do was move a copy of into /usr/bin or some such. Maybe I had to compile.

ExifTool can do several actions, but this post concerns stripping EXIF data for all photos in a directory. Go to that directory, filled with JPG files:
$ exiftool -all= *.jpg
Or, if you have exiv2 and want to losslessly remove IPTC, XMP, and EXIF data...
$ exiv2 -d a *.jpg

Renaming

Go to the directory with the files and use the rename command. Let's say they all start with "IMG" and then some number. To rename them to "Cam01_" in a numbered sequence:
$ rename IMG Cam01_ IMG*

Done.

Cropping

Scanning in 150 lines typically makes a 1256x1752 image. If I forget to set the scan size, the bottom 110 lines just show the scanner bed. To get rid of this excess, copy those JPG's (or use the originals if you don't mind them being changed) into a directory and:

$ mogrify -crop 1256x1642+0+0 *.jpg

The 0+0 is the offset, in other words the image will begin in the top left corner(0,0) and go 1256 pixels horizontally and 1642 vertically. Similarly, if I scan at 75 lines, I get a 624x877 and typically crop down to 624x822.

Rotating

$ jpegtran -rot 90/270 -trim infile.jpg > outfile.jpg

..."90" and "270" being degrees cw rotation. Eg, use "270" for 90° ccw rotation. "Trim" drops edge pixels which can't properly rotate. Also jpegtran doesn't appear to allow wildcards -- if that's correct, a script is necessary for batches with it. Thus, for lossless batching, I use mogrify after cd'ing into that folder. Eg, for 90° ccw...

$ mogrify -rotate 270 *.jpg

add OCR layer

This makes a scanned PDF searchable. Recognition is not 100%

$ yay -S ocrmypdf

pdf conversion

Edit - 2016: ImageMagick (like most apps) has become less and less intuitive to the average user over the years. 1) users should now specify "compress" to avoid a PDF file 10 times larger than the sum of the JPGs being concatenated. 2) users should attempt to match density to the scanned density. The size of the resulting PDF file in megabytes does not change due to density (unlike "compress"), but the size of the page inside the reader does change. If your scans were at 200 DPI, but your density is 100, the page size will be 2x size in the PDF browser and will not match well if concatenated with other docs:

$ convert *.jpg -compress JPEG -density 200 somefile.pdf

A rough yardstick for the density number is to use what you'd want for say, "dpi", on a printer. If one wants to change the page orientation to landscape, then add: -rotate 90 . There's more on all this here. At the bottom of that page is a link to yet a more elaborate page, etc etc.

policy file modification

In 2019, an ImageMagick security vulnerability apparently developed during conversion, such that conversion was de-authorized. To fix: change "none" to "read|write", or "all", in /etc/ImageMagick-6/policy.xml, or to the latest version, 7 or 8. The change must be in the "policymap" portion of the file. Once it's fixed, it may remain that way for a year or two but may eventually be overwritten during an update and need to be re-accomplished.

# nano /etc/ImageMagick-7/policy.xml
<policy domain="coder" rights="all" pattern="PDF,PS" />

The effect is immediate and requires no restart or logout. Any older versions still on the disk, eg version 6, will have zero effect on the current version.

Prior to 2013, ImageMagick's "convert" automatically read the density from the JPG, as well as auto-detected the compression format. A much simpler command was performed in those days:

$ convert *.jpg somefile.pdf

Concatenate/extract PDF pages

Combining several PDF's into a larger PDF (common with letter attachments) is best with GhostScript. Imagine the first input file is in1, second in2, etc...
$ gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=out.pdf in1.pdf in2.pdf

To cleanly extract one or more pages from a PDF, use Ghostscript to avoid the rasterization of extracting as a JPG:
$ gs -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dSAFER -dFirstPage=22 -dLastPage=36 -sOutputFile=outfile.pdf 100p-inputfile.pdf

Once a PDF page is isolated, make it into a reasonably clean JPG for editing.
$ convert -colorspace RGB -resize 800 -interlace none -density 300 -quality 90 input.pdf someoutput.jpg

However, in this final "convert" command, one is liable to encounter the XML security policy which requires the recommended changes noted above to /etc/ImageMagick-7.xml. The changes must go inside the "policymap" section to be effective.

evince pdf reader

Evince is a reliable gnome-based reader, however it has a incomprehensibly stupid flaw: Evince requires that gvfs be installed to display a sidebar index in the PDF. Nothing related to file systems and volume management should have been made a dependency for an application that displays PDFs. PDF readers are not file managers and can easily internally index themselves for a sidebar without an external indexer, especially an intrusive configuration and memory hog like gvfs. I now use "Okular". The interface is not as nice looking but works as well generally and without gvfs.

Sunday, April 29, 2012

Slackware - TeX4ht, Sigil

Using the new Google blog interface for the first time here. Appears it's critical to set the line breaks in "Options", or else bloggers will have to enter <br> at the end of each and every return, even inside code listings and block quotes.

Links: Sigil source Sigil is QT; TeX4ht source No specific dependencies - compiles .tex files; Instructions for making TeX4ht .epubs

Epubs in general

I have files in .tex format. These are easily transformed into PDF's or other formats in LaTeX, but what about reflowable formats? That is, what if one wishes to read files on a celly, Cobo, Nook, Kindle, etc? Two possibilities jumped out. Sigil appeared to be a good Linux WYSIWYG option for taking text files and making them into reflowable .epub files. But of equal importance, TeX4ht appears to do the job on .tex files. We'll start with it.

TeX4ht (LaTex)

The TeX4ht source is here. This appears to require the latest LaTeX installation to work.

Sigil (QT)

The Sigil source is available here, in .zip format. Download and unpack into a directory.

Installation - prep

README indicates it's a QT program. Dependencies (besides QT basics) are libqt4-xml, libqt4-svg, libqt4-webkit and libqt4-dev. Some of these also have dependencies. For a list of what libs I already had onboard, I checked with...
$ ldconfig -p |grep libqt
libqt-mt.so.3 (libc6) => /usr/lib/qt/lib/libqt-mt.so.3
libqt-mt.so (libc6) => /usr/lib/qt/lib/libqt-mt.so
...which indicated I had insufficient QT libs for Sigil.

The installer uses the annoying cmake instead of make:
$ configure prefix=/usr
$ make
# make install

Tuesday, February 28, 2012

Zenwalk-Minislack-Slackware :: Chrome from scratch

Links: libz and libxml2   file source w sloppy instructions   installation with decent library info
I followed the second instructions, linking the seven(7) libraries manually which Chrome utilzes. This avoids many update and fail issues.

initial failures

With everything properly in /opt, and libraries linked, a first run of Chrome brought only the following failures:
$ google-chrome
./google-chrome: /usr/lib/libz.so.1: no version information available (required by ./google-chrome)
./google-chrome: /usr/lib/libpng12.so.0: no version information available (required by ./google-chrome)
./google-chrome: /usr/lib/libnss3.so.1d: version `NSS_3.12.3' not found (required by ./google-chrome)

So libnss3, libpng, and libz. Updating libz apparently also requires a libxml2 update. Libnss is a mozilla security library and I believe the current version requires some other dependency updates. Libpng is probably straightforward. Not sure how many downstream dependencies these alter however.

Friday, February 17, 2012

ffmpeg to avconv

Links: libav.org - avconv, lavf   ffmpeg.org - ffmpeg still developed   xvid.org (xvidcore)   videlan.org (x264)   x264 settings
Edit: Ffmpeg (ffmgeg.org) was forked to avconv (libav.org). Both libav and ffmpeg both still use the libavcodec, but libav 0.8 appears to be the last to even be compatible with the previous ffmpeg. This post is to determine installation order for a robust avconv and describe any command changes from ffmpeg. So far (02/17/2012) order appears: 1) libav (includes libavcodec) 2) x264, 3) xvidcore

ffmpeg/avconv fork


Some confusion exists with the fork. Both ffmpeg and avconv use the same old ffmpeg logo seen here. Additionally, both are touting their use of libavcodec, so that it's unclear which project now has the most stable, fastest version of libavcodec. For now letting it go until I can get clarification on these issues.

Friday, January 13, 2012

Slackware - mp3 tags, editing

In the past, I've exclusively used the editor EasyTag, but I'm always looking for a faster approach when doing computer projects. I'm not the CS guy who can write scripts so, as a simple enthusiast, sometimes faster turns-out to be a GUI approach, other times command line. So, when I heard about eyeD3, I thought I'd give it a whirl.

installation

Standard, configure --prefix=/usr, make, make install. It likes to have python-magic for full functionality. Check the system by searching for libmagic:
$ find -name libmagic*
The only thing I'll say about this program is it unfortunately, on its own, without being requested, adds a TXXX file that notes the latest time the tag was changed. That's useless and just takes up space.

Selectomagic

This project will apparently make playlists based on BPM or other criteria.

bpm detection

EyeD3 has a bpm tag command, so it's all good, but I couldn't find a true linx BPM detector. I eventually went after Abyssmedia's BPM Counter to run it under Wine. This is supposed to be accurate. It probably is but I was getting all kinds of Wine stub errors so i couldn't really use it without tweaking Wine. Accordingly, just reverted to the manual browser-based Salsa City applet. Just hit space bar, for instance.