Texture data in ZIP archive

[Jesse McGatha]

I mentioned this in another thread, but I think it is worth calling out on its own. The current spec requires inlining all textures as encoded data in the XML. To achieve the compression benefits cited in the spec, you have to compress the ZIP item. However, this will cause the encoded data (which was already compressed), in many cases, to grow in size, creating a noticeable counter-effect in compressibility.

 

As I've mentioned in the other thread, allowing the texture data to exist as a separate ZIP item in the archive, referenced within the AMF markup, would gain the performance benefit of not encoding the binary image data in the first place, but would also allow the texture ZIP items to specify a different compression option (uncompressed) compared to the main body of the AMF XML, which would be compressed.

 

-Jesse McGatha

[Far McKon]

One of the things we are doing with .thing meta-format (multi file zipped together STL Wrapper) is to have any key try to :

a) resolve to a filename in the zip, and load that file if the field can accept it
b) resolve to another section of the .thing json file, if the reading software knows how to read it
c) fall back to a text value, use that if possible
d) have a specified expected default value of a,b,c fail.

IMHO I think this might be a good approach for AMF as well.

That said, .thing has problems, like being JSON (where most JSON readers must read the whole file to parse). Timber in mine own eye, and such.
- Far

> --
> You received this message because you are subscribed to the Google Groups "STL 2.0" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/stl2/-/cS_GHD-gOU4J.
> To post to this group, send email to st...@googlegroups.com.
> To unsubscribe from this group, send email to stl2+uns...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/stl2?hl=en.

[Hod Lipson]

Including texture data as a separate file is a good idea. It will help with compression and will simplify situations where multiple files use the same texture. It’s a bit like whether or not to embed fonts in a PDF.

 

During the initial discussions of AMF we actually were planning to allow the AMF file to refer to external sources such as images, textures, and material, just like HTML refers to external images. We can still do it if we decide to.  The objection that several people raised was that this can cause some ambiguity, which in the world of manufacturing is a big concern.

 

My suggestion would be to hold off on this for now until we get some traction. But if others think it’s a good idea to include it now, I would like to hear.

 

--hod

--

[Jonathan Hiller]

First, the texture data embedded in the AMF xml is NOT compressed. It
is encoded in Base64 which is binary data that simply limits itself to
a subset of ascii characters compatible with xml. This actually
increases the number of bytes (opposite of compression) and shouldn't
significantly affect its later compressibility in a binary zip'd amf.

Like Hod says we supported external textures in an early version of
the spec. I think as developers we like the granularity of having our
texture files separate. In compressed amf form (zip archive) this
would be fine. However, if we maintain support for uncompressed amf,
can you imagine how many times an end user would forget to copy the
separate texture file(s) alongside the ascii amf when they go to print
or upload to a service bereau?. From an end user perspective I don't
see how we can both maintain uncompressed amf as a usable option and
allow external textures.

~J

On Wed, Jan 16, 2013 at 9:26 AM, Hod Lipson <hod.l...@cornell.edu> wrote:
> Including texture data as a separate file is a good idea. It will help with
> compression and will simplify situations where multiple files use the same
> texture. It’s a bit like whether or not to embed fonts in a PDF.
>
>
>
> During the initial discussions of AMF we actually were planning to allow the
> AMF file to refer to external sources such as images, textures, and
> material, just like HTML refers to external images. We can still do it if we
> decide to. The objection that several people raised was that this can cause
> some ambiguity, which in the world of manufacturing is a big concern.
>
>
>
> My suggestion would be to hold off on this for now until we get some
> traction. But if others think it’s a good idea to include it now, I would
> like to hear.
>
>
>
> --hod
>
>
>
> From: st...@googlegroups.com [mailto:st...@googlegroups.com] On Behalf Of
> Jesse McGatha
> Sent: Wednesday, January 16, 2013 7:53 AM
> To: st...@googlegroups.com
> Subject: Texture data in ZIP archive
>
>
>

[Jesse McGatha]

On Thursday, January 17, 2013 7:58:30 AM UTC-8, Jonathan Hiller wrote:

First, the texture data embedded in the AMF xml is NOT compressed. It
is encoded in Base64 which is binary data that simply limits itself to
a subset of ascii characters compatible with xml. This actually
increases the number of bytes (opposite of compression) and shouldn't
significantly affect its later compressibility in a binary zip'd amf.

 

Ah! I had remembered it being a base64 encoded png rather than a bitmap. The greater file size, however, continues to be a processing burden on those who do not need or use the texture info.

 

Like Hod says we supported external textures in an early version of
the spec. I think as developers we like the granularity of having our
texture files separate. In compressed amf form (zip archive) this
would be fine. However, if we maintain support for uncompressed amf,
can you imagine how many times an end user would forget to copy the
separate texture file(s) alongside the ascii amf when they go to print
or upload to a service bereau?. From an end user perspective I don't
see how we can both maintain uncompressed amf as a usable option and
allow external textures.

 

I agree that in a loose-file situation this can become problematic. I would resolve this by saying that uncompressed AMF must inline all texture data. In compressed form the texture data may refer only to another ZIP item in the same container. I don't see how there can be "ambiguity" here. It is always clear when the data is missing and the service bureau can refuse to accept such an upload, requiring the user to re-submit correctly.

 

-Jesse McGatha