Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Need A Standard Layered Image Format

shapeof.com

Post reply on HN
Print view View original

31–40 of 145 posts

Re: We Need A Standard Layered Image Format

#31

Post by itafroma »

eridius wrote: post #24
itafroma wrote: post #19

> 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.

At its core, a layered document is a set of declarations about the constituent parts the document is made up. They link to other objects, like images and fonts. Whether you include everything the document links to into one container or let them hang out in a folder, it doesn't change how layered files are created or interacted with within editors or elsewhere.

So to transmit web pages? Sure, we use HTML as an interchange format. You receive everything about the page to manipulate it, including the locations to where the images and other related files are.

In other words, a layered document is not the same in kind as a JPEG or a GIF, which are flattened images. You need to be able to manipulate a layered document in the same way you could manipulate a Word document or an HTML file.

Whether you use a plain text format like XML or a SQLite database, the end result is going to be the same: in a SQLite database, you could place the component images/fonts into the database as blobs, just as you could technically place the component images/fonts in an XML file as data URIs.

But at least with XML, it's editable as plain text and doesn't require the component assets to be transmitted with the layout-defining file. I much prefer that over a format that dictates everything must be encapsulated within.

Re: We Need A Standard Layered Image Format

#32

Post by seanalltogether »

I'm interested in why Acorn ties the concept of a layer so tightly to a bmp or shape blob rather then segregating the two. It seems that having a library table that the layer table links to would allow for better reuse of images.

Library table Layer table Attributes table Also, are the concept of Pages accounted for by the ordering of parentless layers, or does Acorn not support the notion of pages? Would that be its own table or a modification on the Layer table.

Re: We Need A Standard Layered Image Format

#33

Post by takluyver »

thristian wrote: post #17
aidos wrote: post #5

This 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…

There's already a similar situation for files like ODT, which are actually just a zip file with specific contents. But maybe the zip format has more flexibility to stick magic values in than sqlite does.

Re: We Need A Standard Layered Image Format

#34

Post by Someone »

derefr wrote: post #27
rogerbinns wrote: post #26

FXG 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.)

Apple also uses zip for Keynote, Pages and Numbers documents, again for very much the same reasons, and Java's .jar, .war, .ear, .whatevar files also use zip.

.zip seems to be the universal 'combine some stuff in a single file' format, probably because it is old enough to be guaranteed patent free (OTOH: http://broadcast.oreilly.com/2010/06/is-zip-in-the-public-do... and http://www.pkware.com/support/zip-app-note. http://www.pkware.com/documents/casestudies/APPNOTE.TXT only mentions encryption and patching as patented)

Re: We Need A Standard Layered Image Format

#35

Post by chc »

eridius wrote: post #23
aeontech wrote: post #14

Earlier quoted context omitted.

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.

That is a problem with your browser not clearly indicating scrollable areas. Hacker News doesn't do anything special to prevent browsers from showing scrollbars.

Re: We Need A Standard Layered Image Format

#36

Post by saraid216 »

spartango wrote: post #18

Interestingly, in the GIS/Mapping space Mapbox has faced a similar kind of problem, albeit with image tiles rather than just layers. Their solution was to come up with an image format called mbtiles ( http://mapbox.com/developers/mbtiles ), which actually uses SQLite. It's not the same problem, but perhaps it throws some credibility to the use of SQLite as an on disk format for structured images.

ESRI Shapefile formats include a DBF file, which is a Foxpro database.

Re: We Need A Standard Layered Image Format

#38

Post by takluyver »

mkr-hn wrote: post #13

Why not XCF? https://en.wikipedia.org/wiki/XCF_%28file_format%29

That page says: "The use of XCF as a data interchange format is not recommended by the GIMP developers, since the format reflects the GIMP's internal data structures, and there may be minor format changes in future versions."

Re: We Need A Standard Layered Image Format

#39

Post by mkr-hn »

takluyver wrote: post #38
mkr-hn wrote: post #13

Why not XCF? https://en.wikipedia.org/wiki/XCF_%28file_format%29

That page says: "The use of XCF as a data interchange format is not recommended by the GIMP developers, since the format reflects the GIMP's internal data structures, and there may be minor format changes in future versions."

It still seems like a better basis to fork for a format than something new and untested.

Re: We Need A Standard Layered Image Format

#40

Post by coldtea »

thristian wrote: post #17
aidos wrote: post #5

This 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…

>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

If the format catches on, they wont. For one, it would have it's own fixed file extension, and second, file(1) will be updated to perform and extra check even if something initially looks like a common SQLite database file.

Post reply on HN