Science and Technology news... :: View topic

Mark Adler · Guest

The question is largely non-sequitur, but I may have a speck of
insight that can come from it.

My paying job is interplanetary robotic spacecraft system
engineering. It is remarkably difficult as well as rewarding, when
things work. I also do programming, mainly in data compression, as a
hobby. I find the latter relaxing and rewarding, in part because of
the instant gratification. I can build, test, and deploy an
operational and useful software device on my own and in hours to
days. In the space business on the other hand, gratification may not
come for years or, literally, decades of extremely hard work. And
after all that, you may get disappointment instead of gratification.

Two activities on completely opposite ends of the gratification time-
scale and risk spectrum. Both have their place in my world.

Leo B. · Guest

On Oct 23, 6:44 am, Mark Adler <mad...@alumni.caltech.edu> wrote:
[quote]On Oct 22, 11:37 pm, "Leo B." <leo...@gmail.com> wrote:

Why there is gzprintf(), but no gzvprintf(gzFile, const char *,
va_list)?

Because not all libraries provide vsprintf / vsnprintf. zlib does use
those functions internally if available. Otherwise it falls back to
sprintf or snprintf.
[/quote]
According to the source, the STDC implementation of gzprintf depends
on vsprintf/vsnprintf.
It would be trivial to have gzvprintf indef #ifdef STDC. Please?

[quote]It would be trivial to write your own gzvprintf using vasprintf and
gzwrite. (Example below -- untested.)
[/quote]
Sure, but it is annoying to drag this into every project.

Leo

Leo B. · Guest

On Oct 23, 6:56 am, John Reiser <jrei...@BitWagon.com> wrote:
[quote]Why there is gzprintf(), but no gzvprintf(gzFile, const char *,
va_list) in zlib?

vprintf is newer and is used much less often than printf.
va_list had problems with portability for many years. Inertia.
[/quote]
You haven>t looked at the source of gzprintf, have you?

[quote]Why don>t you write gzvprintf, then contribute your implementation?
[/quote]
Ahem... You haven>t looked at the source of gzprintf, have you?

Leo

Mark Adler · Guest

On Oct 24, 10:44 am, "Leo B." <leo...@gmail.com> wrote:
[quote]It would be trivial to have gzvprintf indef #ifdef STDC.
[/quote]
I don>t like the idea of defining a library function that is sometimes
available, sometimes not. Especially when it>s so simple to provide
the function yourself in your own application.

All you really need is gzwrite(). From there, any sort of printf
function you>d like is just a few lines of code.

Mark

Leo B. · Guest

On Oct 24, 2:01 pm, Mark Adler <mad...@alumni.caltech.edu> wrote:

[quote]It would be trivial to have gzvprintf indef #ifdef STDC.

I don>t like the idea of defining a library function that is sometimes
available, sometimes not. Especially when it>s so simple to provide
the function yourself in your own application.
[/quote]
I>m curious, what platform for which zlib can be built does not
support STDC yet?

[quote]All you really need is gzwrite(). From there, any sort of printf
function you>d like is just a few lines of code.
[/quote]
True, but nevertheless gzprintf is included.

Leo

sobriquet · Guest

On 24 okt, 09:42, mathieu <mathieu.malate...@gmail.com> wrote:
[quote]On Oct 23, 7:14 pm, sobriquet <dohduh...@yahoo.com> wrote:

Hello.
On an art cdrom, the graphics are jpgs that are bundled somehow. Does
anyone know how to unbundle them or extract the individual jpg files
from the package?

An example data file is here:

http://www.ibbu.nl/~nsprakel/combY

Simply renaming it to combY.jpg and opening it with irfanview will
display the first image in the package.

I am on linux and non-of the usual tool did work for me :

Kind regards and thanks in advance for any suggestions, Niek

Here is what I used:

$ wgethttp://www.ibbu.nl/~nsprakel/combY
$ file combY
combY: data

$ dd skip=108 bs=1 if=combY of=test.jpg
$ $ file test.jpg
test.jpg: JPEG image data, JFIF standard 1.01, comment: "AppleMark
\015ÿÛ"

$ jpeginfo test.jpg
toto.jpg 781 x 1090 24bit JFIF N 852248

The jpeg marker is at 0x6c AFAIK

2cts
[/quote]
I think there are supposed to be two jpg images in the combY file, but
I>m not sure if they actually use
a marker. Perhaps they have the filesizes stored as constants in the
program so they don>t need
a separator code.

I have another example of a package that probably consists of more
jpgs here:

http://www.ibbu.nl/~nsprakel/combK

John Reiser · Guest

Leo B. wrote:
[quote]On Oct 23, 6:56 am, John Reiser <jrei...@BitWagon.com> wrote:
Why there is gzprintf(), but no gzvprintf(gzFile, const char *,
va_list) in zlib?
vprintf is newer and is used much less often than printf.
va_list had problems with portability for many years. Inertia.

