You are right - streaming will allow receivers to begin processing before the entire file transfer is complete.
My experience is, however, that the parsing time (~ 6 seconds per 1M triangles in AMF) is orders of magnitude smaller than processing time (e.g. geometric slicing).
But the cost of not having compression is detrimental, in terms of usability. File size is a major and growing concern.
In short, leaving compression out of the standard would be a mistake in my opinion, as it will encourage producers to produce large uncompressed files, and will create ambiguity as to who is responsible for compressing them. Most users don't care - they just need small files.
Whether or not it is zip or libz or something else is a good question. We chose zip because it is accessible to most non-experts and is widely used (I would argue it is the most common compression scheme). Non-experts would need this only if they wish to directly create a file themselves, something that was easily possible with STL and contributed to is adoption. But we could debate this.
If you enforce compression in the standard, the AMF producing tool
has to provide the file compression, so it's always available,
independently of what the operating system provides. Same for the AMF
reading tool.
--
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/-/1t2oyPXzl1YJ.
You really should consider detaching the compression from the text standard. It really should be a wrapper.
Also, it seems people in the group quote existing tool preferences and market shares to support arguments. Note that this technology changes quickly. Consider the browser market. A few years ago most browsers where IE. Now it has all changed.
--
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/-/kELp3bfWCTAJ.
I think compression is critical – if CAD systems will produce uncompressed AMF in any but the simplest files, the format will be impractical, no matter how good the rest of it is. And if its going to be compressed, we should specify exactly how so that there is no ambiguity, and I would go with something popular and stable, like zip.
BTW STL also had an ascii and binary version with the same extension, and most readers and users had no problem dealing with both.
--hod
From: st...@googlegroups.com [mailto:st...@googlegroups.com] On Behalf Of Jacob Barhak
Sent: Monday, January 21, 2013 12:57 PM
To: st...@googlegroups.com
Subject: Re: AMF Container Format - zip or no zip?
Hi Jesse,
I agree with this. It's true that there's effectively no cost to
implementing the check for 'PK', but even just allowing for uncompressed
AMF will lead to actual uncompressed AMFs out there. I don't think
anybody wants that.
--
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/-/2bQi4GB5Vs8J.
Here are a few data points:
Compressed AMF is approximately 20 times smaller than uncompressed AMF .
Compressed AMF is about half the size of compressed binary STL
A typical file with 1 million triangles will be 200MB uncompressed AMF, or about 10MB compressed AMF.
(This means that for most people, an uncompressed AMF cannot be emailed; a compressed file can.)
Bottom line, I think we should stick to zip compression for practical reasons, even though from an academic point of view I agree that compression is a separate issue. Compressed XML decouples these two design goals as much as possible.
I also agree with BobC that at this point we should wait for AMF adoption before improving it.
--hod
Hod Lipson
Associate Prof. of Mechanical & Aerospace Engineering and Computing & Information Science
Cornell University, 242 Upson Hall, Ithaca NY 14853, USA
Office: (607) 255 1686 Lab: (607) 254 8940 Fax: (607) 255 1222
Email: Hod.L...@cornell.edu
Web: http://www.mae.cornell.edu/lipson
Administrative Assistant: Craig Ryan cd...@cornell.edu, (607) 255-6981, Upson 258
From: st...@googlegroups.com [mailto:st...@googlegroups.com]
On Behalf Of BobC
Sent: Monday, January 21, 2013 5:28 PM
To: st...@googlegroups.com
Subject: Re: AMF Container Format - zip or no zip?
This is an interesting one, I have been unsure which side of the fence to be on. I think that in principle compactness should be a fundamental part of the spec (like in JPEG), or not at all (like in HTML).
--
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/-/2bQi4GB5Vs8J.
<ccjohn.vcf>
Hi Jacob,
The decision to change or extend the standard is carried out by voting by the members of the ASTM F42 “Additive Manufacturing” group.
Anyone can propose a change; and anyone can join the group and vote. Every company gets one vote regardless of how many representative members it has.
(see ASTM protocol for details).
In case you are wondering, I have volunteered to lead the discussion but I have no final say on what gets proposed or approved or not.
--hod
Hod Lipson
Associate Prof. of Mechanical & Aerospace Engineering and Computing & Information Science
Cornell University, 242 Upson Hall, Ithaca NY 14853, USA
Office: (607) 255 1686 Lab: (607) 254 8940 Fax: (607) 255 1222
Email: Hod.L...@cornell.edu
Web: http://www.mae.cornell.edu/lipson
Administrative Assistant: Craig Ryan cd...@cornell.edu, (607) 255-6981, Upson 258
From: st...@googlegroups.com [mailto:st...@googlegroups.com]
On Behalf Of Jacob Barhak
Sent: Wednesday, January 23, 2013 5:04 PM
To: st...@googlegroups.com
Subject: Re: AMF Container Format - zip or no zip?
Hi Hod,
Visit this group at http://groups.google.com/group/stl2?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
I believe that we should generate a new revision soon to (a) clarify curved triangles and (b) provide make the schema official. There are also various minor corrections and clarifications. I can send the word doc for anyone interested to edit (with “track changes” please).
As for the compression, I do not see any consensus for change at this point, so I suggest we leave as is for now.
Once the new revision converges, we post it on the ASTM website and members are notified. They then have a certain period (I think one month) to challenge the changes. Then voting happens. If even one vote is negative, the change doesn’t pass. So it is best to reach a consensus before voting.
I believe that we should generate a new revision soon to (a) clarify curved triangles and (b) provide make the schema official. There are also various minor corrections and clarifications. I can send the word doc for anyone interested to edit (with “track changes” please).
As for the compression, I do not see any consensus for change at this point, so I suggest we leave as is for now.