Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 need to understand the FILE FORMAT...whether that be XML, PNG, TIFF, XCF, etc. But there seems to be a general belief that there should be a standard library for reading/writing the file format to help reduce the issues of multiple implementations. That library shoudl ONLY be a file format handler, it should NOT be all of GEGL... Surely this is a detail, and the important thing, that is using some kind of metadata manifest, with binary image data stored in some widely supproted image format, is something we can agree on? Whether gegl provides a separate libxcf or not is surely a detail that can be taken care of at the implementation stage... That said, since the general idea is to store layer structure in the image data, and use compositing to generate the final image, libxcf would require access to quite a lot of gegl's internal workings most of the time... at least if the destination application wanted to use gegl for composing. Of course, if they wanted to work around gegl, and use a native layer model, then they wouldn't need to get at gegl's graphing stuff at all. But they'd be limiting themselves more or less to stacks, or very simple trees. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 XCF... As long as a program follows the rules, TIFF is compatible. If you break the rules, all bets are off... The difference is that TIFF is read and written by dozens of ad'hoc software packages. Some use 'libtiff' - but most do not. If you look at a format like PNG, hardly anyone reads and writes it using their own code - almost everyone uses libpng - so there are no problems with PNG compatibility. 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. If you then write in the specification document something like: You are strongly encouraged to use the standard file reading/writing library rather than writing your own ...then better still. I don't think it matters very much how the format is specified. The reliability and transportability of the resulting files depends mostly on the quality of the support library. Another problem with TIFF is that it's easy to extend. That sounds like a good idea - there are ways to simply ignore tags that your program doesn't understand - so how bad could that be? Well, if you have programs that invent tags that say things like What follows is a block of pixels in MacPaint format, or If this tag is set, the pixels are stored bottom-to-top instead of top-to-bottom - then ignoring a tag you don't recognise results in a very screwed up image. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
[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 half of a 32bit float?? That reduces your accuracy/precision and makes you incompatible with the rest of the world doing floating point imaging. nVidia graphics hardware uses half-float - it's useful where bandwidth is a premium - such as downloading high dynamic range images into graphics hardware at realtime rates - and in a lot of cases, a half precision float is still very useful. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 maintained on every modern platform FROM DAY ONE. I agree with this -- I think it's really important. [SNIP] but in any case it makes sense to library-ise the XCF load/saver just from a technical abstraction standpoint.) 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,. (e.g. if an application needs to load an XCF2 file, but don't support layers, the library would be capable of compositing it, putting the logic to do compositing of layers, layer groups, adjustment layers, u8, u16, float, double, cmyk, rgb, ycbcr and spotcolors into a file loading library,. makes very little sense It actually makes a lot of sense to have GEGL support loading XCFs. It would probably be a good idea to have a separate library as well, for those apps that already have their own compositors and don't want to have another one as well. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 'day job'... I wouldn't use the word 'love' exactly. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
* 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 image. And in that process handling the various kinds of layers (8bit, 16bit 16bit float, 32bit float, rgb, cmyk etc.) Sure, if I don't already have that type of functionality in my own application that would be useful. But let's say that I am Photoshop or ImageMagick, which already have layer (with effects), a compositing engine, etc. All I want is to load GEGL/GIMP data from disk into my own data structures. I do NOT want/need all of your functionality - just want to read the file! 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. Then only additional kind of logic would then be a small api allowing you to get to each individual file within the archive or directory. -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ [EMAIL PROTECTED],[EMAIL PROTECTED] ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 local weird-ass machine float. Not common, I grant you, but a real pain when it bites. So it's somehow preferable to come up with our own wierd-ass float format and make life equally hard for everyone? By far the vast proportion of modern machines have IEEE float - so let's make life easy for the majority. The minority need a conversion routine no matter what we do. The last machine I used that didn't have IEEE float (some wierd Hitachi microcontroller) had convenient library functions to interconvert between it's native format and IEEE. The only other alternative is to use a storage mechanism for which there is universal conversion support - but the only format that fits that bill is ASCII - surely we aren't contemplating that for bulk image data? Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 a special point of saying something like 'never, ever serialize floats' and it sounded like the voice of experience. Java doesn't seem to have a problem with it. Even poor fools like me who are working on VM's for machines with non-IEEE floats don't have too much of a problem. That's good to know, it helps me out with some of my own stuff... 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. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 heavyweight library to incorporate into a project just for reading/writing files... Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 convert from IEEE float to your local weird-ass machine float. Not common, I grant you, but a real pain when it bites. So it's somehow preferable to come up with our own wierd-ass float format and make life equally hard for everyone? By far the vast proportion of modern machines have IEEE float - so let's make life easy for the majority. The minority need a conversion routine no matter what we do. The last machine I used that didn't have IEEE float (some wierd Hitachi microcontroller) had convenient library functions to interconvert between it's native format and IEEE. I am all for IEEE FP as well. Just as an ilustration, the code I am working on for custom layer modes uses fixed point - 32bit , being 16.16. There are reasons that lead me to choose it, I can comment if it they are of interest to anyone. If the internal image format is 32bit IEEE it will be easy for me to add the needed convertions, as the 8 bit unsigned integer and 16 bit unsigned integer conversions are in place already. The only other alternative is to use a storage mechanism for which there is universal conversion support - but the only format that fits that bill is ASCII - surely we aren't contemplating that for bulk image data? Steve Baker (817)619-2657 (Vox/Vox-Mail) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 arbitrary number of subchunks, which of course can contain subchunks themselves. PNG 32 bit names are char... or at least all them can be read. :] And I think the purpose of this was, among other ideas: easy to parse (always four chars) and makes sense with some rules about chars (caps vs normal). Even the magic of PNG had a reasoning (part binary to avoid confusion with text and capable of detecting non 8 bit transmision or bad byte order). IOW, why not make it similar, but just bigger (four char for name space and 12 more for function)? Arbitrary size strings does not seem a good idea to me. This seems like a good proposal. Another thing, alignment (and thus padding), is worth the problems it could cause? If the format has to be fast, maybe this should be taken into account, and not only about small sizes in memory (ie 32 bit), but maybe disks (ie blocks) or bigger sizes in memory (ie pages) too. Would the format be used just as storage, or would it be used as source / destination when memory is scarce. Remember that some apps are capable of working in areas instead of the full image, to improve global troughput. Right. To be mmappable, the format should be aligned. I think with careful design, there won't be too much overhead from this. When I wrote that the example was just a rough sketch, part of what I meant was that I didn't pay too much attention to bit sizes and alignment, because that would have been premature optimization. One issue with alignment is which platform's alignement rules should be used. I think a good common-denominator format can be found. It won't get the wierd ones, of course. I work on a Cray, and nothing follows cray's alignment rules. :) image data chunks should use png-style adaptive predictive compression. They should also use adam-7. I would avoid compression inside the format. Files can be compressed as a whole It does complicate in-place image manipulation, true. OTOH, you can get much better lossless compression using image-specific techniques such as predictive compression than you can using general purpose techniques. and IIRC Adam7 is about interlacing, not compression, 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 down version. Well, working a scaled-down version of large files is an important optimization. It's true that not all image manipulation functions can credibly be approximated with working on a scaled-down version, but that's for the gegl people to worry about. My guess is that it will be easier to use interlaced data than true scaled-down images, and the savings in terms of computational time and pipeline flexablity will be worth it. PNG compression is the one provided by zlib PNG's use zlib compression on the overall file, but the entropy is first significanty reduced by using predictive encoding. It's not the same as just running gzip on raw data. and I can show you cases in which other compressors have done a better job with my XCF files (anybody can try bzip2), and if computers keep evolving the same way, the extra CPU load is better than the disk or network transfer. True. Letting other apps do it means those apps could be general, reducing work load. Of course, but we should not sacrifice functionality for convenience. :) Or better, custom, but once the look of the data is well known and there is plenty of test cases (like FLAC but for XCF2, compression targeted at some kind of patterns). Conformance testing is very important. That is a good idea. Realize too that this links to aligment things, if you know that a layer is always somewhere and requires X MB, you can overwrite and reread without problems. This will have to be worked out. CHUNK: chunk start, optional - 2 byte bitmask with some png-like flags xcf-comment total size of chunk and subchunks - 4 bytes size of chunk - 4 bytes For all these sizes... why not 64 and be avoid future problems? If someone likes it and uses it for really big things, segmentation is a negative point. Or maybe force a small max size for each chunk (forcing segmentation) which would give more CRCs. Options, options, options... Both have their plusses and minuses. This is the comment chunk end (flags) - 2 bytes xcf-comment 1 (subchunk depth) - 1 byte crc32 - 4bytes [...] I would add unique chunk ID to each, so then can make references. Good idea. So of your list of items, 1 (lossless), 2 (portable), 3 (extensible), 4 (graphs), 7
RE: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 weird-ass machine float. Not common, I grant you, but a real pain when it bites. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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, ever serialize floats' and it sounded like the voice of experience. Java doesn't seem to have a problem with it. Even poor fools like me who are working on VM's for machines with non-IEEE floats don't have too much of a problem. That's good to know, it helps me out with some of my own stuff... How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 manually convert from IEEE float to your local weird-ass machine float. Not common, I grant you, but a real pain when it bites. Well, since my day job is working with a non-IEEE machine, I can tell you about that pain first hand. It probably took about three days to write conversion functions between the native format and IEEE float and double. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 FORMAT...whether that be XML, PNG, TIFF, XCF, etc. But there seems to be a general belief that there should be a standard library for reading/writing the file format to help reduce the issues of multiple implementations. That library shoudl ONLY be a file format handler, it should NOT be all of GEGL... LDR -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 layers (8bit, 16bit 16bit float, 32bit float, rgb, cmyk etc.) Sure, if I don't already have that type of functionality in my own application that would be useful. But let's say that I am Photoshop or ImageMagick, which already have layer (with effects), a compositing engine, etc. All I want is to load GEGL/GIMP data from disk into my own data structures. I do NOT want/need all of your functionality - just want to read the file! Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 follows the rules, TIFF is compatible. If you break the rules, all bets are off... Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
* 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 compositing library,. But that seems like an EXTREMELY heavyweight library to incorporate into a project just for reading/writing files... 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 layers (8bit, 16bit 16bit float, 32bit float, rgb, cmyk etc.) GEGL will by nature be extensible, and able to do more than GIMP initially will use, this is the reason I proposed having different levels of complexity for the graph layout, and restrictions on which kinds of operations should be allowed in the baseline format. If you're calling GEGL EXTREMELY heavyweight, you should be aware that XCF with effect layers is also an EXTEREMLY heavyweight by your standards. -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ [EMAIL PROTECTED],[EMAIL PROTECTED] ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
* 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 agree with this -- I think it's really important. (That's if we either want or expect the new XCF to become a defacto standard in the first place. Personally I'm not sure either way, but in any case it makes sense to library-ise the XCF load/saver just from a technical abstraction standpoint.) 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,. (e.g. if an application needs to load an XCF2 file, but don't support layers, the library would be capable of compositing it, putting the logic to do compositing of layers, layer groups, adjustment layers, u8, u16, float, double, cmyk, rgb, ycbcr and spotcolors into a file loading library,. makes very little sense,.. For those who were not at GimpCon2,. http://phpweb.hig.no/~oey_kola/ccc/ contains three images of how a GEGL compositing graph correlates with the current gimp layer stack,. a layer stack with groups, and a layer stack with some effect/adjustment layers added. /Øyvind K -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ [EMAIL PROTECTED],[EMAIL PROTECTED] ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
* 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 down version. Well, working a scaled-down version of large files is an important optimization. It's true that not all image manipulation functions can credibly be approximated with working on a scaled-down version, but that's for the gegl people to worry about. My guess is that it will be easier to use interlaced data than true scaled-down images, and the savings in terms of computational time and pipeline flexablity will be worth it. Ideally GEGL will collapse all affine transformations, thus doing resampling only once,. that resample should ideally be from the original data, possible being stored in a tile cache for following calculations of the compositing graph. If the ability to directly from file use a scaled-down version of the image one should rather use a specialiced image format storing a image pyramid (sizes 50%, 25%, 12.5%, 6.25%, etc) that allows the gegl faucet node providing the image to use scale factor as a parameter when loading. For general operation this will not be of great importance, and thus a format providing a linear buffer be better. For 8 and 16bit integer data uncompressed png would provide random access if within a container file format. A compressed png file would be a little harder, but by making an intelligent png loader, one could get a row of tiles without much overhead, (uncompressing the preceeding tiles without actually storing the data) /pippin -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ [EMAIL PROTECTED],[EMAIL PROTECTED] ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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. (That's if we either want or expect the new XCF to become a defacto standard in the first place. Personally I'm not sure either way, but in any case it makes sense to library-ise the XCF load/saver just from a technical abstraction standpoint.) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 complete-ish. (Practical better ideas welcomed.) IEEE floats are portable except for the endian issue. 32-bit floating point PCM audio is just IEEE floats prescribed as little (iirc) endian. Where did you get the idea that this was problematic? 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 floats' and it sounded like the voice of experience. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 floats' and it sounded like the voice of experience. Java doesn't seem to have a problem with it. Even poor fools like me who are working on VM's for machines with non-IEEE floats don't have too much of a problem. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
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 channel, no arbitrary color spaces or data formats. You would have to use gray PNGs to assemble other color spaces... and never want 32 int or floats, or use a similar trick than with colour spaces, split data. I think PNG does not fit 7 without tricks. 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 complete-ish. (Practical better ideas welcomed.) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 'Fox News and all the other right-wing pundits thrive by assuring their audiences that they are the real unfortunates, oppressed by problems as varied as big government, liberal media, taxes and the bottom-feeders they serve, car-pool lanes, and France.' ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