You haven>t looked at the source of gzprintf, have you?
[/quote]
Not only had I looked at the source of gzprintf, but my stated reasons
remain valid regardless of your insinuation. vprintf was not in view
when I myself cleaned up the format designators (%<letter> etc.) in 1978
(30 years ago) as part of one of the earliest implementations of
*printf on system where 4==sizeof(int). There was a disagreement
over the syntax for declaration of variable args:
int ZEXPORTVA gzprintf (gzFile file, const char *format, ...)
versus
int ZEXPORTVA gzprintf (gzFile file, const char *format ...)
[Note the difference in the comma ',' before the ellipsis.]
zlib caters [and has catered] to older systems, older compilers, and older
<stdio>, particularly including implementations where 2==sizeof(int)
and STDC was in its infancy. Indeed, these were common usage for many years.

[quote]Why don>t you write gzvprintf, then contribute your implementation?

Ahem... You haven>t looked at the source of gzprintf, have you?
[/quote]
The first requirement for getting gzvprintf into zlib is a concrete published
documented implementation that can be evaluated. You can advocate for your
vision of progress by sharing *your* implementation.

--

Mark Adler · Guest

On Oct 24, 9:22 pm, "Leo B." <leo...@gmail.com> wrote:
[quote]I>m curious, what platform for which zlib can be built does not
support STDC yet?
[/quote]
zlib is used on a very wide variety of embedded as well as traditional
platforms, some of which have rather barebones C libraries.

[quote]All you really need is gzwrite(). From there, any sort of printf
function you>d like is just a few lines of code.

True, but nevertheless gzprintf is included.
[/quote]
In retrospect, I wish we hadn>t included it. It has been a fair bit
of work on my part to get it to compile portably and at the same time
avoiding security vulnerabilities when possible. I really don>t want
to add yet another portability ordeal. I should note that I don>t get
paid to support zlib, so I feel somewhat justified in making arbitrary
and capricious decisions about its future.

Mark

Mark Adler · Guest

(Odd -- I responded to this this morning, but it never showed up. I
apologize if I end up with a duplicate post here.)

On Oct 24, 9:22 pm, "Leo B." <leo...@gmail.com> wrote:
[quote]I>m curious, what platform for which zlib can be built does not
support STDC yet?
[/quote]
zlib is used in many embedded applications with limited libraries, as
one example.

[quote]All you really need is gzwrite(). From there, any sort of printf
function you>d like is just a few lines of code.

True, but nevertheless gzprintf is included.
[/quote]
In retrospect, I wish we hadn>t. It took more effort than it was
worth to update gzprintf() to compile portably while avoiding security
vulnerabilities when possible. I don>t want to add yet another
portability ordeal. Since I maintain and support zlib (cheerfully)
without getting paid, I feel somewhat justified in making arbitrary
and capricious decisions about its future.

Mark

Mark Adler · Guest

(What the heck? this is the third time I>ve tried this posting on
google groups. I apologize if I end up with redundant posts here.)

On Oct 24, 9:22 pm, "Leo B." <leo...@gmail.com> wrote:
[quote]I>m curious, what platform for which zlib can be built does not
support STDC yet?
[/quote]
zlib is used on a very wide variety of unconventional platforms, such
as in embedded applications, cell phones, etc. with limited libraries.

[quote]All you really need is gzwrite(). From there, any sort of printf
function you>d like is just a few lines of code.

True, but nevertheless gzprintf is included.
[/quote]
In retrospect, I wish we hadn>t included it. It was a fair bit of
work to get gzprintf() to be portable and to avoid security
vulnerabilities when possible. I don>t want to add another
portability ordeal if I can avoid it.

Mark

jules Gilbert · Guest

On Oct 24, 3:07 am, Nimo <azeez...@gmail.com> wrote:
[quote]Ok thanks for your good hint,any how I put myself this weekend
my target as to come up with a sloution to this 50 or 60 years of saga
of compression world.

"At the end data compression is not at all Rocket Engineering".
I>m going to start a new thread all the ideas I>ve in my mind to
discuss.
[/quote]
=========

(Hello, Nimo! Welcome.)

I>ve been working on compression issues for a little less than 15
years. And only now, after working on this topic only part-time,
(well, most of the time,) probably the equivalent of about five years,
have I accomplished what I set out to do, and to do it efficiently.

Today, in one quick pass, I took a 92k-byte bzip2 file (ie., a file
that had already been compressed,) and piped it through the compressor/
decompressor I intend to use when I come down to Texas to take Mark>s
hard earned money.

My program isn>t really very good at all -- it only does about 3,000
to 1, and in a single pass! And worse, most files are made so small
that they don>t present a sufficiently significant chunk for my
program to perform a second physical pass.

The facts with one omission are accurate as stated in the prior
paragraph.

