Live data from Hacker News

We Need A Standard Layered Image Format

shapeof.com

1–10 of 145 posts

Re: We Need A Standard Layered Image Format

#2
not a huge conspiracy theorist, but isn't this the kind of thing that would make us not rely on purchasing Adobe CS7 exclusively (for fear of incompatability) in the future?

Standards wise, open-source wise, and generally it's a good move (who wouldn't want to get a standard complex image format that would make sense to the common programmer?), but I don't think the finance department over at Adobe is going to like it very much?

Re: We Need A Standard Layered Image Format

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

Re: We Need A Standard Layered Image Format

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

Re: We Need A Standard Layered Image Format

#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 have no component in the view space, or to compactly represent raster subimages.

"bounds" is the size of the axis-aligned bounding-box of the image. "offset" i a translation from the center of the axis-aligned bounding-box of the layer image data to the origin, and "rotation" is the rotation (in radians, CCW) of the layer. Order of application is rotation, then translation.

EDIT: Fixed missing def for "bounds".

Re: We Need A Standard Layered Image Format

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

Re: We Need A Standard Layered Image Format

#10

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

If I can just use sqlite, than I don't have to open an archive, parse xml, and otherwise get into a bad mood (see their file layout here: http://www.freedesktop.org/wiki/Specifications/OpenRaster/Dr...).
Post reply on HN