Live data from Hacker News

We Need A Standard Layered Image Format

shapeof.com

111–120 of 145 posts

Re: We Need A Standard Layered Image Format

#111
post #45

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

Who are you to be able to speak on behalf of the SQLite developers? Anyone could be behind that username.

Re: We Need A Standard Layered Image Format

#112
post #106

TIFF, http://en.wikipedia.org/wiki/Tagged_Image_File_Format has been around since 1993. It supports layers. It supports compression. It supports paged(!) images. It has well-defined supported image encoding formats. It's already supported by all the image editing software you've ever used (from this millennia). We have a Standard Layered Image Format. HURRAY. NEXT PROBLEM, PLEASE.

Image formats have come a long way. I think the author wants an image format that can replace .psd in a sensible way. TIFF sadly cannot do that. While it can contain layered raster data, it lacks a lot of other capabilities. The author explicitly mentions vector layers, but if you want parity with .PSD you're looking at also having to support adjustment layers (hue/curves/levels/etc), blending modes, opacity/fill, ra…

.XCF

Re: We Need A Standard Layered Image Format

#113

TIFF, http://en.wikipedia.org/wiki/Tagged_Image_File_Format has been around since 1993. It supports layers. It supports compression. It supports paged(!) images. It has well-defined supported image encoding formats. It's already supported by all the image editing software you've ever used (from this millennia). We have a Standard Layered Image Format. HURRAY. NEXT PROBLEM, PLEASE.

Fun fact: Even though Adobe sits on the TIFF standard for more than 20 years, Photoshop doesn't support layered TIFF images.

Actually, it does: http://cl.ly/image/0j383w2d0t2v

Open this test image if you don't believe me: https://dl.dropboxusercontent.com/u/824493/layertest.tif

Re: We Need A Standard Layered Image Format

#114
Standardizing a format/API upon a tool like SQLite was something that was proposed in the web world as WebSQL but scrapped due to not wanting an entire standard to rely on a specific code base but rather wanting to have the standard be possible to reimplementable by others and thus creating the IndexedDB standard instead.

I'm not proposing that an image format like this one should use IndexedDB, but if relying on SQLite means being reliant on a specific code base that has to be used by anyone that wants to read the file - then it's probably not such a good idea.

When discussing this I think one should also have in mind eg the move to web apps as well - a reliance on SQLite will make it hard for them to read the format. A standardized simple base format that can easily be supported in new languages would be preferable as I see it - but I'm no expert in the image processing area.

Re: We Need A Standard Layered Image Format

#115
It's not going to happen for the same reason a standard 3D format will never happen. (and no neither FBX nor Collada fit).

The problem is, at least in the case of image editors (and 3d editors), standard formats arguably stifle innovation because you have to break the standard to add anything.

Maybe you decide it would be be better if all vector colors were stored as HSVA instead of RGBA except now no one can read your files. Maybe you'd prefer to store floating point colors with values greater than 1.0 to represent light emission. Maybe the standard only defines circles but you want eclipses. Maybe the standard says circles are defined based on rounded rect with the maximum roundness but you'd like them to be based on a center point and radius. Maybe the standard doesn't support text on a path but you want text on path. Maybe the standard doesn't support linking paths so that if the text doesn't fit on one path it bleeds into another. Maybe you'd like to justify text across multiple paths but that's not in the standard. Maybe you like columns but that's in the standard. Or you want to be able to define areas to be cut into pngs, each area with a specifiable filename. Or you want some of the settings to be per animation frame but the spec never thought about animation so your SOL. Or you want layer fx. Or you want to add a new layer effect. Or you want to be able to embed a PDF as a layer. etc.. etc.. etc..

Photoshop's basic chucky format is well known. It's not that hard to write some code to read all the chunks you care about. Putting those chunks in an SQLite format will not make it any easier to deal with new chunks your code does not understand.

Re: We Need A Standard Layered Image Format

#116
post #108

> 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 pro…

"We don't complain that HTML is broken because it links to images instead of including them, do we?" Actually, we do. Saving a webpage and getting tons of file is a nightmare while the IE approach of lumping them all together is just so sensible it's hard to imagine a universe where this isn't standard. Replacing resources is the special case. Sharing, moving or just storing an image isn't. Just get or write a tool t…

Truth be told, you're the first person I've seen ever argue that HTML is a broken file format, particularly because it doesn't contain everything it links to. Imagine what it would mean if HTML was an encapsulated file format: you couldn't pre-fetch or cache static assets at all, because you'd have to get everything any time the structure of the document (the HTML part proper) changes. That's not a 0.001% problem.

As I and others have mentioned throughout the comments here, the single index file—be it XML like FXG, HTML, or otherwise—and linking to assets within it is pretty common and standard approach to complex documents. Combining them by zipping them up is a trivial addition and, again, common way to solve the "but I don't like having multiple files to transfer" problem.

