Archived from groups: comp.sys.palmtops.pilot (More info?)

I'm using ZLauncher on my Treo 650. I have a jpeg that I've resized
for use as a background in ZLauncher, and it does work as-is. But I
was wondering if there was any way to convert it to a Palm-native file
and still be used.

The jpeg, on my SD card, is 33k, but copied into the internal memory
it's converted to 209k! Plus, it takes a moment or two for ZLauncher
to read the jpeg, and I'd like to speed that up.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"Nobody wants to fight a war unless they know there's at least a chance
of winning. You can give them that hope. As one of the older races,
your technology has to be at least as good as the Shadows. Now, if you
can convince your government to send out an expedition to engage one or
two of their ships..." "...No." (Capt. Sheridan and Amb. Kosh, B5
"Interludes and Examinations" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan <cspp@gordol.org> wrote:

>The jpeg, on my SD card, is 33k, but copied into the internal memory
>it's converted to 209k!

Wonder what you're using to copy it. I just copied a 23K jpeg from my card to
internal memory using the included Media app (Zire 72) and it was still 23K in
internal memory...

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that AaronJ claimed:

; >The jpeg, on my SD card, is 33k, but copied into the internal memory
; >it's converted to 209k!
;
; Wonder what you're using to copy it. I just copied a 23K jpeg from my card to
; internal memory using the included Media app (Zire 72) and it was still 23K in
; internal memory...

ZLauncher. The jpeg is on the card in
/palm/programs/zlauncher/backimage. Selecting it from within ZLauncher
causes ZLauncher to copy it to RAM. If I de-select it, ZLauncher
removes the copy from RAM.

ZLauncher does not find a jpeg on the internal memory, only on the
card.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"They taught the younger races, explored beyond the rim, created great
empires. But to all things there is an end." (Amb. Delenn, B5 "In The
Shadow Of Z'Ha'Dum" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan <cspp@gordol.org> wrote:

>ZLauncher. The jpeg is on the card in
>/palm/programs/zlauncher/backimage. Selecting it from within ZLauncher
>causes ZLauncher to copy it to RAM. If I de-select it, ZLauncher
>removes the copy from RAM.

Well then, I imagine ZLauncher has a reason for making such a large file. It
does seem odd though. The built in Palm launcher will use my converted 23K file
as a background just fine. Good thing memory isn't the premium it once was...

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that AaronJ claimed:

; Well then, I imagine ZLauncher has a reason for making such a large file. It

Hence why I want to convert it to a Palm native format.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"Oh, by the way, you know what they say Narn taste like?" "Yeah. Like
chicken. Man, I really need a vacation." (Dr. Franklin and Mr.
Garibaldi, B5 "Legacies" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan <cspp@gordol.org> wrote:

>It is alleged that AaronJ claimed:
>
>; Well then, I imagine ZLauncher has a reason for making such a large file. It
>
>Hence why I want to convert it to a Palm native format.

I think we're going in a circle here. You could convert a jpeg file to a Palm
native format file (pdb) simply by using the Media app like I did and it will
create a like sized pdb file that contains the jpeg image in internal memory.
That file can be used by Media as well as the Palm Launcher. But... I doubt that
ZLauncher could see or use it. Unlike a jpeg file which is a universally
understood specialized graphics file, the pdb file can contain *anything*. And
in many (most?) cases only the program that creates it can understand and use
it. That's why I think it's likely that since ZLauncher creates a monster file,
it has other purposes for that file as well as graphics, and you probably won't
have much luck finding another program to create a small pdb background file
that ZLauncher can understand or use...

Archived from groups: comp.sys.palmtops.pilot (More info?)

AaronJ wrote:
> Jeffrey Kaplan <cspp@gordol.org> wrote:
>>It is alleged that AaronJ claimed:

>>; Well then, I imagine ZLauncher has a reason for making such a large file. It

>>Hence why I want to convert it to a Palm native format.

> I think we're going in a circle here. You could convert a jpeg file to a Palm
> native format file (pdb) simply by using the Media app like I did and it will
> create a like sized pdb file that contains the jpeg image in internal memory.
> That file can be used by Media as well as the Palm Launcher. But... I doubt that
> ZLauncher could see or use it. Unlike a jpeg file which is a universally
> understood specialized graphics file, the pdb file can contain *anything*.

