How about an additional frames table?
We Need A Standard Layered Image Format
21–30 of 145 posts
Re: We Need A Standard Layered Image Format
#22And why not TIFF?
Re: We Need A Standard Layered Image Format
#23Earlier quoted context omitted.
I think you're missing something in your comment. There's no change between the two lines, and no reference to offset or rotation.
mouse over the declaration line and scroll left.
Oh, wow. HN really truncates that early. Those code blocks were narrower than the surrounding text, with no indication whatsoever that they were independently scrolling divs.
I get that HN is awfully bare-bones in its appearance, but this I think is a bit too far.
Re: We Need A Standard Layered Image Format
#24> Last summer, Adobe killed their image exchange format "FXG". Edit: previously I had balked at this claim, but I'm wrong. While I can't find any official notice of its death, and it's still in use in Scene7 and somewhat supported in the open-sourced version of Flex, trawling message boards does indicate Adobe shying away from it in favor of SVG[1][2] and it's not supported in CS6 without an extension. Still, his pro…
We also don't typically use HTML as an interchange format between editors.
Re: We Need A Standard Layered Image Format
#25I would like to suggest this minor change: create table layers (id text, parent_id text, sequence integer, uti text, name text, data blob); become (Vec2 used for notation's sake to make the declaration simpler--just two reals): create table layers (id text, parent_id text, sequence integer, uti text, name text, data blob, offset Vec2, bounds Vec2, rotation real); This would make it really easy to ignore layers which…
I would argue you're not gaining much by complicating that specific table structure, since that information is going to be stored in the layer_attributes table where it naturally belongs. There may be several other attributes that can affect whether or not to load the resulting binary blob into memory.
Re: We Need A Standard Layered Image Format
#26FXG could have solved the single file problem by grouping all the files up and making a zip file, and picking a different extension. For example this is how Android (.apk) and iOS (.ipa) applications are distributed.
It also has the advantage that if you extract the zip you can now access whatever pieces are inside as separate files even by tools that don't understand the containing format. (eg a bunch of jpg/png inside the zip are perfectly viewable in any image viewer). Trying to do the same with SQLite is problematic as you have to write queries to grab the blobs and then dump them to disk.
Where SQLite as a format does shine is if you need to keep historical information such as an undo/redo log. That makes it good for an application format, but not for an interchange format.
Re: We Need A Standard Layered Image Format
#27FXG could have solved the single file problem by grouping all the files up and making a zip file, and picking a different extension. For example this is how Android (.apk) and iOS (.ipa) applications are distributed. It also has the advantage that if you extract the zip you can now access whatever pieces are inside as separate files even by tools that don't understand the containing format. (eg a bunch of jpg/png ins…
> For example this is how Android (.apk) and iOS (.ipa) applications are distributed.
A more relevant example: this is how .docx files work, for very much the same reasons (one XML file at the root, and then a bunch of referenced resources.)
Re: We Need A Standard Layered Image Format
#28Won't this format leave behind traces of what was in the file before? I'm not sure that this is something that we want in a standard interchange format. Users will assume what they are sending is only what they see in an application. This is reasonable. I am concerned that using this format will lead to data leaks.
How is that different from a psd or editable fireworks png file? I can have several groups with various visibility toggles that any normal user wouldn't see unless they dig into the layers.
Re: We Need A Standard Layered Image Format
#29> Last summer, Adobe killed their image exchange format "FXG". Edit: previously I had balked at this claim, but I'm wrong. While I can't find any official notice of its death, and it's still in use in Scene7 and somewhat supported in the open-sourced version of Flex, trawling message boards does indicate Adobe shying away from it in favor of SVG[1][2] and it's not supported in CS6 without an extension. Still, his pro…
We also don't typically use HTML as an interchange format between editors.
But that's because HTML has complicated and ambiguous rendering rules, not because everyone hates structured, human-readable index documents.
Re: We Need A Standard Layered Image Format
#30This whole idea seems totally mad from a distance but as a developer I'd love to be able to open complex files as DBs. What would be the downfalls of passing around a DB as an image file? Does the compression suck? Does the performance suck? What makes this a terrible idea? EDIT: to clarify, by compression I'm referring to the non-lossy type - I'm assuming that within the db you'd have already processed assets.
One downside would be that tools like file(1) that try to guess a file's format by examining its contents would return "SQLite database" for every image file, which isn't the most helpful result. Since SQLite aims to be a generic way for applications to store data, it'd be nice if its "open database" and "create database" functions allowed you to supply, say, a 4- or 8-byte magic value that would be stored at a fixed…
I'm not convinced this is actually a good idea overall, but...
There's no reason `file` couldn't be made to recognize special cases of SQLite databases. It certainly handles far uglier cases already.
And SQLite already provides a place to store meta-data about a table: http://www.sqlite.org/pragma.html#pragma_user_version Though the bummer is user_version is only 32 bits.