Comments on spec

[j...@rastered.com]

Using a database as an image file format seems a bit crazy - like nearly all really good ideas.

On the spec page the question is asked:

If an application which provides features such as non-destructive filters on layers (also known as layer styles), should a composite of the layer be stored as an attribute of the layer? And if it does, maybe a specific key should be used? Maybe 'lift.composite' and 'lift.composite-uti' to store the uti of the composite (tiff/jpeg/png)?

I would reverse that. Store the filtered image as the main data in the layer, and use a layer_attribute to store a reference to the original unfiltered image. This will do a better job of preserving the appearance of the file between applications.


Also from the spec page:

file version info should be stored outside image_attributes. Do we need a 'document_attributes' table which would describe the particular format, the author, copyright, etc?

I would say yes there should be a document attributes table.


I don’t think the documentation specifies the storage format for images including alpha. I suspect most users of this file format would expect alpha to be non-premultiplied.

James Cox
j...@rastered.com

[Gus Mueller]

On Mar 19, 2014, at 5:52 PM, j...@rastered.com wrote:

Using a database as an image file format seems a bit crazy - like nearly all really good ideas.

It’s certainly a lot better than xml + folders of images at least (I’m looking at you Adobe).

On the spec page the question is asked:

If an application which provides features such as non-destructive filters on layers (also known as layer styles), should a composite of the layer be stored as an attribute of the layer? And if it does, maybe a specific key should be used? Maybe 'lift.composite' and 'lift.composite-uti' to store the uti of the composite (tiff/jpeg/png)?

I would reverse that. Store the filtered image as the main data in the layer, and use a layer_attribute to store a reference to the original unfiltered image. This will do a better job of preserving the appearance of the file between applications.

Yea, that makes sense as well.  I could go either way - does anyone else here have input on that?

Also from the spec page:

file version info should be stored outside image_attributes. Do we need a 'document_attributes' table which would describe the particular format, the author, copyright, etc?

I would say yes there should be a document attributes table.

Someone recently pointed out that there’s already a built in sqlite stuff for this - schema_version and user_version.  But that’s obviously only two rows so maybe a bit more would be in order.

I think the author / copyright stuff should probably go in image_attributes with all the other meta data for the image (yes, I’ve changed my mind a bit from the original spec).

I don’t think the documentation specifies the storage format for images including alpha. I suspect most users of this file format would expect alpha to be non-premultiplied.

Since the image data for the row is based off the UTI, it’s up to the particular format of that UTI.  public.png would be alpa + non-premultiplied.  public.jpeg would be only 3 data channels, since there’s no alpha.

-gus

[Jen Montes]

Regarding the filters question, I'd much prefer that the filtered  image be the main data in the layer as James suggested. At the end of the day, it's more important that the image look consistent regardless of the app. I've personally run into situations where different applications rendered an image in different ways and it can be frustrating if you're not sure how the artist intended for it to look, so it would be great to have that information front and center.

Jen

[Troy Gaul]

In actuality, storing a single composite of a filtered layer isn’t necessarily practical by itself, depending on what you want that feature to work with.

If you look at Layer Effects in Photoshop, for example (assuming you want to encompass these). In Photoshop the command to generate layers from layer effects will emit multiple additional layers above and/or below the layer they were attached to (and potentially grouped into a clipping group with them). This is necessary in some cases due to the layer effects using different blending modes than the base layer.

_troy

[Gus Mueller]

On Mar 21, 2014, at 12:19 PM, Troy Gaul <troy...@gmail.com> wrote:

> In actuality, storing a single composite of a filtered layer isn’t necessarily practical by itself, depending on what you want that feature to work with.
>
> If you look at Layer Effects in Photoshop, for example (assuming you want to encompass these). In Photoshop the command to generate layers from layer effects will emit multiple additional layers above and/or below the layer they were attached to (and potentially grouped into a clipping group with them). This is necessary in some cases due to the layer effects using different blending modes than the base layer.

You lost me on both parts :)

A single layer in PS can generate multiple layers out of it? As in, they would show up in the layers list?

I understand the various compositing difficulties involved with blend modes and such, but PSDs don’t actually write out anything more than the layer data minus the styled effects, correct?

thanks,

-gus

[James Cox]

You are correct that PSDs do not contain rendered versions of the layer effects. 

I think Troy was just pointing out that it is not always possible to replace a computed effect with a single layer, as in the case of photoshop layer effects.

[Troy Gaul]

I'm talking about Layer Effects (aka "Layer Style") in Photoshop. You know, the stuff like drop shadows, bevel & emboss, etc. that you can apply to other layers. These are not written by Photoshop to the documents it creates as separate layers. In fact, if I recall correctly, they are not included in PSDs in raster form at all, but rather just as a set of parameters.

Specifically, I'm talking about the stuff in this dialog:

I'm guessing most PSD readers don't try to handle these, as the rendering stack needed to support them is pretty complicated.

So, I was suggesting that if an app wanted to be able to include something like these in a document in a way another app could render, they could do so by including rasterized versions. However, to encompass this Photoshop feature, this would be more than just a different rendered version of the (single) layer, but rather one layer would be represented as a stack of layers with raster versions for each of the pieces that can't be rendered together.

Why might this happen? Well, for example, you can have a layer that is in a normal blend mode, has an inner bevel and has a drop shadow that's in Soft Light blend mode. In this case, you could render the inner bevel into the filtered version of the layer, as it's clipped by the pixels of the layer it's attached to, but the drop shadow, being in a different blend mode, couldn't be rendered into the layer in a way that wouldn't change the appearance of the document.

Make sense?

_troy

On Mar 21, 2014, at 11:13 PM, Gus Mueller <g...@flyingmeat.com> wrote:

On Mar 21, 2014, at 12:19 PM, Troy Gaul <troy...@gmail.com> wrote:

In actuality, storing a single composite of a filtered layer isn't necessarily practical by itself, depending on what you want that feature to work with.

If you look at Layer Effects in Photoshop, for example (assuming you want to encompass these). In Photoshop the command to generate layers from layer effects will emit multiple additional layers above and/or below the layer they were attached to (and potentially grouped into a clipping group with them). This is necessary in some cases due to the layer effects using different blending modes than the base layer.

You lost me on both parts :)

A single layer in PS can generate multiple layers out of it?  As in, they would show up in the layers list?

I’m talking about Layer Effects in Photoshop. Drop Shadow, 

[Troy Gaul]

Attachment seems to be missing. The layer style dialog is here:

    https://dl.dropboxusercontent.com/u/57404/layer-effects.png

_troy