Earlier quoted context omitted.
This is true, but there are container formats just as old like .mov that are quite nice to work with. (While your still sniggering, keep in mind that .mov has a lot in common with MPEG4.) Whenever I need to write a binary serialization format, I usually copy .mov's tree of structs format, it's ridiculously fast, extensible, and keeps people away from C++ terrible stream operators/Java's BinaryReaderWhateverFactoryErr…
do you have a description of the ".mov tree of structs format"
"I think you will all appreciate this person's commenting style"
31–40 of 91 posts
Re: "I think you will all appreciate this person's commenting style"
#32Earlier quoted context omitted.
Simple version (in pseudo-C): struct Atom { uint32 length; uchar type[4]; uchar data[length - 8]; }; The file is a single atom that has other atoms (and random parameters and such) in its data field. You end up with a big tree of atoms which can be parsed as needed. Super simple format -- like the parent, I use atom trees all the time for serialization.
Is it not strange to call it an Atom? Atom is etymologically indivisible, when here we can have arbitrary structure.
Atoms can be linked together to form an arbitrary structure. After all, a tree is a graph.
Re: "I think you will all appreciate this person's commenting style"
#33Earlier quoted context omitted.
do you have a description of the ".mov tree of structs format"
Simple version (in pseudo-C): struct Atom { uint32 length; uchar type[4]; uchar data[length - 8]; }; The file is a single atom that has other atoms (and random parameters and such) in its data field. You end up with a big tree of atoms which can be parsed as needed. Super simple format -- like the parent, I use atom trees all the time for serialization.
So basically just IFF/RIFF with fields exchanged?
See:
http://en.wikipedia.org/wiki/Interchange_File_Format
http://en.wikipedia.org/wiki/Resource_Interchange_File_FormatRe: "I think you will all appreciate this person's commenting style"
#34Earlier quoted context omitted.
Simple version (in pseudo-C): struct Atom { uint32 length; uchar type[4]; uchar data[length - 8]; }; The file is a single atom that has other atoms (and random parameters and such) in its data field. You end up with a big tree of atoms which can be parsed as needed. Super simple format -- like the parent, I use atom trees all the time for serialization.
So basically just IFF/RIFF with fields exchanged? See: http://en.wikipedia.org/wiki/Interchange_File_Format http://en.wikipedia.org/wiki/Resource_Interchange_File_Format
The big difference between the QT Atom structure and RIFF is that RIFF is a series of independent chunks (IIRC), whereas Atoms are a big tree. Structurally nearly identical, though.
Re: "I think you will all appreciate this person's commenting style"
#35Earlier quoted context omitted.
do you have a description of the ".mov tree of structs format"
Simple version (in pseudo-C): struct Atom { uint32 length; uchar type[4]; uchar data[length - 8]; }; The file is a single atom that has other atoms (and random parameters and such) in its data field. You end up with a big tree of atoms which can be parsed as needed. Super simple format -- like the parent, I use atom trees all the time for serialization.
Sounds almost like the IFF format, which was used for just about everything on the Amiga, and then later (with minor changes) as the basis to microsoft's RIFF, underlying wave files, .AVI and a lot of other formats.
IFF is: struct chunk { char tag[4]; int32 length; byte data[length]; byte padding[(2-(length%1))%2]; }
The padding is to two bytes; the tag uses ascii exclusively and no space (33-127), although every format I remember uses upper case + digits. The length does not include tag and the length field, not the padding. Microsoft, in a typical "we don't care" move adopted the spec except they specified little endian whereas IFF is originally big endian.
The entire file must be one complete chunk, and is thus limited to 2GB (signed integer length).
This format has been around (and at some point, dominated image storage with it's "ILBM" chunks, as well as other domains) since 1985 at least. https://en.wikipedia.org/wiki/Interchange_File_Format
Re: "I think you will all appreciate this person's commenting style"
#36I'm pretty sure the PSD format chucks are based off IFF spec from 1985
http://www.martinreddy.net/gfx/2d/IFF.txt
Things were padded to 4 byte boundries because the 68000 processor would crash if you read an unaligned 32bit value. So the length of the actual data was what you find in the size field of each chuck but each chunk is padded. That way you didn't have to work around the 68000 quirks and read a byte at a time.
I wrote a psd reader in 93. It wasn't that hard and still works today. Maybe I chose an easy subset. It only reads the original result (merged layers) that gets saved when you chose to save backwards compatible files in photoshop.
http://elibs.svn.sourceforge.net/viewvc/elibs/trunk/elibs/li...
Re: "I think you will all appreciate this person's commenting style"
#37PSD was never intended to be a data interchange format: it is the serialization format of a single program that has more individual unrelated features that actual people rely on than almost any other piece of software and has maintained striking amounts of backwards compatibility and almost unbroken forwards compatibility during its over two decades of existence. This product's "file format" needs to be critiqued in…
If a wise programmer decided he needs a serialization format, would he deliberately include in that format all the crap so vividly pointed to by the article?
No.
He will think of the "serialization format" as an interchange format between two different instances of his program. One process first writes the data file and another process later will read it. He also knows that sooner or later the "serialization format" needs to talk with different versions of his program, not just different running instances.
AFAIK, the Word .doc also started (and unfortunately continued) as basically a not-so-designed memory dump of the in-memory OLE data model. It's a format that more often than not has infamously stumped its own implementation as well. (Over time, OpenOffice has saved quite a lot of .doc files of Office users.)
Re: "I think you will all appreciate this person's commenting style"
#38John Nack replied to this 3 years ago on his blog.
http://blogs.adobe.com/jnack/2009/05/some_thoughts_about_the...
Re: "I think you will all appreciate this person's commenting style"
#39Earlier quoted context omitted.
Simple version (in pseudo-C): struct Atom { uint32 length; uchar type[4]; uchar data[length - 8]; }; The file is a single atom that has other atoms (and random parameters and such) in its data field. You end up with a big tree of atoms which can be parsed as needed. Super simple format -- like the parent, I use atom trees all the time for serialization.
Is it not strange to call it an Atom? Atom is etymologically indivisible, when here we can have arbitrary structure.
Indeed it would be much more accurate to call it a Turtle, since it's Turtles all the way down.
(Under absolutely no circumstances should anyone actually do this)
Re: "I think you will all appreciate this person's commenting style"
#40PSD was never intended to be a data interchange format: it is the serialization format of a single program that has more individual unrelated features that actual people rely on than almost any other piece of software and has maintained striking amounts of backwards compatibility and almost unbroken forwards compatibility during its over two decades of existence. This product's "file format" needs to be critiqued in…
When a file uses both little-endian and big-endian serialization, at times within the same logical structure, employs several different ways to store an array, and does other things of similar nature, then it is a genuine clusterfuck regardless of whether it is reflective of "Photoshop particular editing model."