And what>s the omission? I have a very complex getBIT/putBIT
arrangement, not the usual bit-I/O stuff but something very
different; Well, the data comes in okay, but leaves not-so-hot. Over
the course (this is measured,) of 1450 bytes, about 25 are faulty,
those bytes contain single bit-errors.

I know, with savings like this (92k to 32 bytes,) I could simply do it
three or even five times and vote the bits -- and it may come that.

I>m spending this week looking at the problem.

I realize that few people believe me; For now, that>s alright. Some
things take time and when my investors say "okay", well, we have
plans.

But soon. How soon? Soon. A month? Yes, probably about a month.

And what will happen then? Well, for one thing a lot of you folks
will look so incredibly foolish -- though I>ll stick up for you. I>ll
say that we live in different worlds, the rules are different in my
world.

Do we share the same physical space? Yes. The same physics? Yes.
The same math? Yes. Then what>s different? It works better if you
work this out yourself...

--jg

Thomas Pornin · Guest

According to Mark Adler <madler@alumni.caltech.edu>:
[quote](What the heck? this is the third time I>ve tried this posting on
google groups. I apologize if I end up with redundant posts here.)
[/quote]
I saw all three versions. Apparently, your messages get sent to
other servers.

--Thomas Pornin

Phil Carmody · Guest

Mark Adler <madler@alumni.caltech.edu> writes:
[quote](What the heck? this is the third time I>ve tried this posting on
google groups. I apologize if I end up with redundant posts here.)
[/quote]
They>re all getting through; don>t worry Mark. (Well, you might worry,
you>re falling into the behaviour patterns of google-groups-using
usenet newbs, rather than someone who actually knows what he>s doing.)
Have you ever thought of using something like aioe.org rather than
the godforsaken abomination that calls itself googlegroups?

Phil
--
The fact that a believer is happier than a sceptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality.
-- George Bernard Shaw (1856-1950), Preface to Androcles and the Lion

Mark Adler · Guest

On 2008-10-26 13:12:02 -0700, Phil Carmody
<thefatphil_demunged@yahoo.co.uk> said:
[quote](Well, you might worry,
you>re falling into the behaviour patterns of google-groups-using
usenet newbs, rather than someone who actually knows what he>s doing.)
[/quote]
Sigh. Well, you can now count me among the newbs. I never had google
groups take so long. (And in fact those three posts and your replies
*still* haven>t shown up there.)

I just downloaded a real newgroup reader which I am using as we speak,
and I>ll start using that instead of google groups.

Mark

mathieu · Guest

On Oct 25, 6:58 am, sobriquet <dohduh...@yahoo.com> wrote:
[quote]On 24 okt, 09:42, mathieu <mathieu.malate...@gmail.com> wrote:

On Oct 23, 7:14 pm, sobriquet <dohduh...@yahoo.com> wrote:

Hello.
On an art cdrom, the graphics are jpgs that are bundled somehow. Does
anyone know how to unbundle them or extract the individual jpg files
from the package?

An example data file is here:

http://www.ibbu.nl/~nsprakel/combY

Simply renaming it to combY.jpg and opening it with irfanview will
display the first image in the package.

I am on linux and non-of the usual tool did work for me :

Kind regards and thanks in advance for any suggestions, Niek

Here is what I used:

$ wgethttp://www.ibbu.nl/~nsprakel/combY
$ file combY
combY: data

$ dd skip=108 bs=1 if=combY of=test.jpg
$ $ file test.jpg
test.jpg: JPEG image data, JFIF standard 1.01, comment: "AppleMark
\015ÿÛ"

$ jpeginfo test.jpg
toto.jpg 781 x 1090 24bit JFIF N 852248

The jpeg marker is at 0x6c AFAIK

2cts

I think there are supposed to be two jpg images in the combY file, but
I>m not sure if they actually use
a marker. Perhaps they have the filesizes stored as constants in the
program so they don>t need
a separator code.

I have another example of a package that probably consists of more
jpgs here:

http://www.ibbu.nl/~nsprakel/combK
[/quote]
$ strings combY | grep JFIF | wc
2 2 10

$ strings combK | grep JFIF | wc
10 10 50

Use an hex editor and look for JFIF (pretty easy). You>ll see there is
a small header before each jpeg. So I would guess layout is:

main header (12 bytes):
01 00 00 0A 00 02 62 96 03 0F 04 15

for each jpeg:
108 - 12 = 96 bytes header per jpeg
then the first jpeg marker: ffd8

inspect the main header and you might find 2 or 10 encoded for the
number of files. and maybe you have the jpeg length encoded in the
'header per jpeg'.

good luck


www.GetXFactor.com Leading Technology, Science, Agriculture News and information	Part of the Identityscape.com network... getxfactor.com jmoodmusic.com smartbusinesschoices.com mintdepot.com lowfaresalways.com evangelicalview.com shoppingpodder.com soproudlywehail.com webnews.ws currenthumor.com

Science and Technology news... Forum Index -> Compression Forum	Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9 Next
Page 5 of 9