I have cjpeg and djpeg for OS4.

Can anyone give me a status report regarding conversion of:

Jpeginfo
Jpegoptim

Edit: I cannot get a version from cjpeg and djpeg OS4
As memory serves, that was true of the 6.2b package for prior OS.
I realize the package says 6.2
Is my memory faulty about there being a 6.2b?

Last edited by number6 on 26-Mar-2005 at 01:14 AM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

For those interested in the value of these "obscure" programs and why I wish
information as to their status:

djpeg - is used effectively in thumbnail generators to increase speed by
4,8,16 times. It can be employed to augment or replace native loaders.
Since thumbnails only require a fraction of the data to actually be processed,
this program is "smart" enough to ignore the rest of the data, hence the speed
increase.

jpeginfo - is used effectively to give useful info on your jpg files.

jpegoptim - is used effectively to save you 0-25% on your storage medium.
It strips jpgs of info not needed, but included through many programs that
save in that format. It writes the "cleaned up" file back to your storage
medium in "lossless" form. Some Adobe files are a prime example of "expanded"
jpgs.

Perhaps this better explains my interest in knowing the status of development
of these fine programs.

Note: A question was asked some time ago by @cecilia about the directory named
"jpegtmp". If one adds the following to user-startup this directory will
accelerate work with the above listed programs:

Makedir RAM:jpegtmp
Assign jpegtmp: RAM:jpegtmp

jpegtmp is a "temporary" work directory for the package. Some installs may
create such a directory in "t:". This, in my opinion, is not optimum, since
that is not RAM:t, but t: on hard disk. Faster response is achieved with the
above assign to RAM. Also, the less "nibling" away at hard disk the better.

Last edited by number6 on 26-Mar-2005 at 02:22 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

Ah, so THIS is what that slightly obscure PM was all about

When I went looking, these are some links I discovered:
jpeginfo in debian

another place for jpeginfo

djpeg seems to be a linux command.

and for those who want some info on jpegtmp try there.

sometime in the distant past I seem to recall IBrowse or some amiga browser needing/using this directory and i noticed it wanted the dir in T: (the HD) and I immediatly changed that to ram because as you already pointed out that seems dumb

anyway, i never liked things accumulating on my HD.

_________________
"In terms of worship, I worship the God of Irony.
That's the only God that I know exists." Terry Gilliam

@number6

Quote:

Some installs may create such a directory in "t:". This, in my opinion, is not optimum, since that is not RAM:t, but t: on hard disk. Faster response is achieved with the above assign to RAM. Also, the less "nibling" away at hard disk the better.

@cecilia

Quote:

wanted the dir in T: (the HD)

I don't know about you, but T: has been set to RAM:T by default on all my AOS setups as far as I remember (3.1 & 4.0 and I think 3.9 too). I always thought it strange that PPaint uses T: by default considering that is in RAM: for it's "virtual memory". Also, I checked with OS4 today so I'm absolutely sure about that one:

1. "cd T:" sets current directory to RAM:T.
2. According "assign list" T: points to RAM:T and nothing else.

@salass00

I could be wrong, but I have the following:

Makedir Ram:jpegtmp
Assign jpegtmp: Ram:jpegtmp

My old memory tells me that someone had recommended I do this since Ram:t
has other things that may be there.
With a "clean" jpegtmp I was told it would be easier to follow.

As I said, I could be wrong. It could have been my own advice, not that
of an author. Sorry if I confused anyone with that one.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@cecilia

Thank you so much for your reply. I am sorry I was in such a hurry.

I am glad you appreciate.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

Sure, with such a directory you could just do 'delete jpegtmp:#?' if you were done with the jpeg programs (and AWeb perhaps).

_________________
: AmigaOneXE (unmod.) 750FX/512 MB +stuff & AmigaOS 4.(0|1)
: A1200/68060&96MB/SCSI/EM1200-Voodoo3 & OS 3.5
: A500/1MB
: Pegasos (ff) 512 MB & MorphOS
Praise seitan.

@thread

I still get an occasional requester for the "jpegtmp" directory (which used to
be VMEM iirc).
Having failed to note the program making the request, I am NOT going to replace
my assign. That way, the -next- time this requester appears, I can make note of the
program(s) still using this.

@Cecilia

It could be a particular jpg type and it could have been from IBrowse.

Best Wishes,
#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@thread

http://amigaworld.net/modules/news/article.php?storyid=1845&start=20
Post #26 Indicates a "requirement" for jpegtmp for Aweb (at the time this was posted).

http://www.hal9k.com/cug/cug381.htm
Tom Lane - CUG#381: JPEG Software by the Independent JPEG Group

Quote:"Amiga implementations put the temp files in the directory named by JPEGTMP:,
so be sure to assign JPEGTMP: to a disk partition with adequate free space."

Personal note:I created this directory in RAM: and made an appropriate assign
in user-startup in the past. This worked just as well. As stated earlier, I have
since removed this assign and still receive the occassional requester for the
JPEGTMP directory. I must then use OS4 ASL to assign this to T:. At that point
the application will proceed. If I no longer have an assign, AND OS4 makes this
assign automatic, then why would I receive a requester for this?

