Clojure read TGA witout libraries - clojure

I want to read TGA file to BufferedImage. How I can do it without libraries?
Now there is function:
(defn load-image [filename]
(ImageIO/read (File. filename)))
This function read jpeg file successfully, but return nil instead of BufferedImage for TGA file.

The easiest thing would be still to use a library, for example TwelveMonkeys. In your project.clj (if you are using Leiningen), add:
{:dependencies [... [com.twelvemonkeys.imageio/imageio-tga "3.4.1"]]}
Then, in the code:
(ImageIO/scanForPlugins)
(defn load-image [filename]
(ImageIO/read (File. filename)))
This will work for valid TGA files.

Related

Why can't itext read this tiff

I am using iText 7.0.0 to read in pages from a TIFF image file and add those pages to a PDF.
I have found an example TIFF that iText cannot read.
The answerer of this question Exception when converting tiff file to pdf file with iText mentioned sharing problem TIFFs, so I am doing that here.
This is a clojure example that fails reading the first page with both the recoverFromImageError and direct flags set to true. It also fails to read all of the other pages.
(let [tiff "test-multi-rgb-compression-type-7.tiff"
url (UrlUtil/toURL tiff)]
(Image. (ImageDataFactory/createTiff url true 1 true)))
This produces the following stacktrace:
com.itextpdf.io.IOException cannot.read.tiff.image
TiffImageHelper.java: 279 com.itextpdf.io.image.TiffImageHelper/processTiffImage
TiffImageHelper.java: 89 com.itextpdf.io.image.TiffImageHelper/processImage
ImageDataFactory.java: 400 com.itextpdf.io.image.ImageDataFactory/createTiff
The TIFF file is accessible here https://drive.google.com/file/d/0B5HypmT13gm-RGFURWZ4SlgxLUk/view?usp=sharing
Thanks for you time.

can we set password for zip file using minizip

I want to set password for zip files using minizip.I didn't find an documentation regarding this.I know we can encrypt all the zipped file.
A complete example using C code is provided in the /contrib/minizip directory: minizip.c for the compression, miniunzip.c for the decompression.
As said in the previous comment zipOpenNewFileInZip3 is for compression with password.
For decompression you have to open the zipped file(s) with unzOpenCurrentFilePassword.
Googling:
err = zipOpenNewFileInZip3_64(zf,savefilenameinzip,&zi,
NULL,0,NULL,0,NULL /* comment*/,
(opt_compress_level != 0) ? Z_DEFLATED : 0,
opt_compress_level,0,
/* -MAX_WBITS, DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY, */
-MAX_WBITS, DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY,
password,crcFile, zip64);
Taken from here.
If you use from command line:
minizip [-p password]

How to create .sub (vobsub sutitle sub/idx) file from bitmap files

I have some bitmap files (jpeg, png, ...) and I want to write a C++ program that joins those bitmap files to pes stream (mpeg-2 format), then create a sub file (.sub/.idx: vobsub subtitle files).
Can you give me some hint?
Thanks
Can't you just call ffmpeg ?
First gogle result : http://tooloftrade.blogspot.fr/2011/10/merging-images-into-movie-using-ffmpeg.html

In the context of clojure-xml/parse, what is an InputStream?