Just want to point out that Palm OS supports "File Stream" PDBs. They
are basically a standard way of encapsulating any file into a PDB.
A Palm application can then read it in a way that's similar to how
regular applications (those that run on traditional general-purpose
computers) read a file.

It would thus be possible to convert a JPEG into a PDB in a standard
way that preserves the regular structure of the JPEG file. One could
easily do this with the "par" command line utility, like this:

par c -a stream Whatever.PDB Whatever tttt cccc Whatever.jpg

That command says to put the file Whatever.jpg into the PDB file
Whatever.PDB, to name the database "Whatever" (so that it will show
up as that on the Palm, which never sees the "Whatever.PDB" filename),
and to put 'tttt' as its type and 'cccc' as its creator.

Having said that, just because you can put the JPEG into a PDB in
a standard way does not mean that ZLauncher supports that. In fact,
based on this discussion, it seems like it doesn't.

On that subject, it seems like the original poster wishes for a way
for ZLauncher to convert this JPEG into a Palm-native format, in order
to prevent it from taking up much space. However, it's quite possible
that this is exactly what ZLauncher is, in fact, doing -- converting
the JPEG (an efficient file format) into a native file format. The
Palm image format (a Palm Bitmap) has several different options for
compressing image data, and none of them are anywhere near as
efficient as JPEG is. However, the Palm can draw its native image
format much more quickly than it can draw a JPEG. So, I wouldn't
be surprised if the ZLauncher author has chosen to convert the JPEG
into a native-format Palm Bitmap in order to get the drawing speed
they want.

I especially would not be surprised to hear that considering one
other little fact: when you have a Palm Bitmap that is 320x320
(the size of the scren on the Zire 72) and using 16-bit color
(the color depth that the Zire 72 uses), it will take up 204800
bytes plus a little overhead to store the dimensions and other
info about the bitmap. Since it will have to be broken apart to
be stored in a PDB on the device (since records within a PDB can
only accomodate 64K each), that will add a little more overhead,
and I would not be surprised at all if it worked out to 209K, since
that amounts to 4.5% overhead, which is about what you'd expect,
if you take the approach of expanding the JPEG into an uncompressed
bitmap and putting that in the storage heap (a/k/a "internal memory" )
of the Palm.

- Logan

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that AaronJ claimed:

; >; Well then, I imagine ZLauncher has a reason for making such a large file. It
; >Hence why I want to convert it to a Palm native format.
;
; I think we're going in a circle here. You could convert a jpeg file to a Palm
; native format file (pdb) simply by using the Media app like I did and it will
; create a like sized pdb file that contains the jpeg image in internal memory.
; That file can be used by Media as well as the Palm Launcher. But... I doubt that
; ZLauncher could see or use it. Unlike a jpeg file which is a universally

Which would render it unusable for my purpose wouldn't it? And in any
case, the media manager that came with my Treo 650 doesn't convert
JPEG's to Palm native. The Treo appears to have three types of
internal memory: ROM, regular memory, and media memory. Image files
that I do import into the internal memory, or make with the built-in
camera, cannot be located with a file manager.

; understood specialized graphics file, the pdb file can contain *anything*. And
; in many (most?) cases only the program that creates it can understand and use
; it. That's why I think it's likely that since ZLauncher creates a monster file,
; it has other purposes for that file as well as graphics, and you probably won't
; have much luck finding another program to create a small pdb background file
; that ZLauncher can understand or use...

The back images included in the themes for ZLauncher are PDB files.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"You know back at the station, I was... surprised to see you walk into
the War Room. When an Ambassador comes to visit we usually have some
advanced warning." "There wasn't time. And believe me, my being here
is as much of a surprise to me as it is to you." "Is it?" (Capt.
Sheridan and Amb. Sinclair, B5 "War Without End, Pt. 1" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that Logan Shaw claimed:

; On that subject, it seems like the original poster wishes for a way
; for ZLauncher to convert this JPEG into a Palm-native format, in order
; to prevent it from taking up much space. However, it's quite possible

Whether the conversion is done by ZLauncher automatically, or by me
preemptively, I don't care. I want to have the file converted so that
it takes up less space in main memory, and also hopefully get rid of
the slight delay that occurs when switching to the launcher when the
image is configured as the background. When no image is configured as
a background, switching to new ZLauncher is instantaneous. My
conclusion therefore is that there's a slight delay while it reads the
file. This delay is probably twofold: translating the JPEG and then
reading it.

