Leonard Rosenthol wrote:
At 6:29 PM +0200 8/14/03, Øyvind Kolås wrote:
Then you jsut want to be able to understand the XML file, which is the
reason I proposed using something like xml in the first place, the rest
of the logic would then be contained in your application.
Well, yes, I
Leonard Rosenthol wrote:
At 8:47 AM -0700 8/12/03, Nathan Carl Summers wrote:
This is what I mean by a standard that people can have confidence in --
people should trust that if their program writes good XCF's that a good
program will be able to read it.
Right!
If a program writes GOOD
[EMAIL PROTECTED] (2003-08-21 at 1016.13 -0400):
At 11:42 PM -0700 8/13/03, Manish Singh wrote:
Supports IEEE floats, but not float16 (a 32-bit float cut in half). RH
added this to filmgimp since they had established this format in their
workflow with other tools already.
Why would you only use
On Thu, 14 Aug 2003, Øyvind Kolås wrote:
* Adam D. Moss [EMAIL PROTECTED] [030814 09:59]:
Stephen J Baker wrote:
So, I think what is needed to make a reliable file format is to provide
a well written library for reading and writing the files that's freely
available and properly
Guillermo S. Romero / Familia Romero wrote:
To some extent, it reminds me of the Blender format (with the add on
that Blender files are 64 or 32 bit, little or big endian, and all the
plataforms can load them fine... Adam will love it :] ).
I wrote a Blender file reading C library as part of
my
* Leonard Rosenthol [EMAIL PROTECTED] [030814 18:06]:
At 4:41 PM +0200 8/14/03, Øyvind Kolås wrote:
The baseline GEGL library will be exactly the baseline functionality
needed to be able to something useful with the file,. compositing the
layers, layer groups, and effect layers into a single
Austin Donnelly wrote:
How is the serialization done then, just a raw 32-bit IEEE float
dump with a predefined endianness? 64-bit doubles just as easy?
The real problem comes when your code is running on a system without IEEE
float support, and you need to manually convert from IEEE float to your
On Mon, 11 Aug 2003, Adam D. Moss wrote:
Nathan Carl Summers wrote:
On Mon, 11 Aug 2003, Adam D. Moss wrote:
IIRC, the Loki guys. Some ramblings a few years ago on the
problems of interoperability of game data between
windows/mac/linuxx86/linuxalpha/etc over network and on disk.
They made
At 10:06 AM +0200 8/14/03, Øyvind Kolås wrote:
Which is why I in an earlier mail suggested developing a GEGL file format
that gimp could extend and use a subset of. By doing it this way, gegl
would be the aforementioned file loading, and compositing library,.
But that seems like an EXTREMELY
Stephen J Baker wrote:
Austin Donnelly wrote:
How is the serialization done then, just a raw 32-bit IEEE float
dump with a predefined endianness? 64-bit doubles just as easy?
The real problem comes when your code is running on a system without IEEE
float support, and you need to manually
At 7:52 PM +0200 8/14/03, Guillermo S. Romero / Familia Romero wrote:
The spec is only updated every 18-24 months when Adobe
releases a new version of Photoshop - so you definitely don't wait
for that! As for the other, yes, that is true you could wait, but
nobody does...
Where are those
On Mon, 11 Aug 2003, Guillermo S. Romero / Familia Romero wrote:
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700):
Portable XCF would use a chunk system similar to PNG, with two major
differences. First, chunk type would be a string instead of a 32-bit
value. Second, chunks can contain an
How is the serialization done then, just a raw 32-bit IEEE float
dump with a predefined endianness? 64-bit doubles just as easy?
Yup.
The real problem comes when your code is running on a system without IEEE
float support, and you need to manually convert from IEEE float to your
local
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700):
7 able to support many color depth and spaces
PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other
IIRC (did I read the spec wrongly maybe?) the upper limit is RGBA with
16 bit per channel, no arbitrary color spaces or data
Nathan Carl Summers wrote:
On Mon, 11 Aug 2003, Adam D. Moss wrote:
IIRC, the Loki guys. Some ramblings a few years ago on the
problems of interoperability of game data between
windows/mac/linuxx86/linuxalpha/etc over network and on disk.
They made a special point of saying something like 'never,
On Tue, 12 Aug 2003, Austin Donnelly wrote:
How is the serialization done then, just a raw 32-bit IEEE float
dump with a predefined endianness? 64-bit doubles just as easy?
Yup.
The real problem comes when your code is running on a system without IEEE
float support, and you need to
At 6:29 PM +0200 8/14/03, Øyvind Kolås wrote:
Then you jsut want to be able to understand the XML file, which is the
reason I proposed using something like xml in the first place, the rest
of the logic would then be contained in your application.
Well, yes, I need to understand the FILE
At 4:41 PM +0200 8/14/03, Øyvind Kolås wrote:
The baseline GEGL library will be exactly the baseline functionality
needed to be able to something useful with the file,. compositing the
layers, layer groups, and effect layers into a single image. And in that
process handling the various kinds of
At 8:47 AM -0700 8/12/03, Nathan Carl Summers wrote:
This is what I mean by a standard that people can have confidence in --
people should trust that if their program writes good XCF's that a good
program will be able to read it.
Right!
If a program writes GOOD XCF...
As long as a program
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700):
Portable XCF would use a chunk system similar to PNG, with two major
differences. First, chunk type would be a string instead of a 32-bit
value. Second, chunks can contain an arbitrary number of subchunks, which
of course can contain subchunks
* Leonard Rosenthol [EMAIL PROTECTED] [030814 16:33]:
At 10:06 AM +0200 8/14/03, Øyvind Kolås wrote:
Which is why I in an earlier mail suggested developing a GEGL file format
that gimp could extend and use a subset of. By doing it this way, gegl
would be the aforementioned file loading, and
* Adam D. Moss [EMAIL PROTECTED] [030814 09:59]:
Stephen J Baker wrote:
So, I think what is needed to make a reliable file format is to provide
a well written library for reading and writing the files that's freely
available and properly maintained on every modern platform FROM DAY ONE.
I
* Nathan Carl Summers [EMAIL PROTECTED] [030813 15:39]:
dunno why an editor should do progressive load. Load smaller res in
case of problem? I would try to avoid that instead of try to fix it,
with proper storage and transmission. Load with proxy images? Too
rough, IMO, it is not a scaled
[EMAIL PROTECTED] (2003-08-14 at 1440.34 -0400):
The updates were originally done as technical notes, now they
are incorporated into the main TIFF v7 spec which is part of the
Photoshop SDK.
They seem to be very friendly and open about it:
From
Stephen J Baker wrote:
So, I think what is needed to make a reliable file format is to provide
a well written library for reading and writing the files that's freely
available and properly maintained on every modern platform FROM DAY ONE.
I agree with this -- I think it's really important.
Nick Lamb wrote:
On Sun, Aug 10, 2003 at 03:02:41AM +0100, Adam D. Moss wrote:
Another data point is that floats are just a bastard to serialise
in a portable, precise manner. Personally I'd represent a 32-bit
float with a 32-bit integer and 32-bit fixed-point fractional part.
Redundant but
On Mon, 11 Aug 2003, Adam D. Moss wrote:
IIRC, the Loki guys. Some ramblings a few years ago on the
problems of interoperability of game data between
windows/mac/linuxx86/linuxalpha/etc over network and on disk.
They made a special point of saying something like 'never, ever
serialize
Guillermo S. Romero / Familia Romero wrote:
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700):
7 able to support many color depth and spaces
PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other
IIRC (did I read the spec wrongly maybe?) the upper limit is RGBA with
16 bit per
[EMAIL PROTECTED] (2003-08-09 at 1830.56 -0700):
Is there a good reason not to use either PSD or TIFF as the
native format? The only possible argument for either is that Adobe
controls them both. However, I would state that TIFF has pretty much
taken on a life of its own outside
At 7:18 PM +0200 8/10/03, Guillermo S. Romero / Familia Romero wrote:
You are right, PSD is not an option, it would mean always behind Adobe
and never able to include new things.
Agreed...
About TIFF, every now and then someone appears with an horror story about TIFF
files, so while better than
30 matches
Mail list logo
