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

61–70 of 145 posts

Re: We Need A Standard Layered Image Format

#61

Post by ceol »

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

First, thanks so much for making what is one of the most awesome database tools around.

If you would be willing, what's your opinion on using SQLite as an image format like this? The "When to Use" page specifically sites application file formats as a good use, but would your header byte allocation be done begrudgingly or contentedly?

Re: We Need A Standard Layered Image Format

#62

Post by Semiapies »

This is an interesting idea, though I cringe a little at using a relational database as a key/value store (as in the case of layer_attributes).

I wonder whether it would be more useful to just represent the whole thing as a big JSON structure with base64 blobs. Each layer can be an object in the "layers" array with the attributes as keys.

Re: We Need A Standard Layered Image Format

#63

Post by arielpts »

aaronblohowiak wrote: post #54

> When you want to send someone an image you want to pass them a single file, not an XML file with a folder of assets. While there are technical benefits to this, it's an incredible burden on the customer. Or, you could just zip that whole thing up and everyone who doesn't have to care thinks it is "just one file", like .war's.

Other common examples: .app .docx

Re: We Need A Standard Layered Image Format

#65

Post by [deleted] »

SQLite wrote: post #53
aidos wrote: post #46

Earlier quoted context omitted.

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?

When designing a file format, it is always a good idea to plan for enhancements. There were originally 36 bytes of unused space in the 100-byte header of the SQLite 3.0.0 file format, back in 2004 - bytes set aside specifically to deal with unforeseen needs. Over the years, 12 of those bytes have been allocated to various improvements. 24 bytes remain. (I'd prefer not to use them up all at once or on a whim, obviousl…

[deleted]

Re: We Need A Standard Layered Image Format

#66

Post by crgt »

chc wrote: post #55
eridius wrote: post #41

Earlier quoted context omitted.

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.

Hacker News does everything it is supposed to according to the CSS standard to indicate to your browser that the area is scrollable. In fact, it is obvious that the site is doing enough because the browser does in fact render the area as scrollable. The fact that your browser doesn't do anything to visually indicate when a region is an independent scrollable area is entirely Apple's fault . You can argue that website…

Huh. So do we build sites for users or to satisfy specs?

Re: We Need A Standard Layered Image Format

#67

Post by mkr-hn »

rosser wrote: post #58
mkr-hn wrote: post #39

Earlier quoted context omitted.

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

Something you don't control — and which the people who do control it say "don't use this because we'll probably change it often" — is somehow better than something you do control?

> fork

Re: We Need A Standard Layered Image Format

#68

Post by gilgoomesh »

Semiapies wrote: post #62

This is an interesting idea, though I cringe a little at using a relational database as a key/value store (as in the case of layer_attributes). I wonder whether it would be more useful to just represent the whole thing as a big JSON structure with base64 blobs. Each layer can be an object in the "layers" array with the attributes as keys.

Layered images can easily grow to gigabytes in size. You do not want to store that much information in a format like JSON that must be opened into memory, parsed and stored in native objects. SQLite is RAM efficient and quick to open, even at large file sizes.

Re: We Need A Standard Layered Image Format

#70

Post by skue »

groby_b wrote: post #43

"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 orde…

But a layered image SHOULD be a single file and not a filesystem. No non-technical user would expect otherwise.

And why all the spite? Gus isn't proposing that Acorn's database schema BE the standard. He says that clearly. He simply wrote a blog post giving an example of how he has used SQLite for storing layered images. (Also, he did happen to describe how he does layer sequencing - did you read the full article?) Any final spec would of course need to define additional semantics. That wasn't the point.

Post reply on HN