; I especially would not be surprised to hear that considering one
; other little fact: when you have a Palm Bitmap that is 320x320
; (the size of the scren on the Zire 72) and using 16-bit color
; (the color depth that the Zire 72 uses), it will take up 204800
; bytes plus a little overhead to store the dimensions and other
; info about the bitmap. Since it will have to be broken apart to
; be stored in a PDB on the device (since records within a PDB can
; only accomodate 64K each), that will add a little more overhead,
; and I would not be surprised at all if it worked out to 209K, since
; that amounts to 4.5% overhead, which is about what you'd expect,
; if you take the approach of expanding the JPEG into an uncompressed
; bitmap and putting that in the storage heap (a/k/a "internal memory" )
; of the Palm.

Well, that's technical information I did not previously have. By the
way, this is on the Treo 650. Our displays set of similar resolutions,
but I don't know about our memory structures. The Treo 650 uses a file
system with larger blocks than most other Palm units. The 24 MB of
memory available to the user is roughly equivalent in total storage
capacity to the 16 MB on my previous Palm.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"I warn you Mariel, do not be overconfident. If I were married to
Londo Mollari I'd be concerned." "G'Kar, if you were married to Londo
Mollari, we'd all be concerned." (Amb. G'Kar and Mariel, B5 "Soul
Mates" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan wrote:
> It is alleged that Logan Shaw claimed:

> ; I especially would not be surprised to hear that considering one
> ; other little fact: when you have a Palm Bitmap that is 320x320
> ; (the size of the scren on the Zire 72) and using 16-bit color
> ; (the color depth that the Zire 72 uses), it will take up 204800
> ; bytes plus a little overhead to store the dimensions and other
> ; info about the bitmap. Since it will have to be broken apart to
> ; be stored in a PDB on the device (since records within a PDB can
> ; only accomodate 64K each), that will add a little more overhead,
> ; and I would not be surprised at all if it worked out to 209K, since
> ; that amounts to 4.5% overhead, which is about what you'd expect,
> ; if you take the approach of expanding the JPEG into an uncompressed
> ; bitmap and putting that in the storage heap (a/k/a "internal memory" )
> ; of the Palm.
>
> Well, that's technical information I did not previously have. By the
> way, this is on the Treo 650. Our displays set of similar resolutions,
> but I don't know about our memory structures. The Treo 650 uses a file
> system with larger blocks than most other Palm units.

The bitmap structures are the same. In fact, if you are writing to a
bitmap after you decode a JPEG, you will most likely include some code
from PalmSource called BitmapRsrc into your application to allow you
to manipulate the bitmap. This code will be the same on all devices,
so the 320x320 16-bit bitmap will be the same format on all devices.

The point you make about the NVFS blocksize stuff on Treo 650 is a
good one. The overhead of NVFS probably is part of the overhead that
brings it from 200K even up to 209K. Most likely, the NVFS overhead
isn't that great, because it tends to apply when you have lots of
small records in your PDB. But, if you are storing a big 200K bitmap,
you would most likely just break that up into four pieces of 50K each
or something along those lines. Thus, the only NVFS overhead (besides
fixed per-record overhead) would be the overhead when the roughly 50K
piece you put in the PDB record takes up part of a block and the
other part of that final block (in the record) is wasted. With only
four records, even if you have a Treo without the update that decreases
the block size and still have 512 byte blocks, that's only 2K max of
overhead due to having bigger blocks.

By the way, it seems quite likely that the delay you experience when
you have the background is not from decompressing the JPEG. If you
have a 209K file, it's quite likely that it's totally uncompressed.
The delay is probably due to the fact that after the launcher
starts, this PDB that contains the bitmap is on flash but is not
in RAM. So, the Palm has to read over 200K from flash to RAM before
it can display the image, and that's after the launcher has already
started running (because the PRC for the launcher is loaded all
at once, before the launcher starts).

Ironically, if it were decompressing the JPEG on the fly, it might
actually be faster, or at least no slower: it would have less data
to read from flash, and on a modern device (with JPEG decoding
implemented as a PNO a/k/a ARMlet), decoding a JPEG of that size
might take 1 second or so (depending on the JPEG and such).

