I am looking for an SDK for (roughly) the following capabilities regarding JPEG2000 files –
Decode and encode J2K files.
Decode to access individual elements (boxes, marker segments, image stream, etc.) of JPEG2000 images for inspection and potential alteration of texts and bits.
Encode (reconstruct) the JPEG2000 image with given elements.
This is all done from within C++ applications.
It must support 64-bit Redhat Linux OS.
It should be able to handle J2K (JPEG2000) files as large as 16GB i.e. 64-bit file address.
Please tell me of SDK's with the above capabilities that you know or have used in your projects. Also, hints on performance and licensing/pricing would be appreciated.
The best JPEG 2000 library is Kakadu: http://www.kakadusoftware.com/
No problems, Kakadu can handle raw codestreams (j2c) and file formatted codestreams (jp2)
Full codestream access and manipulation.
Not sure what you mean here, but if you mean to assemble components together or pieces of an image (i.e. like tiles.) yes, Kakadu is more than capable.
Yes, it's written in C++ so it will easily integrate with other C++ applications.
Yes, every major platform is supported.
Yes, 64bit addressing is supported.
Source: http://www.kakadusoftware.com/documents/Overview.txt
As for pricing and licensing model, it's a bit different for how you use it. Licenses start from $250USD for individual licenses, $500USD for evaluation licenses. See here for the most accurate details on licensing: http://www.kakadusoftware.com/index.php?option=com_content&task=blogcategory&id=6&Itemid=12
Kakadu is authored by David Taubman, one of the key contributors to the JPEG 2000 specification. If you need JPEG 2000 to do something more, he will be a great person to ask for help.
Another commercial library to do this is Accusoft Pictools.
We use it for Medical Imaging purposes.
It supports most known formats including jpeg2000 (.jp2).
https://www.accusoft.com/pictools.htm
Has complete libraries to be called from unmanaged code.
regards
Ari
Related
There are so many formats that intuitively are more bound to graphics: it could be vector graphics format such as SVG, various PNG, JPEG formats etc. Why PDF of them all has a dedicated library?
Note: this question is NOT opinion-based. I'm interested in the very reason for why PDF has such a central point in xOS. Give it a day to see.
My bonafides: I licensed my PDF viewer to Apple for Rhapsody and then the PDF library I wrote in Objective-C to Apple as the basis of CoreGraphics. I’ve written code for NeXT systems since 1988, and worked as a contractor for NeXT and Apple many times.
As Rob says, NeXTstep used Display Postscript (“DPS”), under license from Adobe. When Apple switched from “Classic” Mac OS to OS X, they absolutely didn’t want to keep paying Adobe the per-seat license for DPS each Mac it sold – it had been years since they’d agreed to pay a per-seat license to anyone for the Mac.
And, at the same time, DPS didn’t reflect modern graphics trends. It was a Turing-complete language and ran in its own process, and client apps would have to send inter-process messages to it, which meant expensive context switches and no direct sharing of buffers. (Also it broke down isolation between client processes.)
So the graphics team (led then by Peter Graffagnino) needed to replace DPS, but also not break all the existing NeXTstep apps. As it happened an engineer at Adobe (I believe it was originally Sam Streeper) had written a graphics language that was MUCH simpler than PostScript and wasn’t Turing complete, but still had most of the drawing conventions of PostScript. (Display PostScript was superset of PostScript, so any PostScript program runs in DPS.)
PDF was originally designed for PostScript-driven printers, because lots of PostScript programs (aka “print jobs”) ended up slurping down memory and processor time and often were just too big to work on any individual printer (RAM was expensive back then). Converting PostScript files to PDF made them process far more easily, and since PDF doesn’t have control flow you couldn’t, say, send the printer into an infinite loop. (Adobe processed PDF with a PostScript program they’d send to the printer as well.)
PDF was also an open standard, so with Apple writing their own implementation they didn’t have to pay Adobe anything to use it. PDF was fast and simple and free and had the exact same model because it was designed to run on PostScript printers.
So: Apple had to switch to a new graphics language for Mac OS X (née NeXTstep), and wanted one with the same semantics and Display PostScript so all their existing apps largely still worked.
So first they wrote the functional calls to CoreGraphics, implementing all the conventions of PostScript / PDF (eg: how clip paths work, how paths are filled if they self-overlap, resolution-independence, the state stack, etc). They rewrote all the existing high-level graphics functions (eg, NSRectFill()) so they were on top of CoreGraphics, so 99% of existing NeXTstep programs could switch from DPS to CG without modification. (By the late 1990s most NeXTstep programmers had realized dipping into DPS and trying to create effects by writing PostScript was pretty much always a bad idea, so we used the high-level calls.)
But the final missing piece was giving programs a format they could read and write to disk. In NeXTstep days we used both PostScript and Encapsulated PostScript, but the former was Right Out now. PDF was a natural fit (for the reasons outlined above) so they added reading and writing of PDF files.
Postscript (pun intended): The PDF code in CoreGraphics today is not what I licensed Apple — they used my code as more of a “working reference” and came up with their own APIs, since CoreGraphics couldn’t use Objective-C and my API was never really intended to be used by general programs.
The drawing model utilized by Quartz 2D is based on PDF specification.
It is widely stated that Quartz "uses PDF internally" (notably by Apple in their 2000 Macworld presentation and Quartz's early developer documentation), ... Quartz's internal imaging model correlates well with the PDF object graph, making it easy to output PDF to multiple devices.
https://en.wikipedia.org/wiki/Quartz_(graphics_layer)#Use_of_PDF
https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html
Continuing Mahal Tertin's points, focusing on the drawing side, which isn't really PDF-centric but the history is interesting anyway (I'll get to the file format side below).
Quartz was developed before 1999, and was a fairly natural continuation of NeXT's use of Display Postscript and QuickDraw, which conceptually goes back to the Lisa and was used extensively on pre-OS X Macs.
SVG might have been a reasonable base, but work on it didn't even start until 1999. It was never in a position to the basis for OS X drawing. Even if it had come out a couple of years earlier, it would still have been an untested experimental format vs a established format that Apple already had extensive code and experience for.
When iOS came along, it inherited Core Graphics, which made development dramatically easier for OS X developers. Converting everything to an SVG DOM or the like would have made iOS much harder to migrate to. (I had complex custom views on OS X that I ported verbatim to iOS with the addition of one flip translation and a hacky #define to replace NSColor with UIColor.) It also made developing iOS much easier in the first place since Apple could reuse substantial existing code. Why replace the entire drawing system with another format? To what purpose?
Quartz/PDF/Postscript all have the concept of independent objects/layers that are composited together, and has lots of support for text and lines. This makes a lot of sense when you're building a windowing system and want to easily drag a window along the screen, overlapping other windows, and minimizing computation. PNG and JPEG are built to compress single, static images. They don't make any sense for this use. JPEG in particular would be a horrible way to try to manage a windowing system full of crisp, straight lines and text, exactly the things that JPEG hates.
So that's the drawing side (which isn't really PDF-centric anyway, but it answers why SVG DOM isn't the heart of Core Graphics), but why does PDF get its own framework and not PNG?
As a graphics format, PNG does get a lot of support in iOS (as opposed to OS X). iOS is highly optimized to display PNG and converting images to and from PNG is very easy in iOS. There really isn't a need for a PNGKit. What would it do beyond what's built into UIKit, where PNG and JPEG are given their own special handling right in UIImage (handling PDF doesn't get)?
PDFKit exists because PDF is complicated, and it addresses printing problems that the other formats don't (things like handling multiple pages; when was the last time someone mailed you an SVG Print document?) While it may seem that it's getting a lot of special support by getting its own framework, PDFKit isn't really very good and doesn't support a lot of more complicated PDF features. So while there is a long history of PDF inside of Core Graphics, PDF as a file format is actually pretty poorly supported by Apple IMO. (Compare PSPDFKit, which much more powerful, and a necessary addition for almost any app that uses PDF in a non-trivial way.)
I want to Detect 360 degree video
I want to find if the video format is 360 degree and based on that manage the player supported the 360 degree
So anybody can help ?
It seems that the 360video/VR standards are still in flux. This article, http://labs.dash.umn.edu/etc-lab/detecting-spherical-media-files/, (dated April 2016) suggests that inspecting the EXIF properties of the photo/video might reveal a pattern in the metadata. There are libraries available to access EXIF data from files, such as this: https://github.com/exif-js/exif-js. PHP libraries exist as well. Phil Harvey's website ( http://www.sno.phy.queensu.ca/~phil/exiftool/) has a wealth of information and coding examples. There are compiled tools for WIN, MAC and NIX and a C++ library as well. From personal experience, EXIF values can be read from JPEG files. I have never tried accessing 360 JPEGs, but it is my understanding that the photo files produced from spherical cameras are nothing but regular JPEGs (although the images appear distorted when viewed without a 360 viewer). The EXIF tool that Phil Harvey has written shows support for mp4. You may be able to use the tool to analyze 360 videos to look for discernible patterns in the metadata.
I am looking for some tool or library (.NET version will be perfect) I could use to convert some big PDF files (over 200MB) to TIFF in the product we are developing for our client.
I need tool I could call from the command line or a library that I could use in the .Net application.
I have tested ghostscript, and it works perfect but according to its license, we cannot use it.
Do you have any experience with free or commercial products we could use for it? Could you recommend something?
Thanks in advance!
As you explicitly ask for commercial software as well, callas pdfToolbox performs this task. I'm affiliated with this company / product so draw your own conclusions about quality / price. However, the software:
works perfectly on the command-line
exports to PNG, JPG or TIFF (or rasterized PDF)
exports to either grey, RGB or CMYK
supports smoothing and overprint preview (important when you're in graphic arts, likely less so if not)
is available on Mac OS X, Windows, Linux and Unix
Send me a private message if you want to know more.
Gnostice PDFOne .NET has a PDFDocument.SaveAsMultiPageTiff() method that you can use.
http://www.gnostice.com/nl_article.asp?id=215&t=Convert_A_Multi-Page_TIFF_To_PDF_Using_PDFOne_NET
Do you know any application that will display me all the headers/parameters of a single H264 frame? I don't need to decode it, I just want to see how it is built up.
Three ways come to my mind (if you are looking for something free, otherwise google "h264 analysis" for paid options):
Download the h.264 parser from (from this thread # doom9 forums)
Download the h.264 reference software
libh264bitstream provides h.264 bitstream reading/writing
This should get you started. By the way, the h.264 bitstream is described in Annex. B. in the ITU specs.
I've created a Web version - https://mradionov.github.io/h264-bitstream-viewer/
Based on h264bitstream and inspired by H264Naked. Done by compiling h264bitstream into WebAssembly and building a simple UI on top of it. Output information for NAL units is taken from H264Naked at the moment. Also supports files of any size, just will take some time initially to load the file, but navigation throughout the stream should be seamless.
I had the same question. I tried h264 analysis, but it only supports windows. So I made a similar tool with Qt to support different platforms.Download H264Naked. This tool is essentially a wrapper around libh264bitstream
We're currently creating a device for a customer that will get a block of data (like, say, 5-10KB) from a PC application. This is a bit simplified, so assume that the data must be passed and uncompressed a lot, not just once a year. The communication channel is really, really slow, so we'd like to compress the data beforehand, pass to the device and let it uncompress the data to its internal flash. The device itself, however, runs on a micro controller that is not really fast and does not have a lot of memory. It has enough flash memory to store the result, and can uncompress the data block as it is received, but it may not have enough RAM to store the entire compressed or uncompressed (or even both!) data blocks. And of course, it doesn't have an operating system or other luxury.
This means we need a sufficiently fast uncompression algorithm that does not use a lot of memory. The compression can be slow and ugly, since we're doing it on the PC side. C or .NET code preferred though for compression, to make things easier. The uncompression code should be in C, since it's unlikely that someone has an ASM optimized version for our controller.
We found LZO, which would be almost perfect for us, but it has a so-called "free" license (GPL) by default, which makes it totally unusable for our customer. The author says that commercial licenses are available on request, but unfortunately he's currently unreachable (for non-technical reasons, like the news on his site say).
I found a few other libraries, including the puff.c from zlib, and we're still investigating, but I thought I'd ask for your experience:
Which compression algorithm and/or library do you recommend for embedded purposes, given that the decompression device has really limited resources and source code and a commercial license are required?
You might want to check out one of these which are not GPL and are fairly compact implementations:
fastlz - MIT license, fairly simple code
lzjb - sun CDDL, used in zfs for compression, simple and very short
liblzf - BSD-style license, small, fast
lzfx - BSD-style, based on liblzf, small, fast
Those algorithms are all based on the original algorithm of Lempel–Ziv–Welch (They have all LZ in common)
https://en.wikipedia.org/wiki/Lempel–Ziv–Welch
I have used LZSS. I used code from Haruhiko Okumura as base. It uses the last portion of uncompressed data(2K) as dictionary. This code can be modified to not require a temporary ring buffer if you have no memory. The licensing is not clear from his site but some versions was released with a "Use, distribute, and modify this program freely" line included and the code is used by commercial vendors.
Here is an implementation based on the same code that forms part of the Allegro game library. Allegro licensing is giftware or zlib.
Another option could be the lzfx lib that implement LZF. I have not used it yet but it seems nice. Also uses previous results so it has low memory requirements and is released under a BSD Licence.
One alternative could be the LZ77 coder/decoder in the Basic Compression Library.
Since it uses the unpacked data history for its dictionary, it uses no extra RAM except for the compressed and uncompressed data buffers. It should be ideal for your use case (zlib license, portable C). The entire decoder is just 70 lines of code (including comments), and really fast.
EDIT: Yet another alternative is the liblzg library, which is a refined version of the aforementioned LZ77 coder/decoder. It compresses better, is generally faster, and requires no memory for decompression. It is very, very free (zlib license).
I would recommend ZLIB.
From the wiki:
The library provides facilities for control of processor and memory use
There are also facilities for conserving memory. These are probably only useful in restricted memory environments such as some embedded systems.
zlib is also used in many embedded devices because the code is portable, liberally-licensed
and has a relatively small memory footprint.
A lot depends on the nature of the data. If it is simple enough, you may not need anything very fancy. For example if the downloaded data was a simple image (for example something like a line graph), a simple run length encoding could cut the data down by a factor of ten and you would need trivial amounts of code and RAM to decode it.
Of course if the data is more complex, then this won't be of much use. But I'd start by exploring the data being sent and see if there are specific aspects which would allow you to compress it more effectively than using a general purpose algorithm.
You might want to check out Jørgen Ibsen's aPlib - a couple of excerpts from the product page:
The compression ratios achieved by aPLib combined with the speed and tiny footprint of the depackers (as low as 169 bytes!) makes it the ideal choice for many products.
aPLib is free to use even for commercial use, please check the included license for details.
The compression library is closed-source (yes, I know this could be a problem), but has precompiled libraries for a variety of compilers and operating systems, including both 32- and 64-bit editions. There's C and x86 assembly source code for the decompressor.
EDIT:
Jørgen also has a free (zlib license) BrifLZ library you could check out if not having compressor source is a big problem.
I've seen people use 7zip on an embedded system with memory in the tens of megabytes.
there is a specific custom version of zlib for Micro-controller based on ARM Cortex-M (M0, M0+, M1, M3, M4)
https://github.com/kuym/Zlib-ARM-Cortex-M