Re: proposed solution to 64k image limitation
On Mon, Mar 10, 2003, Bill Janssen wrote: > * I think I'd pick 80x80 as the default chunk size. That will waste memory; 80x80 might be OK at 16bpp, but I think the default size should be calculated in the parser and use bigger chunk sizes for lower bitdepths. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
A couple of points: * I'd like to include other elements of an image in the new multi-part image record, such as the ALT tag, and perhaps a CAPTION text as well. * Please call it DATA_MULTIIMAGE instead of DATA_MULTIRECORD. * I think I'd pick 80x80 as the default chunk size. Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
> Now comes the problem. I have written the code in the viewer to > support this but I have no idea how to handle support in the python > parser or jpluck. Any volunteers? :) I've been wanting to do this for years, so let's discuss the format a bit more, and meanwhile I'll get started on the parser changes. Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
> I have a fuzzy memory of Bill mentioning on the list that the parser had the > capacity to crop > out a specified section of an image (in the capacity to crop to some 150x150 part of > a big > image and show it on the palm, instead of shinking the whole image to 150x150). I > think that is > what it was about. Here is the message I was thinking of: Yes, it works with the SECTION keyword, so that will crop out a 150x150 pixel area starting at x=303,y=168 (from the top left corner). Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Mon, Mar 10, 2003 at 11:05:45AM -0700, Adam McDaniel wrote: > Laurens, can you mock up any old .pdb as I described in > > http://lists.rubberchicken.org/pipermail/plucker-dev/2003-March/001941.html > > Just make sure that it has an example a multirecord image inline as > well as when you click onto it it tries to load it up directly. As > soon as you can do that, I'll mock up the viewer to support this > method with both inline and fullscreen images. Better yet, let me mock up a viewer with what I think would work out for this, plus I'll include some excessive debugging info. I'll whip this up tonight -- Adam McDaniel Array.org Calgary, AB, Canada ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
> This means the user has to pass a target resolution to the parser. Which is exactly why I suggested doing it in the viewer directly. d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Mon, Mar 10, 2003 at 06:37:59PM +0100, Laurens M. Fridael wrote: > After experimenting some more it seems that this method doesn't work > reliably. Placing the images next to each other only works reliably if you > know the exact amount of available horizontal space at that specific point > in the text record *in advance*. This means the user has to pass a target > resolution to the parser. Furthermore, horizontal space is influenced by > horizontal margins and the presence (or lack thereof) of the scrollbar. This > makes things way too complicated for the parsers so I think a dedicated > composite image record is called for. Agreed. Besides, as Michael mentioned earlier that this metiod would work fine for inlined images but when viewing them directly it won't work. It would be best off just to make both inline and fullscreen images use the same record to maintain consistency. Plus, what if there is text before or after the image? If its just a parser-only split image then the beginning or end piece might be out of alignment. By telling the viewer 'These pieces are to remain intact' the viewer can take steps accordingly to maintain that. As for Michael's problem of "this worked for inliend, but what about fullscreen?" .. I do have a potential solution for that as well. It'll actually work easily under OS5 devices becuase of BmpCreateV3Bitmap() but for pre-OS5 there will be a little more work involved. Laurens, can you mock up any old .pdb as I described in http://lists.rubberchicken.org/pipermail/plucker-dev/2003-March/001941.html Just make sure that it has an example a multirecord image inline as well as when you click onto it it tries to load it up directly. As soon as you can do that, I'll mock up the viewer to support this method with both inline and fullscreen images. Thanks :) -- Adam McDaniel Array.org Calgary, AB, Canada ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
Laurens M. Fridael wrote: Michael Nordström wrote: Actually, I think it would be possible to support "large" inlined images without making any changes to the viewer. If the parser would split the image and include the different parts in the Plucker document as several "normal" images after each other then the viewer wouldn't require any changes to support the large inlined image. Each individual image part would link to the same large pannable image. Funny, I was thinking along those lines as well. I've prepared two examples that illustrate this: http://jpluck.sourceforge.net/download/baboon.png.pdb (300x300x16bpp) http://jpluck.sourceforge.net/download/cat.png.pdb (300x449x16bpp) Wow, these look beautiful on my CLIE. So in theory if the image is too wide, the parser could chop up a very large image into squares and place it into a table? That wouldn't require any changes to the existing parser(assuming tables work). Very cool Taras ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
I wrote: > The method I used slices the image down and places the segments next > to each other. This should work well in conjunction with horizontal > aligment. The problem is that the images display well only on a > particular resolution. If you try to view the examples on 160x160 the > image will be chopped up. The scrollbar also affects the available > horizontal space. After experimenting some more it seems that this method doesn't work reliably. Placing the images next to each other only works reliably if you know the exact amount of available horizontal space at that specific point in the text record *in advance*. This means the user has to pass a target resolution to the parser. Furthermore, horizontal space is influenced by horizontal margins and the presence (or lack thereof) of the scrollbar. This makes things way too complicated for the parsers so I think a dedicated composite image record is called for. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
Michael Nordström wrote: > Actually, I think it would be possible to support "large" inlined > images without making any changes to the viewer. If the parser would > split the image and include the different parts in the Plucker > document as several "normal" images after each other then the viewer > wouldn't require any changes to support the large inlined image. Each > individual image part would link to the same large pannable image. Funny, I was thinking along those lines as well. I've prepared two examples that illustrate this: http://jpluck.sourceforge.net/download/baboon.png.pdb (300x300x16bpp) http://jpluck.sourceforge.net/download/cat.png.pdb (300x449x16bpp) As the resolutions indicate these PDBs are meant for hires devices. I've run them in the CLIE hires emulator (not having a hires device myself) and they look very pretty there. The method I used slices the image down and places the segments next to each other. This should work well in conjunction with horizontal aligment. The problem is that the images display well only on a particular resolution. If you try to view the examples on 160x160 the image will be chopped up. The scrollbar also affects the available horizontal space. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Mon, Mar 10, 2003, Michael Nordström wrote: > I'm not sure you would even have to use a list to implement this... Actually, I think it would be possible to support "large" inlined images without making any changes to the viewer. If the parser would split the image and include the different parts in the Plucker document as several "normal" images after each other then the viewer wouldn't require any changes to support the large inlined image. Each individual image part would link to the same large pannable image. However, to support the much larger pannable image would require changes to the viewer, too. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003, Adam McDaniel wrote: > I've attached a diff as a preliminary implementation of > horizontally layering images. But that code only handles *inlined* images. An inlined image is not a problem, since you only draw the image and then "forget" it. However, to handle the large pannable version you would need something else and that is what I'm talking about. You can see my suggestion at http://www.plkr.org/list/2Q2000/0132.html Keep in mind that it was written in June 2000 and the idea would most likely need some changes... > Fortunatly, I see no reason as of why this would take up any more > memory this way then if there were actually that many images nativly > references in the document itself..., other than the linked list but > that's only temporary. The images don't take up any extra memory at all, since we don't have to "remember" anything for inlined images. I'm not sure you would even have to use a list to implement this... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, 9 Mar 2003 18:40:26 -0500 (EST), "David A. Desrosiers" <[EMAIL PROTECTED]> wrote: > Another idea comes to mind... how about having images in one pdb, >and the textual content in another? This would have a few advantages (and >one disadvantage, more "crumbs" to clean up at doc-deletion time), however, >we can create a parser that can put the images into the second "image" >database compressed and in "raw" format, as if they were an ogg file sitting >on an SD card, and read them block by block, instead of storing them as Palm >records themselves. If you require a user who wants images >60kb to put them on a memory card, then you can even just copy the jpeg file directly from the web site to the memory card. For example, CrsImageView and some other apps can read jpeg files if they are on memory cards... -- Cheers, Ken [EMAIL PROTECTED] ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
> So in effect Adam's solution has the limitation that images can only be > 30K pixels wide in the most extreme case(with 16bpp). That's about 9 > screens across on a high-res device. Images this wide will lead to > gigantic PDBs, so in practice you won't even go near this limit. Anyway, > you're calling the shots here. Another idea comes to mind... how about having images in one pdb, and the textual content in another? This would have a few advantages (and one disadvantage, more "crumbs" to clean up at doc-deletion time), however, we can create a parser that can put the images into the second "image" database compressed and in "raw" format, as if they were an ogg file sitting on an SD card, and read them block by block, instead of storing them as Palm records themselves. I've never implemented something like this, but not all data accessible on a Palm has to be in Palm Record format. We could then also deal with the dynamic "chunking" viewer code I've just suggested in my previous message to read the text content from the first database (or even text plus images <64k) and then the large "pannable" images from the image database, for images which are >64k. d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
> Then what's the maximum width of an image? I've loaded a 2000x30x8bpp > (60K) image and it displays well. It's just an image record, i.e. not an > embedded image. More importantly, how do apps like FireViewer and others view images which are 2000x2000x16bpp on the Palm? What magic are they using to get around the 64k limitation? How about if we use the 160x160 (or viewport size on a hires device) and use that as our "chunk" point in an image. Let's say you have a 320x320 image you want to display. it would look like this (pardon the ascii art): .--. | .--. | | | | | : | | chunk 1 | | chunk 2 : | | | | : | | | | : | | | | : | |__| | : |__| |___|: : :: : :: : chunk 3 : chunk 4 : : :: :...:: If we take what would exist in 'chunk 1' and split that up using Adam's original format, then do the same (dynamically? blit offscreen?) with 'chunk 2' if they pan left (to move 'chunk 2' left into the "view"), and so on if they pan up (to bring 'chunk 4' into the "view", ad nauseum. I see where the issue about splitting images can get into place here, but... this is a problem at _decompression time_. What if we stored the images themselves, compressed, at 60k or whatever the current limit is (based on rle, etc. compression being used) then apply the chunking part in the _viewer_ and not pre-chunked in the parser? I see one good reason to do it this way; beamed content. If I have a hires device, with a 320x320 screen, and parse my content desktop-side with the modified "chunking parser", and then beam that content over to someone with a Palm III for example (160x160, low internal storage memory, etc.) would it not cause problems for them to uncompress and read that same image? If it was in the viewer, the viewer could check the device, and "chunk" accordingly. This is just one idea of course, but obviously it can be done. I've got huge maps of Boston and New York here on my Palm which pan and zoom fine in FireViewer and other apps, and the panning/zooming is smooth, very smooth. d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003 at 09:27:43PM +, Michael Nordström wrote:
> I know from past experience that Adam has a different view than me
> when it comes to the viewer's memory use; IMO, we should use as
> little memory as possible to be able to support also older devices
> and not only the latest and greatest ;-)
Thanks alot.. :) .. I've attached a diff as a preliminary
implementation of horizontally layering images. Obviously it would
need to be re-worked for my revision (the squares) but this idea would
be the same.
Fortunatly, I see no reason as of why this would take up any more
memory this way then if there were actually that many images nativly
references in the document itself..., other than the linked list but
that's only temporary.
By the way, I doubt if this code actually works, as well even if it
did it certainly isn't optimized .. You'll get the basic idea..
Index: document.h
===
RCS file: /cvs/plucker/plucker_src/viewer/document.h,v
retrieving revision 1.41
diff -u -r1.41 document.h
--- document.h 29 Jan 2003 15:16:15 - 1.41
+++ document.h 9 Mar 2003 21:33:14 -
@@ -42,7 +42,8 @@
DATATYPE_STYLE_SHEET= 11,
DATATYPE_FONT_PAGE = 12,
DATATYPE_TABLE = 13,
-DATATYPE_TABLE_COMPRESSED = 14
+DATATYPE_TABLE_COMPRESSED = 14,
+DATATYPE_MULTIRECORD= 15
} PluckerDataType;
Index: image.c
===
RCS file: /cvs/plucker/plucker_src/viewer/image.c,v
retrieving revision 1.53
diff -u -r1.53 image.c
--- image.c 22 Feb 2003 13:52:27 - 1.53
+++ image.c 9 Mar 2003 21:33:15 -
@@ -29,6 +29,7 @@
#include "genericfile.h"
#include "history.h"
#include "hires.h"
+#include "list.h"
#include "mainform.h"
#include "os.h"
#include "paragraph.h"
@@ -67,6 +68,11 @@
* Local Functions
*
***/
+static void DrawMultiInlineImage( const Header* imageRecord,
+const TextContext* tContext, Int16* width ) IMAGE_SECTION;
+static void GetMultiImageMetrics( const Header* imageRecord, Int16* width,
+Int16* height ) IMAGE_SECTION;
+static LinkedList ReadMultiRecord( const Header* multiRecord ) IMAGE_SECTION;
/***
@@ -184,6 +190,10 @@
imagePtr = (BitmapType*) ( imageRecord + 1 );
break;
+case DATATYPE_MULTIRECORD:
+DrawMultiInlineImage( imageRecord, tContext, width );
+/* FALLTHROUGH */
+
default:
MemHandleUnlock( imageHandle );
FreeRecordHandle( &imageHandle );
@@ -229,6 +239,33 @@
+static void DrawMultiInlineImage
+(
+const Header* imageRecord,
+const TextContext* tContext,
+Int16* width
+)
+{
+LinkedList referenceList;
+Int16* reference;
+
+referenceList = ReadMultiRecord( imageRecord );
+reference = ListFirst( referenceList );
+while ( reference != NULL ) {
+Int16 singleWidth;
+
+DrawInlineImage( *reference, tContext, &singleWidth );
+*width += singleWidth;
+
+ListTakeOut( referenceList, reference );
+SafeMemPtrFree( reference );
+reference = ListNext( referenceList, reference );
+}
+ListRelease( referenceList );
+}
+
+
+
/* Get the height and width of the image */
void GetImageMetrics
(
@@ -297,6 +334,10 @@
imagePtr = (BitmapType*) ( imageRecord + 1 );
break;
+case DATATYPE_MULTIRECORD:
+GetMultiImageMetrics( imageRecord, width, height );
+/* FALLTHROUGH */
+
default:
MemHandleUnlock( imageHandle );
FreeRecordHandle( &imageHandle );
@@ -343,6 +384,35 @@
+static void GetMultiImageMetrics
+(
+const Header* imageRecord,
+Int16*width,
+Int16*height
+)
+{
+LinkedList referenceList;
+Int16* reference;
+
+referenceList = ReadMultiRecord( imageRecord );
+reference = ListFirst( referenceList );
+while ( reference != NULL ) {
+Int16 singleWidth;
+Int16 singleHeight;
+
+GetImageMetrics( *reference, &singleWidth, &singleHeight );
+*width += singleWidth;
+*height += singleHeight;
+
+ListTakeOut( referenceList, reference );
+SafeMemPtrFree( reference );
+reference = ListNext( referenceList, reference );
+}
+ListRelease( referenceList );
+}
+
+
+
/* Optimize an image based upon screendepth and OS */
Boolean OptimizeImage_None
(
@@ -601,3 +671,27 @@
largeImage = false;
}
+
+
+static LinkedList ReadMultiRecord
+(
+const Header* multiRecord
+)
+{
+LinkedList referenceList;
+UInt16 totalP
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003, Laurens M. Fridael wrote: > Images this wide will lead to gigantic PDBs, so in practice you > won't even go near this limit. The difference between Adam's suggestion (based on what he wrote; I haven't seen the code, yet) and my suggestion is not only about the image size, but also about the memory it uses to display the images. Let's say we actually have an image with a width of 30k pixels and e.g. a height of just 100 pixels. To display that image we would have to work with 100 1x30k images at the same time. Now, I haven't seen Adam's code, yet, but I would be surprised if it could handle such a (I admit, exotic:) case... If you split the image in both directions you would be able to display the same large image while using a much smaller amount of memory (hopefully, if my theory works in practice, only the same 60k we use today.) I know from past experience that Adam has a different view than me when it comes to the viewer's memory use; IMO, we should use as little memory as possible to be able to support also older devices and not only the latest and greatest ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003 at 09:16:02PM +0100, Laurens M. Fridael wrote: > So in effect Adam's solution has the limitation that images can only be 30K > pixels wide in the most extreme case(with 16bpp). That's about 9 screens > across on a high-res device. Images this wide will lead to gigantic PDBs, so > in practice you won't even go near this limit. Anyway, you're calling the > shots here. I agree with Mike when he says that I'd be replacing one limitation with another. It may be best off to just split the image up into squares. How about this.. pieces = tbmp size / max memory + 1 (same as before) pieces += pieces % 2 (to make sure we have an even number) The parser then picks some arbitrary values to define the rows and columns. This is pretty much up in the air just as long as the two values multiply together to equal the number of pieces. For example, we find we need 6 pieces, and the parser decides 3 columns and 2 rows. Our image now looks like this: w1w2w3 : : : : : : : : h1 : : : : : : : : : : : : h2 : : : : :_:_:__: w1 = w / columns w2 = w / columns w3 = w / columns + w % columns h1 = h / rows h2 = h / rows + h % rows Ofcourse, DATATYPE_MULTIRECORD would require a header at this point. Lets say.. Columns .. 2 bytes .. Numeric .. Total number of vertical crosssections Rows.. 2 bytes .. Numeric .. Total number of horizontal crossections Then finally a list of 2 byte uids to the actual images, in linear order from left to right, top to bottom. When the viewer attemps to draw the image, it will know how many columns/rows/pieces are involved and can place each individual image in the proper location accordingly. Can this work as a better solution? On Sun, Mar 09, 2003 at 06:17:29PM +, Michael Nordström wrote: > Anyway, your current suggestion will not be used, but don't throw > away the code. Maybe some part of it can be used for a solution that > can handle images that have been split in both directions (maybe you > would even be interested in implementing such a solution?) Still, it > might be a good idea to wait until we know what would be possible to > create in the parser... Well, I guess the reason why I'm spearheading this is becuase I want to get it implemented and out of the way :) I know that plucker itself isn't an image viewer by nature, but could easy be used as one. This is mostly a problem on hires devices becuase of the larger space to draw images.. it would be nice to actually have images that fully utilized the drawing area with the highest bitdepth possible. -- Adam McDaniel Array.org Calgary, AB, Canada ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
Michael Nordström wrote: > Whatever that fits within the 60k limit and has a height of 1 pixel, > i.e. it also depends on the bitdepth how wide the resulting image > can be. > > However, I kind of doubt there are any "interesting" images that have > a height of 1 pixel ;-) So in effect Adam's solution has the limitation that images can only be 30K pixels wide in the most extreme case(with 16bpp). That's about 9 screens across on a high-res device. Images this wide will lead to gigantic PDBs, so in practice you won't even go near this limit. Anyway, you're calling the shots here. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003, Laurens M. Fridael wrote: > Then what's the maximum width of an image? Whatever that fits within the 60k limit and has a height of 1 pixel, i.e. it also depends on the bitdepth how wide the resulting image can be. However, I kind of doubt there are any "interesting" images that have a height of 1 pixel ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
Michael Nordström wrote: > On Sun, Mar 09, 2003, Adam McDaniel wrote: >> Well, I don't see any problem in creating a single image thats 1000 >> pixels wide and 1 high. Ofcourse, the altmaxwidth/altmaxheight value >> would cap any runaway issues like that. > > In other words, you are replacing one limitation with another (i.e. > there is a limit to how wide the image can be.) Then what's the maximum width of an image? I've loaded a 2000x30x8bpp (60K) image and it displays well. It's just an image record, i.e. not an embedded image. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
I have a fuzzy memory of Bill mentioning on the list that the parser had the capacity to crop out a specified section of an image (in the capacity to crop to some 150x150 part of a big image and show it on the palm, instead of shinking the whole image to 150x150). I think that is what it was about. Here is the message I was thinking of: http://www.mail-archive.com/[EMAIL PROTECTED]/msg01864.html Best wishes, Robert ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003, Adam McDaniel wrote: > Well, I don't see any problem in creating a single image thats 1000 > pixels wide and 1 high. Ofcourse, the altmaxwidth/altmaxheight value > would cap any runaway issues like that. In other words, you are replacing one limitation with another (i.e. there is a limit to how wide the image can be.) The only solution that will be added to the viewer is a solution that doesn't add new limitations (except for available memory:) If you check the archive you will see that my suggestion would be able to display images of any size (well, it will be limited by the size of the PDB, i.e. the number of records you can include:) I'm sure my suggestion from back then can be improved (I have learned a few more things about PalmOS programming since June 2000:) I did write some code back then, but since there was no response on the parser side (and I didn't really consider it to be that important to turn the viewer into an image viewer) I "suspended" that work and concentrated on other more important features... I did discuss it with Bill when I met him at PARC in 2001, but I'm not sure if he has put any more work into that particular feature (I haven't). Anyway, your current suggestion will not be used, but don't throw away the code. Maybe some part of it can be used for a solution that can handle images that have been split in both directions (maybe you would even be interested in implementing such a solution?) Still, it might be a good idea to wait until we know what would be possible to create in the parser... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003 at 03:01:53PM +, Michael Nordström wrote: > On Sun, Mar 09, 2003, Adam McDaniel wrote: > > Now comes the problem. I have written the code in the viewer to > > support this but I have no idea how to handle support in the python > > parser > > Hmm, I can see more problems than just to make the parser split up the > image; what if I have an image that is VERY wide? You solution depends > on the width being of a "reasonable" size. Well, I don't see any problem in creating a single image thats 1000 pixels wide and 1 high. Ofcourse, the altmaxwidth/altmaxheight value would cap any runaway issues like that. > I suggested a solution to this problem in June 2000, but (just as in > your case) I needed a parser that could split the image into smaller > parts... Hence my email out to the list :) Here's some more details on DATATYPE_MULTIRECORD as a data record: uid = unique ID paragraphs = always 0 size = number of pieces of the image multiplied by 2 type = DATATYPE_MULTIRECORD (ie, 15) Then the data would be a direct list of uids, one after another, two bytes each. Do you think that might be too simple? In other words, should there be like a MultirecordType structure header to preceed the data that contains a bit more detailed information? -- Adam McDaniel Array.org Calgary, AB, Canada ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003, Adam McDaniel wrote: > Now comes the problem. I have written the code in the viewer to > support this but I have no idea how to handle support in the python > parser Hmm, I can see more problems than just to make the parser split up the image; what if I have an image that is VERY wide? You solution depends on the width being of a "reasonable" size. I suggested a solution to this problem in June 2000, but (just as in your case) I needed a parser that could split the image into smaller parts... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