- Logan

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan wrote:
> Which would render it unusable for my purpose wouldn't it? And in any
> case, the media manager that came with my Treo 650 doesn't convert
> JPEG's to Palm native. The Treo appears to have three types of
> internal memory: ROM, regular memory, and media memory. Image files
> that I do import into the internal memory, or make with the built-in
> camera, cannot be located with a file manager.

The Palm actually has only two types of long-term memory (if you don't
count ROM). There is VFS, which means filesystems (like a regular DOS
FAT filesystem) located on SD Card, on internal flash "drive", or (as
in the case of the LifeDrive) on internal hard drive. VFS is what most
file managers let you see.

Then there is also the storage heap. This is the "internal" memory
where your PDB and PRC databases are kept. In the old days (before
memory stick and SD Card), Palms had only storage heap and nothing
else. Storage heap is traditionally a fixed portion of (battery-backed)
RAM, but on newer devices (T5 and Treo 650, and LifeDrive, I think),
storage heap is on flash, but there are special tricks going on behind
the scene to load pieces of it into RAM on demand so that applications
still think of it as residing in RAM.

If you store a regular file, say foo.jpg, in storage heap, it gets
put into what's called a File Stream. A File Stream is really a PDB,
but it has a special flag set that tells the operating system that
it can be treated like a file.

Now, here's the tricky and weird part: the mechanisms for accessing
VFS files and File Stream files are totally different. The two types
of files exist in different locations, they have different types of
filenames (the File Stream world has no hierarchy and does not include
directories -- everything is in a flat namespace). Thus, it's common
to see applications that can read only one type of file and not the
other. It's most common to see applications that only know how to
deal with VFS files and not File Stream files.

The point of all this is that it's possible that the media manager
knows how to write to both VFS files and File Stream files, whereas
the File Manager may only know how to deal with VFS files. Thus,
it would be possible for the media manager to create a type of
file that the File Manager doesn't even know about.

For what it's worth, the freeware FileZ application knows about both
types of files, so if you are interested in investigating, that might
be a good tool to investigate with.

- Logan

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that Logan Shaw claimed:

; The point of all this is that it's possible that the media manager
; knows how to write to both VFS files and File Stream files, whereas
; the File Manager may only know how to deal with VFS files. Thus,
; it would be possible for the media manager to create a type of
; file that the File Manager doesn't even know about.

I doubt that. I use McFile, and have been for quite a while, long
before I started using the Treo. And the Treo is the first device I've
used that has this multiplicity of memory types. Before, I've only had
"internal ram" ("Palm card" ) and the expansion card (SD or MS).

; For what it's worth, the freeware FileZ application knows about both
; types of files, so if you are interested in investigating, that might
; be a good tool to investigate with.

I also have Filez installed. It also cannot find media files in the
internal storage. This is with Filez 6.7 : 5/5/05.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"There's always a choice. We say there is no choice, only to comfort
ourselves with a decision we have already made. Now if you understand
that there's hope. If not...." (Lady Morella, B5 "Point Of No
Return" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan wrote:
> It is alleged that Logan Shaw claimed:
>
> ; The point of all this is that it's possible that the media manager
> ; knows how to write to both VFS files and File Stream files, whereas
> ; the File Manager may only know how to deal with VFS files. Thus,
> ; it would be possible for the media manager to create a type of
> ; file that the File Manager doesn't even know about.
>
> I doubt that. I use McFile, and have been for quite a while, long
> before I started using the Treo. And the Treo is the first device I've
> used that has this multiplicity of memory types. Before, I've only had
> "internal ram" ("Palm card" ) and the expansion card (SD or MS).

Oh, I thought you were talking about some sort of built-in file manager,
and since I don't have a Treo 650, I'm not familiar with what applications
come with it, and was just assuming that this hypothetical file manager
only understands VFS.

Since you're talking about McFile and FileZ, that makes me think
that the media manager is instead putting its data into the hidden
VFS filesystem that the Treo 650 and the T|T5 have.

It's a little confusing, but the storage heap (which is, on older
devices, always entirely in RAM) is stored on flash, and that is
done by layering the storage heap on top of a hidden VFS volume.
Volumes are hidden if they have the vfsVolumeAttrHidden attribute
flag set.

So, in the case of a T|T5, you can actually have 3 VFS volumes.
You have the "Internal" VFS volume, which is easily visible
to the user. You have an SD Card VFS volume (if you've got an
SD Card inserted). And, you have a third hidden VFS volume
which is used to store everything in the storage heap. (PRCs
and PDBs are stored as files.)

