Do anyone of you know of a defacto standard huffman table for progressive jpeg encoding? There's examples of tables for baseline encoding in the standard that a lot of implementations use that seem to be adequate for most uses in regards of symbol frequency and so on but I can't seem to find one for progressive encoding that includes the symbols EOB1 through EOB14.
I am not aware of such a table. The approach is to do two passes over the data and find the best table for the scan in questions.
Related
So I've been attempting to write my own JPEG decoder (In Lua for the ROBLOX platform if that's of any use) and in every guide I find online, it always uses an example where the image has 4 distinct Huffman tables. 1 for DC Luminance, 1 for AC Luminance, 1 for DC Chrominance, and 1 for AC Chrominance. When this is the case, my decoder works fine and everything is happy and nice. However when trying to decode some random jpeg images off the internet, I find that a lot of them have fewer than 4 Huffman tables, and in these cases my decoder fails miserably. I've tried researching for if there are some standard Huffman tables I should use as defaults for when the other tables aren't present, or if I should instead use a duplicate of one of the tables as a replacement for the missing ones, but I have come up empty handed. Any help on the subject would be greatly appreciated, thank you!
Okay so thank you to DaBler in explaining this to me in the comments on my original question, it was extremely helpful.
Apparently you can have multiple Huffman Tables under one DHT marker, which I did not know. I'll see if I can get it working and thank you for the help!
It just seems to me that when writing code for dynamic data visualization, I end up doing the same things over and over in different languages/platforms. Now if I had a cross platform language(which I do) and something like a binary version of SVG, I could make my code target that and use/create interpreters for whatever platform I currently need to use it on.
The reason I don't want SVG is because the plaintext part makes it too slow for my purposes. I could of course just create my own intermediary format but if there is something already out there that's implemented by various things then the less work for me!
Depending on what you mean by “too slow”, the answer varies:
Filesize too large
Officially, the closest thing SVG has to a binary format is SVGZ, which is a gzipped SVG file with the .svgz extension. All conforming SVG viewers should be able to open it. Making one is simple on *nix systems:
gzip yourfile.svg && mv yourfile.svg.gz yourfile.svgz
You could also try Brotli compression, which tends to have smaller filesize at the cost of more compression time.
Including other assets is inefficient
SVG can only bundle bitmaps and other binary data through base64 encoding, which has a fair amount of overhead.
PDF can include “streams” of raw binary data, and is surprisingly efficient when programmatically generated.
Parsing the text data takes too long
This is tricky. PDF and its brother, Encapsulated PostScript, are also old, well-supported vector graphic formats. Unfortunately, they too are also text at their core, with optional compression.
You could try Computer Graphics Metafiles, which can be compiled ahead of time. But I’m unsure how well-supported they are across consumer devices.
From a comment:
Almost nothing about the performance of SVG other than the transmission cost of sending it over a network is down to it being plaintext
No, that's completely wrong. I worked at CSIRO using XML for massive 3D models. GeoScience Australia did a formal study into the parsing speed - parsing floating point numbers from text is relatively expensive for big data sets, compared to reading a 4 or 8 byte binary representation.
I've spent a lot of time optimising my internal binary formats for Touchgram and am now looking at vector art.
One of the techniques you can use is a combination of
variable-length integer coding and
normalising your points to a scale represented by integers, then storing paths as sequences of deltas
That can yield paths where often only 1 or 2 bytes are used per step, as opposed to the typical 12.
Consider a basic line
<polyline class="Connect" points="100,200 100,100" />
I could represent that with 4 bytes instead of 53.
So far, all I've been able to find in binary SVG is this post about a Go project linking to the project description and repo
Adobe Flash SWF files may work. Due to its previous ubiquity, 'players' and libraries were written for many platforms. The specifications were open and license permitting. For simple 2D graphics, earlier, more compatible versions would do fine.
The files are binary and extraordinarily small.
How to read the pixel values of jpeg image using c/c++, without using any library.
I read about how compression takes place in jpeg in my course,i want header information.
For the syntax of the file you can check wikipedia.
Each segment has its own marker. The variable length segments have a two byte field for their length. So far is not really a problem, as you are able to extract all segments using this information (or at least it seems so on a first glance).
The more problematic part is to actually do something useful with the data inside the segments. The wikipedia page provides information on this topic, but it will require quite some mathematic knowledge to actually decode and grab the pixels.
Finally found some really helpful links..
link 1
link 2
Thanks for help and support.
I have some ideas I would like to experiment with relating to data compression, but am finding it difficult to decipher some parts of how the standard are applied "in real life". I would like to look at some sample compressed files to observe how the the blocks are arranged and the huffman tree(s) are structured.
Are there any tools in existence which can help visualize this for a given compressed file (zip/gzip/deflate etc)? I'm picturing something like a tree view or some form of graph visualizer.
You might be interested in this (if you are still interested that is :-P)
http://jvns.ca/blog/2013/10/24/day-16-gzip-plus-poetry-equals-awesome/
I made a "entropy image" tool.
The entropy_image tool replaces each pixel
with the (estimated) number of bits
necessary to encode that pixel using range coding or Huffman compression.
I hope this isn't the only compression visualization tool in the world.
Im writing a game engine and I'm wondering what 3D model format should I use/load/export? Obj seems universal and easy but it also appears to be unreliable in that most models out there contain errors and it doesn't store anywhere near as much as other formats.
There appear to be formats specifically for games such as MD2/3/5 but Im not sure, I use wings3d if I model, and I don't know what other details beyond purely loading what I need and support from the format Id have to implement, such as would I need to implement IK? and can I use scripted per piece animation rather than Inverse kinematics and bone rigging?
Collada is an open XML based format for 3d models owned by the Khronos group(OpenGL standards body)
From the Collada.org FAQ:
The COLLADA 1.4.x feature set includes:
Mesh geometry
Transform hierarchy (rotation, translation, shear, scale, matrix)
Effects
Shaders (Cg, GLSL, GLES)
Materials
Textures
Lights
Cameras
Skinning
Animation
Physics (rigid bodies, constraints, rag dolls, collision, volumes)
Instantiation
Techniques
Multirepresentations
Assets
User data
Before worrying about what 3D formats you want to support, I think you should really focus on what features you are planning to implement in your engine. Write those down as requirements, and pick the format that supports the most features from the list... as you'll want to showcase your engine (I am assuming you are planning for your engine to be publicly available). You might even want to roll your own format, if your engine has specific features (which is always a good thing to have for a game engine).
After that, support as many of the popular formats as you can (.X, .3DS, .OBJ, .B3D)... the more accessible your engine is, the more people will want to work with it!
Collada is a nice and generic format, but like Nils mentions, it is not an ideal format for final deployment.
I use my own binary format. I've tried to use existing formats but always run into limitations. Some could be worked around, others where showstoppers.
Collada may be worth a look. I don't think that it's that good as a format to be read by a 3D engine. It's fine as a general data-exchange format though.
http://www.collada.org/mediawiki/index.php/Main_Page
+1 for Collada. You may also want a custom native binary format for really fast loading (usually just a binary dump of vertex/index buffer data, plus material and skeleton data, and collision data if appropriate).
One trend in the games industry is to support loading a format like collada in the developer build of the engine, but also have a toolchain that exports an optimized version for release. The developer version can update the mesh dynamically, so as artists save changes, the file is automatically reloaded allowing them an (almost) instant WYSIWYG view of their model, but still providing a fully optimised release format.
support Collada well, and then supply good converters to/from the other formats (this might be the hard part). This will give you maximum flexibility. Take a look at C4 engine
Collada is great, but it lives more on the 3D app side of things. ie it's best used for transferring 3D data between applications, not loading 3D data from within a games engine. Have you looked into Lua? It's widely used in games because its a scripting language that's both ridiculously quick (perfect for games) and very flexible (can be used to represent whatever data you need for your engine).