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

81–90 of 145 posts

Re: We Need A Standard Layered Image Format

#81

Post by peatmoss »

blacksqr wrote: post #57
peatmoss wrote: post #42

Earlier quoted context omitted.

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

I just used Spatialite to create a tool for managing large stacks of images on the pixel level; i.e., each image gets its own database file, each pixel is stored as an XYZ coordinate and an RGB value. I can use Spatialite's built-in functions to rotate, translate, scale, etc. images; and use SQL to pull out sub-volumes of the stack, edit and composite them. My biggest stack is almost 2000 images, over 90GB uncompress…

Do you do anything in particular to improve access speed to that image data? I've been working with big matrices that get spit out of traffic assignment software that we use in travel modeling. Every vendor seems to have their own proprietary format. We ended up using HDF5 as a container due to its somewhat awesome speed characteristics. I'd initially tried SQLite for that matrix data, but couldn't squeeze the same kinds of performance out of it. That could have just been my own brain fail though.

Re: We Need A Standard Layered Image Format

#82

Post by est »

IMHO SQLite is horrible format. using Matroska (.mkv) would be suitable for anything, vectors, bitmaps, audios and so on. It's essentially a container format like XML but for binary

WebM is based on mkv as well.

Re: We Need A Standard Layered Image Format

#84

Post by kalleboo »

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…

Does the zip format let you replace an arbitrary file inside an archive without rewriting the whole file? It's not uncommon to see Photoshop files that are 400+ MB, and rewriting the whole file on save would have some pretty poor performance. The other examples of files that use the zip approach are either distribution-only (ipa/apk/jar) or generally don't get very big (word processing).

Re: We Need A Standard Layered Image Format

#85

Post by comex »

benatkin wrote: post #59

The author didn't put the punchline in the title. Why did you put it in the title, HN submitter or editor?

On the contrary, in my opinion, this isn't a joke, and since the "punchline" was likely to draw attention to the article from people that might be more interested in a debate over the wisdom of using SQLite "trivially" like this than a generic discussion of image formats, it was useful and shouldn't have been removed from the title.

Re: We Need A Standard Layered Image Format

#86

Post by comex »

skue wrote: post #70
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?) A…

> But a layered image SHOULD be a single file and not a filesystem.

But if all (or most of what) you want is a VFS, SQLite isn't necessarily a good way to make one. As has been mentioned elsewhere in the thread, it's fairly common for modern file formats to be zips of a structured filesystem; although this has upsides and downsides compared to SQLite, it seems much easier to run unzip than look up how to get SQLite to output the binary content of a table row to a file.

Re: We Need A Standard Layered Image Format

#88

Post by jcampbell1 »

robbles wrote: post #51
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…

Couldn't someone come up with a relatively sane schema for storing the same information that a PSD would contain in a SQLite database? That way, you could standardize on the semantics that are already documented and familiar to other developers, but avoid the difficulties of the file format , which seem to be the issue here. * disclaimer: I've never had to write a PSD-parser, I'm just going on hearsay.

Photoshop layers have all the nastiness of threaded comments plus the added complexity of "blending". I frankly can't comprehend the complexity of modeling Photoshop's layers as SQL tables.

Converting PSD's to JSON seems like a reasonable thing to do, but converting them to normalized SQL seems like a never ending shit show.

Re: We Need A Standard Layered Image Format

#90

Post by shuzchen »

aceofspades19 wrote: post #77
arielpts wrote: post #64

Earlier quoted context omitted.

XML is a really bad format for containing large chunks of binary data (bitmap)

And why are we storing binary data? The whole point of SVG is everything is in XML unless I'm very mistaken

The author is looking for a container format capable of storing multiple image layers, and one that is capable of storing both vector and raster images.

So you could possibly argue that XML (a la SVG) is the right format to represent the vector files within that container, but it wouldn't be appropriate for the container file itself since binary data really bloats XML.

Post reply on HN