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

11–20 of 145 posts

Re: We Need A Standard Layered Image Format

#11

Post by eridius »

angersock wrote: post #7

I 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 think you're missing something in your comment. There's no change between the two lines, and no reference to offset or rotation.

Re: We Need A Standard Layered Image Format

#12

Post by eridius »

darkstalker wrote: post #9

What about OpenRaster? It's used in open source apps like MyPaint and Gimp. http://www.freedesktop.org/wiki/Specifications/OpenRaster

> OpenRaster is an open exchange format for layered raster based graphics.

How's that going to work for vector images?

Re: We Need A Standard Layered Image Format

#14

Post by aeontech »

eridius wrote: post #11
angersock wrote: post #7

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

Re: We Need A Standard Layered Image Format

#15

Post by rlpb »

angersock wrote: post #8
rlpb wrote: post #3

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

That ship has pretty much sailed with EXIF and embedded metadata anyways, right? This would seem to be more targeted at digital content creation (and toolchain application interop) than a normal-use file format.

It's up to your editor what metadata it chooses to save. It is not up to your editor what data was in the sqlite row that it just modified or deleted but may still be forensically available. There is a fundamental difference here.

It is possible to clean it up of course - perhaps by vacuuming, or definitely by copying to a new file at database level. But it seems dangerous to me to start with a native format with this behavior and attempt to clean it up later.

Re: We Need A Standard Layered Image Format

#16

Post by eurleif »

rlpb wrote: post #3

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

It could be defined in the format spec that applications should VACUUM the database after every save.

Re: We Need A Standard Layered Image Format

#17

Post by thristian »

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 location in the file's header so tools could distinguish your SQLite-based file-format from everybody else's, without having to load the thing up and examine the schema.

Re: We Need A Standard Layered Image Format

#18

Post by spartango »

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.

Re: We Need A Standard Layered Image Format

#19

Post by itafroma »

> 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 problem with FXG (or a format like it) seems superficial. Yes, FXG defines links to other assets instead of combining them into one file, but to me, that's a feature, not a problem: I can them programmatically swap out assets easily by just manipulating the references within the file. It makes it really useful for generating customized assets on demand. In practice, it's like HTML for layered documents. We don't complain that HTML is broken because it links to images instead of including them, do we?

If you don't like that you have to send a folder: zip it up and give it a custom extension if need be, a la browser extensions and Microsoft Office formats.

[1]: http://mail-archives.apache.org/mod_mbox/flex-dev/201303.mbo... [2]: http://mail-archives.apache.org/mod_mbox/flex-dev/201303.mbo...

Re: We Need A Standard Layered Image Format

#20

Post by eurleif »

rlpb wrote: post #15
angersock wrote: post #8

Earlier quoted context omitted.

That ship has pretty much sailed with EXIF and embedded metadata anyways, right? This would seem to be more targeted at digital content creation (and toolchain application interop) than a normal-use file format.

It's up to your editor what metadata it chooses to save. It is not up to your editor what data was in the sqlite row that it just modified or deleted but may still be forensically available. There is a fundamental difference here. It is possible to clean it up of course - perhaps by vacuuming, or definitely by copying to a new file at database level. But it seems dangerous to me to start with a native format with thi…

>But it seems dangerous to me to start with a native format with this behavior and attempt to clean it up later.

File formats don't have behaviors. Programs do.

Lots of binary formats, including PNG, will ignore any extra junk after the end of the file. So if a change makes a PNG file smaller, there's nothing stopping a program from leaving data from the old version at the end. But that's not normal behavior for programs that write PNG, so it's not an issue.

As long as programs adopted the behavior of VACUUMing the database, this wouldn't be an issue either.

Post reply on HN