I can't figure out what an InputStream is in the context of the clojure-xml documentation. The clojure-xml documentation lists the inputs to clojure-xml/parse as a "File, InputStream, or String naming a URL".
I tried:
(defn open-file
"Attempts to open a file and complains if the file is not present."
[file-name]
(let [file-data (try
(slurp file-name)
(catch Exception e))]
file-data))
(clojure-xml/parse (utl/open-file "test.xml"))
and receive this error:
FileNotFoundException /home/cnorton/projects/clojure/xml-lib/<
(No such file or directory) java.io.FileInputStream.open
(FileInputStream.java:-2)
but this works:
(clojure-xml/parse "test.xml")
Why wouldn't an InputStream be considered the result of opening a file? Therefore, what is an InputStream in this context?
InputStream refers to a java.io.InputStream. The easiest way to get one in Clojure is by using clojure.java.io/input-stream.
clojure.xml/parse should accept anything that clojure.java.io/input-stream would. Examples:
(require '[clojure.xml :as xml])
(require '[clojure.java.io :as io])
(xml/parse "/Users/bsmith/.m2/settings.xml")
(xml/parse (io/input-stream "/Users/bsmith/.m2/settings.xml"))
The difference between "/Users/bsmith/.m2/settings.xml" and a "File name":
"/Users/bsmith/.m2/settings.xml" is a String which (happens) to specify an (absolute) path to a file on my file system. In the Java world, however, the class java.io.File is the idiomatic way to represent a file path. clojure.java.io does't care, it will accept a String naming a file or a java.io.File naming a file.
The error message you got in your initial post came because you first loaded the XML into a String using slurp. (Not a good idea since XML carries its own encoding with it, which slurp is not able to interpret.) In any event, you then passed the String on and clojure.java.io ultimately tried to interpret the actual content of the XML as a file path, which clearly can't work.

Decompression and extraction of files from streaming archive on the fly

I'm writing a browser plugin, similiar to Flash and Java in that it starts downloading a file (.jar or .swf) as soon as it gets displayed. Java waits (I believe) until the entire jar files is loaded, but Flash does not. I want the same ability, but with a compressed archive file. I would like to access files in the archive as soon as the bytes necessary for their decompression are downloaded.
For example I'm downloading the archive into a memory buffer, and as soon as the first file is possible to decompress, I want to be able to decompress it (also to a memory buffer).
Are there any formats/libraries that support this?
EDIT: If possible, I'd prefer a single file format instead of separate ones for compression and archiving, like gz/bzip2 and tar.
There are 2 issues here
How to write the code.
What format to use.
On the file format, You can't use the .ZIP format because .ZIP puts the table of contents at the end of the file. That means you'd have to download the entire file before you can know what's in it. Zip has headers you can scan for but those headers are not the official list of what's in the file.
Zip explicitly puts the table of contents at the end because it allows fast adding a files.
Assume you have a zip file with contains files 'a', 'b', and 'c'. You want to update 'c'. It's perfectly valid in zip to read the table of contents, append the new c, write a new table of contents pointing to the new 'c' but the old 'c' is still in the file. If you scan for headers you'll end up seeing the old 'c' since it's still in the file.
This feature of appending was an explicit design goal of zip. It comes from the 1980s when a zip could span multiple floppy discs. If you needed to add a file it would suck to have to read all N discs just to re-write the entire zip file. So instead the format just lets you append updated files to the end which means it only needs the last disc. It just reads the old TOC, appends the new files, writes a new TOC.
Gzipped tar files don't have this problem. Tar files are stored header, file, header file, and the compression is on top of that so it's possible to decompress as the file it's downloaded and use the files as they become available. You can create gzipped tar files easily in windows using winrar (commercial) or 7-zip (free) and on linux, osx and cygwin use the tar command.
On the code to write,
O3D does this and is open source so you can look at the code
http://o3d.googlecode.com
The decompression code is in o3d/import/cross/...
It targets the NPAPI using some glue which can be found in o3d/plugin/cross
Check out the boost::zlib filters. They make using zlib a snap.
Here's the sample from the boost docs that will decompress a file and write it to the console:
#include <fstream>
#include <iostream>
#include <boost/iostreams/filtering_streambuf.hpp>
#include <boost/iostreams/copy.hpp>
#include <boost/iostreams/filter/zlib.hpp>
int main()
{
using namespace std;
ifstream file("hello.z", ios_base::in | ios_base::binary);
filtering_streambuf<input> in;
in.push(zlib_decompressor());
in.push(file);
boost::iostreams::copy(in, cout);
}
Sure, zlib for example uses z_stream for incremental compression and decompression via functions inflateInit, inflate, deflateInit, deflate. libzip2 has similar abilities.
For incremental extraction from the archive (as it gets deflated), look e.g. to the good old tar format.