It is POSSIBLE that this directory comes into play during a memory overflow
situation. Is it possible then that the seldom seen requester DOES appear when
some setting concerning memory in AWeb is "too low"?

I must ask because another website gives examples of potential difficulties
(-rare- crash or freeze) when this occurs. Note: This is older information.
Has this been fully addressed?

Best Wishes,
#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@thread

http://www.amitrix.com/faqs.html
Relevant section:Memory Usage (but more here is of interest)
Indeed a dependency is mentioned concerning the directory JPEGTMP.
It seems to indicate that if enough memory is NOT available in TEMP it will use
the JPEGTMP directory.
Is this dependency still in place?
Would this explain why I still get the occassional requester for the JPEGTMP directory?
Are any other current apps still (hiding) a JPEGTMP directory dependency?
Is so, would it be wise to make an assign for JPEGTMP to t: or somewhere else
and add this to startup-sequence or user-startup?

Best Wishes,
#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

The AWeb awebjfif.awebplugin (which uses libjpeg) "requires" JPEGTMP: to be
assigned. It is used for large jpegs whixh require more memory than is
available to decode.

You can set the limit at which this swap directory gets used in the

AWebPath:AWebplugin/Docs/awebjfif.awebplugin/html docs

assigning it to T: is convenient on ssytems that have very large memory,
but this serves little point as you are still using ram ideally it should be set to
a directory on disk somewhere.

On my A1200 its assign to work:vmem, which used is also used by imagefx: and jpeg datatype.

I don't know whether the OS4 datatype needs it.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Thanks. Since I had seen the requester (for JPEGTMP), but was looking at older
documentation, I wanted to be sure about this.
If you read the whole thread, you will understand that I created the conditions
for this problem to occur intentionally, by REMOVING my assign.
It was the only way to check and see if the dependency on JPEGTMP was actually
still there.
Hope this is clear in the new docs. I don't think everyone understands JPEGTMP.
I am still curious, though, whether other current programs still have this
dependency, without clear mention of it?

Best Wishes,
#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@broadblues

Hmmm...If one uses the (current) install and chooses the "install presets"
(paraphrased) option that is in the install, then the files in AWebPath:AWebplugin/Docs
never get seen by the user, because ALL setup is "automated". Will the instructions
concerning JPEGTMP appear in the "new" main docs as well, and not just in the configs
for the individual decoders?

Best Wishes,
#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@thread

http://os4depot.net/?function=showfile&file=graphics/edit/jpegoptim.lha

Much thanks to author and uploader to make this fine program available.
My initial test on a sample directory shows it running 5 times the speed of the
68k version on final and I also noticed it is no longer ixemul.library dependent.
Fantastic!

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

Quote:

number6 wrote: @thread http://os4depot.net/?function=showfile&file=graphics/edit/jpegoptim.lha Much thanks to author and uploader to make this fine program available. My initial test on a sample directory shows it running 5 times the speed of the 68k version on final and I also noticed it is no longer ixemul.library dependent. Fantastic! #6

Thanks for this, I've just uploaded jpeginfo to OS4depot

Ciao, Alfred

@Serpi

I've just uploaded jpeginfo to OS4depot

Umm, I can't get it to open any file. Could you explain why i'm looking
at unix shell commands?

_________________

@Snuffy
Quote:

Umm, I can't get it to open any file. Could you explain why i'm looking at unix shell commands?

I'm not sure I understand you.
jpeginfo is, like jpegoptim, only a (quick) port of a shell programm.
So open a shell, type "jpeginfo" and the name of a JPEG file and it will output some information about it.
If you are missing a GUI, I have to dissapoint you, most likely I will not do one. But of course you could
A) do it better - with GUI
B) use something r (if i remember the name) that is able to create a GUI for a shell programm
C) Use (and maybe alter) this simple shell script, that will give you a file requester and output the information in a requester:
Quote:

requestfile TITLE "Please select a JPEG/JFIF file" PATTERN #?.(jpg|jpeg) NOICONS > ENV:JPEGFILESELECT jpeginfo $JPEGFILESELECT > ENV:JPEGFILEINFO requestchoice TITLE "JPEGInfo" BODY "$JPEGFILEINFO" GADGETS "OK"

You can save this as a script with icon, set IconX as default tool and you can open a file by doubleclicking (best to set "WINDOW=NIL:" in ToolTypes).

Ciao, Alfred

@Snuffy

Quote:

Umm, I can't get it to open any file. Could you explain why i'm lookingat unix shell commands?

In shell get arguments with jpeginfo -h.
Program works perfectly with jpeginfo [filename]
Works perfectly as a button in Dopus, as well. Example:
AmigaDOS settings for - [path to jpeginfo] -c {f}

@Serpi

Thanks for this fine program as well. Much appreciated here!

#6

Last edited by number6 on 08-Jan-2007 at 09:44 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*