Re: We Need A Standard Layered Image Format

#117

It's not going to happen for the same reason a standard 3D format will never happen. (and no neither FBX nor Collada fit). The problem is, at least in the case of image editors (and 3d editors), standard formats arguably stifle innovation because you have to break the standard to add anything. Maybe you decide it would be be better if all vector colors were stored as HSVA instead of RGBA except now no one can read yo…

> The problem is, at least in the case of image editors (and 3d editors), standard formats arguably stifle innovation because you have to break the standard to add anything.

Indeed: that's exactly why Adobe created FXG instead of adopting SVG in the first place[1] (though they are now circling back to SVG).

[1]: http://www.mikechambers.com/blog/2008/09/30/why-adobe-chose-...

Re: We Need A Standard Layered Image Format

#118
post #108

Earlier quoted context omitted.

"We don't complain that HTML is broken because it links to images instead of including them, do we?" Actually, we do. Saving a webpage and getting tons of file is a nightmare while the IE approach of lumping them all together is just so sensible it's hard to imagine a universe where this isn't standard. Replacing resources is the special case. Sharing, moving or just storing an image isn't. Just get or write a tool t…

Truth be told, you're the first person I've seen ever argue that HTML is a broken file format, particularly because it doesn't contain everything it links to. Imagine what it would mean if HTML was an encapsulated file format: you couldn't pre-fetch or cache static assets at all, because you'd have to get everything any time the structure of the document (the HTML part proper) changes. That's not a 0.001% problem. As…

"Combining them by zipping them up is a trivial addition..."

That, seriously, 99% of the population will never, ever, accomplish in their entire lifetime. Instead, you get files without the resources. Instead, you get files with hard coded local links to C:\xxx.

This of course works for HTML since most "regular people" never ever has to deal with either html files or its resources (but every time they do, it is sure to be a disaster).

Images on the other hand is something that most people deal with in some way or another. It must be something that you can easily share or it will be pointless.

It would be nice if you could actually add a caption to an image - without having to "destroy" the original by converting it to a png just so that you'd be sure that the recipient could handle it.

Everything has its place. Resources work fine for html files if you are the creator, if you want to store a page for later use it is a disaster.

I love the fact that the resources are separate from the document when I write use InDesign or LateX - such a relief from having to deal with word documents etc. At the same time those solutions make it completely inaccessible to most people I know, they are great for their isolated environment but disastrous for anything else.

So, an image with resources... Might work well, terrific even, in your studio but if it is ever going to be used by the masses it is a dealbreaker.

What if PDF only used linked resources, no one would even know what PDF was by now if that were the case.

"Imagine what it would mean if HTML was an encapsulated file format: you couldn't pre-fetch or cache static assets at all, because you'd have to get everything any time the structure of the document (the HTML part proper) changes. That's not a 0.001% problem."

You could of course do all that with single encapsulated file as well...

Re: We Need A Standard Layered Image Format

#120
post #118

Earlier quoted context omitted.

Truth be told, you're the first person I've seen ever argue that HTML is a broken file format, particularly because it doesn't contain everything it links to. Imagine what it would mean if HTML was an encapsulated file format: you couldn't pre-fetch or cache static assets at all, because you'd have to get everything any time the structure of the document (the HTML part proper) changes. That's not a 0.001% problem. As…

"Combining them by zipping them up is a trivial addition..." That, seriously, 99% of the population will never, ever, accomplish in their entire lifetime. Instead, you get files without the resources. Instead, you get files with hard coded local links to C:\xxx. This of course works for HTML since most "regular people" never ever has to deal with either html files or its resources (but every time they do, it is sure…

> That, seriously, 99% of the population will never, ever, accomplish in their entire lifetime.

Yes, they do. All the Microsoft Office formats (DOCX, XLSX, etc.), all the OpenOffice formats, all the iWork formats, ePub, Safari extensions, Chrome extensions, JAR files, and countless other general public-facing formats are exactly that: loose collections of files that contain an index file (or multiple index files) and are combined using zip. People by and large don't seem to have a problem dealing with them: transfers, edits, and other operations are seamless to regular users.

> What if PDF only used linked resources, no one would even know what PDF was by now if that were the case.

Many PDFs do, in fact, rely on this capability.[1] It's generally transparent to the user.

> You could of course do all that with single encapsulated file as well...

No, you couldn't. You'd have to transfer the entire file to determine what's changed. That's the the definition and principle benefit of encapsulation: one file gets transferred at once instead of many in piecemeal.

[1]: http://en.wikipedia.org/wiki/Portable_Document_Format#Conten...

Post reply on HN