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

41–50 of 145 posts

Re: We Need A Standard Layered Image Format

#41

Post by eridius »

chc wrote: post #35
eridius wrote: post #23

Earlier quoted context omitted.

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.

But it doesn't do anything to force the scrollbars either, or to provide a visual treatment that indicates that this is an independent scrollable area. We've had iOS around for 6 years now, with its hidden-scrollbars approach, and OS X has followed the hidden-scrollbars approach for some time now as well. It is no longer acceptable to assume that scrollbars are necessarily going to be visible.

Re: We Need A Standard Layered Image Format

#42

Post by peatmoss »

saraid216 wrote: post #36
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.

And I still dream of spatialite becoming the one interchange format to rule them all.

Re: We Need A Standard Layered Image Format

#43

Post by groby_b »

"I want a filesystem in a single file. I'll pick the one I'm most comfortable with and pretend that it's much better than separate files".

Meanwhile, we'll ignore all the semantic issues around the data. What exactly _is_ a layer? Any given image file? What if some tools only handle e.g. alpha-layers? What if a layer is actually a filter kernel?

How are the layers composited? How are they ordered? Is it a linear order, or is there actually a tree of layers?

The reason PSD works so well is only partially that things are all in one file. It's also that the semantics of its contents are extremely well defined. (OK, if you're willing to consider PSD documentation "extremely well defined")

And Gus is almost completely punting on that part - define _that_ well enough, and it might make sense. Until then, it's just another VFS with a blob of assets that the receipient probably can't parse exactly as intended.

Re: We Need A Standard Layered Image Format

#44

Post by SQLite »

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.

Not if you set "PRAGMA secure_delete=ON;" See http://www.sqlite.org/pragma.html#pragma_secure_delete for additional information.

Re: We Need A Standard Layered Image Format

#45

Post by SQLite »

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 are currently 24 contiguous bytes of unused space in the SQLite header. If need be, and if SQLite catches on for use as a portable image format, I will be willing to allocate some or all of those 24 bytes to an identifier string for file(1).

Re: We Need A Standard Layered Image Format

#46

Post by aidos »

SQLite wrote: post #45
thristian wrote: post #17

Earlier quoted context omitted.

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 are currently 24 contiguous bytes of unused space in the SQLite header. If need be, and if SQLite catches on for use as a portable image format, I will be willing to allocate some or all of those 24 bytes to an identifier string for file(1).

This is surely one of the greatest responses I've ever seen on the internet. What was the intention with the unused space originally? Did you foresee this moment coming?

Re: We Need A Standard Layered Image Format

#47

Post by prodigal_erik »

eridius wrote: post #41
chc wrote: post #35

Earlier quoted context omitted.

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.

But it doesn't do anything to force the scrollbars either, or to provide a visual treatment that indicates that this is an independent scrollable area. We've had iOS around for 6 years now, with its hidden-scrollbars approach, and OS X has followed the hidden-scrollbars approach for some time now as well. It is no longer acceptable to assume that scrollbars are necessarily going to be visible.

HN's semantic markup isn't always great, but in this case it simply uses 
 styled with overflow: auto.
> The behavior of the 'auto' value is user agent-dependent, but should cause a scrolling mechanism to be provided for overflowing boxes. — http://www.w3.org/TR/CSS2/visufx.html#overflow
Apple's rendering is overly pretty to the point of being useless. They dropped support for a perfectly reasonable semantic requirement (make all the content available) which was in the spec literally before their browser existed.

Re: We Need A Standard Layered Image Format

#48

Post by zellyn »

Some of your blobs seem to contain a lot of structured data: I would further specify a format for them somehow: perhaps as further tables that join to the main ones, perhaps as JSON, perhaps as protobufs. Burying application- or format-specific blobs in SQL fields just pushes the problem down a level.

Re: We Need A Standard Layered Image Format

#50

Post by hiker »

OpenEXR solved that problem years ago and it's supported by virtually all content creation tools. An open source implementation with a well designed C++ api and bindings to several other languages.

For reasons that I don't understand, it's adoption is weak outside of the VFX industry.

Post reply on HN