I guess this leaves me wondering: does FileZ allow you to view
hidden volumes? I haven't downloaded the latest in a while, so
I'm not sure if it does or not.

- Logan

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that Logan Shaw claimed:

; Since you're talking about McFile and FileZ, that makes me think
; that the media manager is instead putting its data into the hidden
; VFS filesystem that the Treo 650 and the T|T5 have.

Quite probably. I can think of no other reason why I would not be able
to locate the files the built-in camera makes when saving to internal
storage.

; I guess this leaves me wondering: does FileZ allow you to view
; hidden volumes? I haven't downloaded the latest in a while, so
; I'm not sure if it does or not.

Hidden +volumes+? Not that I've found. Hidden +files+, yes.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"Look, Mr. Garibaldi. I, I have no reason to tell you -" "I'm not
finished. Now, you're right. The statue itself is worthless. But
it's big enough to hide lots of stuff inside." (Human and Mr.
Garibaldi, B5 "The Illusion Of Truth" )

Archived from groups: comp.sys.palmtops.pilot (More info?)

Jeffrey Kaplan <cspp@gordol.org> wrote:

>ZLauncher does not find a jpeg on the internal memory...

No program will find a jpeg file in internal memory because you can't have a
jpeg file in internal memory. Only pdb or prc files will work in internal
memory. After thinking about it, perhaps ZLauncher will only see it's own
converted jpeg files, and not one converted by another program. If that's the
case I suspect you're SOL on finding a different program to make a smaller
converted jpeg file...

Archived from groups: comp.sys.palmtops.pilot (More info?)

AaronJ wrote:
> Jeffrey Kaplan <cspp@gordol.org> wrote:
>
>
>>ZLauncher does not find a jpeg on the internal memory...
>
>
> No program will find a jpeg file in internal memory because you can't have a
> jpeg file in internal memory. Only pdb or prc files will work in internal
> memory.

Actually, it's not used often, but Palm OS supports things called
File Streams. These are just PDBs, but they have a filename encoded
within them and there are system calls for accessing them like
regular files on a regular computer. So, you *can* put a JPEG
in internal memory, and you can do it in a standard way that any
program could recognize and understand, if it chooses to use the
File Stream API.

> After thinking about it, perhaps ZLauncher will only see it's own
> converted jpeg files, and not one converted by another program.

That's VERY likely to be the case. There is no standard format
for storing converted JPEG files, especially considering that
once decompressed many images will be too large to fit in a PDB
record or PRC resource and therefore some sort of splitting and
reassembling procedure must be used. Each program will choose
its own method. Without cooperation (and there's little motivation
for cooperation), there is no reason one program would be able to
read anothers' converted files.

> If that's the
> case I suspect you're SOL on finding a different program to make a smaller
> converted jpeg file...

Since the converted JPEG file is likely stored without any compression
at all (hence the roughly 200K size for a 320x320 image, which is
exactly the size that a 16-bit 320x320 image should be if not
compressed at all), ZLauncher is probably only capable of reading
an uncompressed image, and there is probably no way at all to make
a smaller converted JPEG file that's compatible with ZLauncher,
whether it's with ZLauncher or any other program.

- Logan

Archived from groups: comp.sys.palmtops.pilot (More info?)

It is alleged that AaronJ claimed:

; No program will find a jpeg file in internal memory because you can't have a
; jpeg file in internal memory. Only pdb or prc files will work in internal
; memory. After thinking about it, perhaps ZLauncher will only see it's own
; converted jpeg files, and not one converted by another program. If that's the
; case I suspect you're SOL on finding a different program to make a smaller
; converted jpeg file...

Oh, sorry... ZLauncher support got back to me on this. Paraphrased,
they said that the copy placed into main memory has been converted by
ZLauncher into a Palm-native state, and that since jpg is a compressed
file, it has to be uncompressed to be used.

--
Jeffrey Kaplan www.gordol.org
The from userid is killfiled Send personal mail to gordol

"Find what you need and let's get out of here. We're running out of
time." "Cannot run out of time. There is infinite time. You are
finite. Zathras is finite. This... is wrong tool. No, no, not good
no... no never use this." (Cmdr. Ivanova and Zathras, B5 "War Without
End Pt. 2" )