Does GDCM library support the following DICOM transfer syntaxes:
1.2.840.10008.1.2.4.53 JPEG Spectral Selection, Nonhierarchical (Processes 6 & 8)
1.2.840.10008.1.2.4.55 JPEG Full Progression, Nonhierarchical (Processes 10 & 12)
If yes, could anyone link me sample pictures encoded with these transfer syntaxes? I've been searching everywhere, but I found nothing...
Thanks for your reply.
I have already seen that link you provided, but there is no Transfer Syntax UIDs list, so I wasn't sure GDCM supports exactly transfer syntaxes I mentioned in my question.
Still, I need to test it in practice, so still looking for files encoded with those transfer syntaxes... Searched over 20k pictures and didn't find them, but I know there must be somewhere example files..
Yes GDCM does support both of those, see Short Presentation
Related
I would like to convert this book Mastering the Lightning Network, which is freely available through GitHub to a pdf for personal use.
Unfortunately, I have only figured out how to "translate" single files using asciidoc or asciidoctor-pdf. The options for folders don't seem to work with the configuration of the repository.
There has to be an easy way to translate everything, including all files and pictures. Would be very thankful if somebody could help me out.
As far as I know it is not possible to convert a folder containing AsciiDoc files to a pdf, a simple script could do it but the problem would be in what order do you want your files to be converted?
The simplest solution for you is to create your own content.adoc file and use the include macro to select what files you want to convert and in what order, it could look something like this:
= Mastering the Lightning Network
include::01_introduction.asciidoc[]
include::02_getting_started.asciidoc[]
include::03_how_ln_works.asciidoc[]
include::04_node_client.asciidoc[]
include::05_node_operations.asciidoc[]
include::06_lightning_architecture.asciidoc[]
include::07_payment_channels.asciidoc[]
include::08_routing_htlcs.asciidoc[]
include::09_channel_operation.asciidoc[]
include::10_onion_routing.asciidoc[]
include::11_gossip_channel_graph.asciidoc[]
include::12_path_finding.asciidoc[]
include::13_wire_protocol.asciidoc[]
include::14_encrypted_transport.asciidoc[]
include::15_payment_requests.asciidoc[]
include::16_security_privacy_ln.asciidoc[]
include::17_conclusion.asciidoc[]
and you convert using asciidoctor-pdf content.adoc
You could try using imagemagick:
magick *.jpg out.pdf
This question is about extraction of metadata only.
Is it required for exiftool to get a complete file for propperly working?
Scenario:
I want to extract the metadata of a 20 GB video file. Do I need to provide exiftool with the complete file (via stdin), or is it enough to provide it with a certain amount of bytes.
Motivation:
I am programatically (golang) calling exiftool in a streaming context and want to have the extraction as fast as possible. Magic numbers for filetypes work with the first 33 bytes and I am wondering if that is possible with the exiftool metadata as well.
The answer depends upon the file and the location of the metadata within that file.
There are a couple of threads on the subject on the ExifTool forums (link 1, link 2) and Phil Harvey, the author, says that about half the time the in the case of MP4/MOV videos, the metadata is at the end of the file.
Using the -fast option might help. I've done some quick tests using cURL and a large image file (see the second to the last example under Piping Examples) and in that case cURL didn't download the whole image file, just enough to extra the metadata. It might be different with a video file though, as I haven't tested that situation.
I downloaded some data in DAF "transfer" format, which NASA completely
fails to explain here:
http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/req/daf.html#Conversion%20and%20Transfer%20of%20DAF%27s
How do I read this file. Here are the first few lines I'm trying to comprehend:
DAFETF NAIF DAF ENCODED TRANSFER FILE
'DAF/SPK '
'2'
'6'
'NIO2SPK '
BEGIN_ARRAY 1 3895604
'URA111 '
'-BC186A96D0E76^8'
'BC0DDF032F041^8'
'2BD'
'7'
'1'
'3'
1024
'-BC18166^8'
'FD2^4'
'-DA4A19AC2BCD18^4'
'-4D5E7E1A67739^4'
'1D46248537C30E^5'
'EBA587DFA5E3B^3'
'-26885CE73CB0D^4'
'-BF0DC6EDB5B2C8^2'
'129C1CFEABE48^3'
'5594FC676368^1'
'-472EBF2225A^1'
'-2198AE1963D^0'
'79CC4CA0C^-1'
'FDD9792D82^-2'
'2001D81A^-2'
'333BCEE2BDD724^4'
'-D78AA10831D9C8^4'
'-6D712677574DF8^4'
'283A14783CDC^4'
'90AC22194ABF6^3'
'-1DEF6219F664FE^3'
'-47318F604096^2'
'9B805F405B1C^1'
'1275B947E2AC^1'
'-16A664664D^0'
'-2F614B9F5^-1'
'-B7C3E41D^-3'
'2F3D71F8^-3'
According to NASA, this is/was a popular format for Fortran programs,
but google was not at all helpful (wikipedia doesn't have an entry
either).
OK, I think I finally figured it out at least part of this. For
reference, the original file (a whopping 162M in size) is the
ura111.bsp file in:
http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/satellites/
and converted to ura111.xsp using the toxfr program in:
http://naif.jpl.nasa.gov/pub/naif/utilities/SunIntel_32bit/
The small files:
http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/satellites/ura111.cmt
http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/satellites/ura111.inp
explain more about the main file.
Things like "-BC18166^8" really are double precision numbers, written
in modified hexadecimal IEEE-754 format. Wikipedia sort of explains
this format here:
http://en.wikipedia.org/wiki/IEEE-754
and there are IEEE-754-to-decimal convertors like this:
http://www.h-schmidt.net/FloatConverter/ (and many others)
However, these don't explain/convert the exact format NASA uses, which
was one reason for my confusion.
For reference "-BC18166^8" is converted as follows:
The decimal value of "BC18166" is 197230950
We now divide by 16 repeatedly until the result is less than 1 (in
other words, we divide by 16^(length of "BC18166")), yielding
0.734742544591427
The '^8' means we multiply by 16**8 to get 3155695200
the leading "-" just means we add a minus sign to get -3155695200
Of course, we could've combined steps 2 and 3 and just multiplied
197230950 by 16.
#klugerama, to answer your question, yes, I am trying to write a file
parser, this time in Perl, as part of a program that accurately
identifies the positions of various objects in our solar system.
I've already parsed the NASA files relating to planets (and Earth's
own moon) here:
ftp://ssd.jpl.nasa.gov/pub/eph/planets/ascii/
but these are in a much different and far easier-to-parse format.
This document (hosted at ucla.edu) has a complete description of the file format.
Addtionally, check out this python project on Github. It appears to provide the DAFTB function you're looking for.
Edit For the record (cough), it doesn't look like this format was ever intended to be read, per se, by humans. It's a transfer format intended to be converted back to usable binary in whatever executable code is appropriate.
You didn't explain why you want to do this. So unless you are writing a file parser (which has been done already in at least two languages), I'm not sure what the benefit is of being able to read the raw values.
Strictly speaking, the answer to your question is that you use software (see link above) to read it.
I would like to do a task that is quite simple on other OS, but it is not so trivial on iOS. Namely, I want to create file and open it in Numbers.
I can preview the file with UIDocumentInteractionController and then offer it to user that he/she opens it.
THis seems to me quite a reasonable solution. However, I need to offer proper file format. I suppose CSV and XLS would be reasonable to implement and it would most probably work, but I would still like to do it in native Numbers format if possible. However, I can't find any info about this file format.
Basically, this task is about exporting data to another app and then working further with them.
I don't know of a library that can create native Numbers files. There are hoewever some libraries that allow creating XLS files. Since Numbers fully supports XLS, this is probably the way to go.
There is a comercial library available that might work on the iPhone (costs $200): http://www.libxl.com/
As for free XLS libraries, I only know xlwt, a Python module. You could set up a webservice that creates an XLS file for your app, using xlwt on the server side.
If you want to pass information to Numbers, you can probably also use CSV files. If you use CSV files, you must be aware of some things. There are two kinds of CSV files: the comma separated version (used in english speaking countries) and the semicolon separated (used in continental europe).
The comma separated CSV files look for example like this:
"ID","First Name","Last Name","Salary"
1,"John","Malkovich",3400.20
2,"Fred","Astaire",2000.60
The second kind of CSV files are semicolon separated and use a comma as decimal mark. They look like this:
"ID";"First Name";"Last Name";"Salary"
1;"John";"Malkovich";3400,20
2;"Fred";"Astaire";2000,60
On the Macintosh, Numbers expects a different format depending on the Region setting. If you have your Region set to the US, it will expect the first kind. If you choose Germany, it will expect the second kind.
I don't know what kind of files Numbers on the iPad expects.
Another alternative would be using copy and paste. Try to copy tab separated text into the clipboard.
I hope this may help you. I've contacted libxl team and they responded with the link to the demo version of their iPhone library: http://www.libxl.com/download/libxl-iphone.zip
Usually both files are availble for running some diff tool but I need to find the differences in 2 binary files when one of them resides in the server and another is in the mobile device. Then only the different parts can be sent to the server and file updated.
There is the bsdiff tool. Debian has a bsdiff package, too, and there are high-level programming language interfaces like python-bsdiff.
I think that a jailbreaked iPhone, Android or similar mobile device can run bsdiff, but maybe you have to compile the software yourself.
But note! If you use the binary diff only to decide which part of the file to update, better use rsync. rsync has a built-in binary diff algorithm.
You're probably using the name generically, because diff expects its arguments to be text files.
If given binary files, it can only say they're different, not what the differences are.
But you need to update only the modified parts of binary files.
This is how the Open Source program called Rsync works, but I'm not aware of any version running on mobile devices.
To find the differences, you must compare. If you cannot compare, you cannot compute the minimal differences.
What kind of changes do you do to the local file?
Inserts?
Deletions?
Updates?
If only updates, ie. the size and location of unchanged data is constant, then a block-type checksum solution might work, where you split the file up into blocks, compute the checksum of each, and compare with a list of previous checksums. Then you only have to send the modified blocks.
Also, if possible, you could store two versions of the file locally, the old and modified.
Sounds like a job for rsync. See also librsync and pyrsync.
Cool thing about the rsync algorithm is that you don't need both files to be accessible on the same machine.