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

131–140 of 145 posts

Re: We Need A Standard Layered Image Format

#131

Post by tjoff »

itafroma wrote: post #120
tjoff wrote: post #118

Earlier quoted context omitted.

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

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

In other words, a single encapsulating file... Which was my point?

The exact implementation is hardly relevant is it?

"No, you couldn't."

Of course you can. Just include hashes of the different resources within the file and only the parts of the file that contain changes needs to be downloaded. Or implement something more general along the lines of the rsync algorithm.

Taking html as an example you could also do everything transparently on the server if you wanted to. Or do everything transparently on the client instead if you wanted to keep a snapshot of each visit as a single file.

But no, I'm not arguing that we should encapsulate all web pages. But on the client side, if the user chose to save a webpage, the result should in most cases be a single encapsulating file.

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

The keyword was only used linked resources. I think my point was, and is, rather obvious. PDF would never be where it is today if it weren't for its ability to encapsulate resources.

EDIT: My point isn't that all files should be encapsulating all the linked content. There must be a point to it. Web pages on a server, hardly beneficial... Image files? Absolutely.

Re: We Need A Standard Layered Image Format

#132

Post by virtualritz »

jjcm wrote: post #106
mceachen wrote: post #93

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…

Anything that TIFF lacks can be added using custom tags. All people need to do is to agree on names and types for these custom tags that store the new information. This means any old app will still be able to work with such TIFF files and just ignore the information it doesn't understand. So the problem isn't solved but the answer is not coming up with yet-another-file-format.

A good example of extending TIFF with tags is Pixar's PhotoRealistic RenderMan. It uses a TIFF flavor as a base for its mip-mapped textures. Such a TIFF contains a pyramid of layers of the image at different pre-downsampled resolutions and a bunch of custom tags, the renderer interprets when it reads such a file.

However, I can use 'Open As...' in Photoshop and open this as a TIFF. I will simply get the highest resolution layer from the file. That's a simple and battle-proven example of why TIFF is indeed a great answer to the problem.

Re: We Need A Standard Layered Image Format

#133

Post by chaz »

sneak wrote: post #98
cachvico wrote: post #96

Earlier quoted context omitted.

How about just strip PSD of all its crud, Adobe specifies it openly and gives it to the commons. I have a dream..

Keep dreaming: PSD is not a single file format, but two decades of cruft upon cruft: http://www.jwz.org/blog/2012/11/psd/

I found this article, linked in the comments, to be insightful: http://www.joelonsoftware.com/items/2008/02/19.html

Re: We Need A Standard Layered Image Format

#134

Post by nanoscopic »

Correct me if I am wrong, but FXG files are an archive with an XML file and assets, just as xlsx files are.

How is this a problem? How could is possibly be easier to open a file in sqlite than it is to just extract the file into it's folder structure with any standard decompression software?

I don't know about you, but last time checked there is no easy way to open a file contained in a sqlite database in my editor directly. I for one would much prefer the archive method than using a sqlite database.

Also, I would rather edit xml, than edit a sqlite database. XML can be edited by any text editor. I'd say text editors are a bit more universal and widespread than sqlite editors.

Re: We Need A Standard Layered Image Format

#135

Post by elsamuko »

jwarren wrote: post #113
elsamuko wrote: post #102

Earlier quoted context omitted.

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

This one doesn't work with PS, but can be opened with GIMP as two separate images:

https://sites.google.com/site/elsamuko/new.tif

tiffinfo of this image:

http://pastebin.com/raw.php?i=85aUFjeS

Re: We Need A Standard Layered Image Format

#136

Post by npsimons »

mceachen wrote: post #93

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.

Came here to say almost exactly this; of course, people being people, TIFF won't be "good enough", where "good enough" is either 1) invented in house (NIH syndrome), or 2) monetizable (TIFF is too open/not proprietary enough).

Re: We Need A Standard Layered Image Format

#137

Post by KaiserPro »

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.

There are already formats that allow you to keep n layers of images. openEXR for example allows you to keep multires, multi bitdeptph images all in the same file, with lots of metadata

It also has options for byte order to allow faster read/writes

Re: We Need A Standard Layered Image Format

#138

Post by KaiserPro »

mceachen wrote: post #93

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.

or if thats not good enough: http://www.openexr.com/

has photoshop plugin aswell. No real support in the gimp though (cinepaint possibly has it though.)

Re: We Need A Standard Layered Image Format

#140

Post by Millennium »

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…

If what you want is a filesystem in a file, then it's probably best to just start with .iso files and work from there. You'd still have to standardize the directory structure and "internal" formats for actual data, but that would get you the filesystem-like structure you're looking for in a format that is already optimized for use as a filesystem.
Post reply on HN