Science and Technology news... :: View topic

Sie · Guest

We are trialing some software that very basically allows your average Joe
with the correct client software installed send an image file via the
internet to a server running the server side of this software. While this is
already very easy to do with a bit of HTML code and asp/php e.t.c to receive
and manipulate the file. This software claims to compress the image before
it is sent and then decompress the server end with no loss using file
compression rather than further image compression. What>s more it claims it
compresses them up to 80% compression before transfer!

While I can believe this of bitmap or tiff (uncompressed) images I can not
believe can compress a jpeg file up to 80% using lossless file compression.
Testing the software produces an exact transferred copy of the original
image but the only proof that it was compressed during transfer is the
software log which could claim anything. It is being tested using a 2mb
network link to the internet at the moment so the difference in transfer
time between a 200k jpeg and the same file compressed by 80% would be hardly
noticeable.

I have tried the best file compression methods I know such as rar and ace
e.t.c to compress a jpeg but cannot get above 2% compression. I genuinely
think this software is making untrue claims.

This is the software.

http://www.sharpbyte.com

Notice in there features claim they use a tiff file as an example which is
entirely believable but in xfer log the software claims it has compressed
jpeg>s from 200k to 40k before xfer is to me ridiculous.

Any thoughts from yourselves would be appreciated as I am really confused.

Thanks

Sie

Sie · Guest

"Thomas Richter" <thor@cleopatra.math.tu-berlin.de> wrote in message
news:bhve1r$9i3$4@mamenchi.zrz.TU-Berlin.DE...
[quote]Hi,

80% compression compared to what? To the original JPEG stream, or compared
to the unexpanded original image? And how is this 80% counted? The file
size of the compressed image is 80% of the file size of the original, or
does 80% compression mean that only 20% of the data is left?
[/quote]
Compared to the jpeg stream. It know nothing of the original images it is
only aware of the jpeg file you give it. I can only presume considering it
claims to compress the file size from around 200-250k to 40-50k (no exact
figures at hand)
that it means 20% left.

[quote]If you need to be fast sending images, one possible approach is to
make the images 'browsable' in the sense that you sent your customers
a preview image over the line (possibly with smaller dimensions, or in
lower quality), and let them pick "regions of interest" then. These
regions can then be re-encoded in higher quality and transmitted in a
second go.
[/quote]
The system is for photographers to send there images into our servers for a
regional newspaper so they just send what they have. We look at the
speediest methods of xfer of normal modem 56k lines therefore the compressed
file xfer was attractive to the hierarchy that made the decision to trial
the software.

Thanks

Sie

Joe · Guest

Thomas Richter <thor@cleopatra.math.tu-berlin.de> wrote in message
news:bhvkc2$ful$1@mamenchi.zrz.TU-Berlin.DE...
[quote]
Hi,

80% compression compared to what? To the original JPEG stream, or
compared
to the unexpanded original image? And how is this 80% counted? The file
size of the compressed image is 80% of the file size of the original,
or
does 80% compression mean that only 20% of the data is left?

Compared to the jpeg stream. It know nothing of the original images it
is
only aware of the jpeg file you give it. I can only presume considering
it
claims to compress the file size from around 200-250k to 40-50k (no
exact
figures at hand) that it means 20% left.

That seems pretty much like a hoax to me. jpeg streams do have a certain
redundance, but not *that* much.

The system is for photographers to send there images into our servers
for a
regional newspaper so they just send what they have. We look at the
speediest methods of xfer of normal modem 56k lines therefore the
compressed
file xfer was attractive to the hierarchy that made the decision to
trial
the software.

How large are the images you expect on your server? Would be a
different compression program (non-jpeg) be feasible for your
photographers? Depending on the image size, you can do better than
jpeg. Maybe not down to 80%, but if the images are possibly around
2000x2000 pixels or larger, 30% compared to a jpeg of the same quality
don>t seem to be too unrealistic. That>s then non-jpeg, though.

So long,
Thomas

[/quote]
Has anyone used a packet sniffer on thier network, and extracted the TCP
stream?
You should be able to tell _exactly_ how many bytes it uses.
Ethereal is easy to do this with, on a PC running ICS/NAT.

Also, make sure the program isn>t making some kind of backup.
If you can>t read the file on another PC, then it>s likely storing a hidden
copy, so you can>t just delete/rename the original.

Also: If you are required to use a user name, for it to work on any PC,
then they could just store a server side copy.
IP addresses and ID strings can be used also, as a username.

Sie · Guest

The images probably originate from a digital camera as a jpeg. I know the
more expresive digital cameras will allow Tiff usage but I doubt the
photographers use it considering the amount of space it uses on whatever
storage cards they use on the camera. I have not seen them send any other
format than jpeg and the file size on those always seem to be in the range
of 150k to 400k so they don>t even use high resolution images. Considering
the loss in quality taken by images when they get down newspaper resolution
they don>t need to be the greatest quality in the first place.

Thanks

Sie
"Thomas Richter" <thor@cleopatra.math.tu-berlin.de> wrote in message
news:bhvkc2$ful$1@mamenchi.zrz.TU-Berlin.DE...
[quote]
Hi,

80% compression compared to what? To the original JPEG stream, or
compared
to the unexpanded original image? And how is this 80% counted? The file
size of the compressed image is 80% of the file size of the original,
or
does 80% compression mean that only 20% of the data is left?

Compared to the jpeg stream. It know nothing of the original images it
is
only aware of the jpeg file you give it. I can only presume considering
it
claims to compress the file size from around 200-250k to 40-50k (no
exact
figures at hand) that it means 20% left.

That seems pretty much like a hoax to me. jpeg streams do have a certain
redundance, but not *that* much.

The system is for photographers to send there images into our servers
for a
regional newspaper so they just send what they have. We look at the
speediest methods of xfer of normal modem 56k lines therefore the
compressed
file xfer was attractive to the hierarchy that made the decision to
trial
the software.

How large are the images you expect on your server? Would be a
different compression program (non-jpeg) be feasible for your
photographers? Depending on the image size, you can do better than
jpeg. Maybe not down to 80%, but if the images are possibly around
2000x2000 pixels or larger, 30% compared to a jpeg of the same quality
don>t seem to be too unrealistic. That>s then non-jpeg, though.

So long,
Thomas

[/quote]

Sie · Guest

If have thought of using a sniffer program and probably give it a go later.
I just thought there was no logical explanation for how it could work in the
first place.

Not quite sure what you mean by a backup file. The server never knows what
image it is likely to recieve and the files it puts in the received folder
is the one that is manipulated and moved around. The file is no smaller than
it>s original it>s only during the xfer it claims to have reduced it>s size
and expanded it back to normal at server end.

Thanks

Sie
"Joe" <jwhiteheadcc___dumb@bots___hotmail.com> wrote in message
news:7cK0b.15506$kK4.640@nwrddc02.gnilink.net...
[quote]
Thomas Richter <thor@cleopatra.math.tu-berlin.de> wrote in message
news:bhvkc2$ful$1@mamenchi.zrz.TU-Berlin.DE...

Hi,

80% compression compared to what? To the original JPEG stream, or
compared
to the unexpanded original image? And how is this 80% counted? The
file
size of the compressed image is 80% of the file size of the original,
or
does 80% compression mean that only 20% of the data is left?

Compared to the jpeg stream. It know nothing of the original images it
is
only aware of the jpeg file you give it. I can only presume
considering
it
claims to compress the file size from around 200-250k to 40-50k (no
exact
figures at hand) that it means 20% left.

That seems pretty much like a hoax to me. jpeg streams do have a certain
redundance, but not *that* much.

The system is for photographers to send there images into our servers
for a
regional newspaper so they just send what they have. We look at the
speediest methods of xfer of normal modem 56k lines therefore the
compressed
file xfer was attractive to the hierarchy that made the decision to
trial
the software.

How large are the images you expect on your server? Would be a
different compression program (non-jpeg) be feasible for your
photographers? Depending on the image size, you can do better than
jpeg. Maybe not down to 80%, but if the images are possibly around
2000x2000 pixels or larger, 30% compared to a jpeg of the same quality
don>t seem to be too unrealistic. That>s then non-jpeg, though.

So long,
Thomas

Has anyone used a packet sniffer on thier network, and extracted the TCP
stream?
You should be able to tell _exactly_ how many bytes it uses.
Ethereal is easy to do this with, on a PC running ICS/NAT.

Also, make sure the program isn>t making some kind of backup.
If you can>t read the file on another PC, then it>s likely storing a
hidden
copy, so you can>t just delete/rename the original.

Also: If you are required to use a user name, for it to work on any PC,
then they could just store a server side copy.
IP addresses and ID strings can be used also, as a username.

[/quote]

Joe · Guest

Sie <no_siejones_spam@freeuk.com> wrote in message
news:JGO0b.115605$YP.15549@news.easynews.com...
[quote]If have thought of using a sniffer program and probably give it a go
later.
I just thought there was no logical explanation for how it could work in
the
first place.

Not quite sure what you mean by a backup file. The server never knows what
image it is likely to recieve and the files it puts in the received folder
is the one that is manipulated and moved around. The file is no smaller
than
it>s original it>s only during the xfer it claims to have reduced it>s
size
and expanded it back to normal at server end.
[/quote]
Well if the website was a little more detailed, that would be obvious, but
till they send me a demo, I couldn>t be sure. ):
A backup could be a hidden file on the 'testing' machine, and not just the
server.
Does it work on an entirely different client?
Till I have the demo, I can>t say.

Geoff T · Guest

"Sie" <nospam_s.jones@expressandstar.co.uk> wrote in message news:<0jG0b.88628$CQ.727964@news.easynews.com>...

(snipped)

[quote]compresses them up to 80% compression before transfer!
------------------^^^^^[/quote]

There is the problem: "up to" also contains the number zero.

Sign up to my pyramid scheme - you may be earning up to $10,000 per
week in as little as 14 days!! :)

- Geoff T

Thomas Richter · Guest

Hi,

[quote]The images probably originate from a digital camera as a jpeg. I know the
more expresive digital cameras will allow Tiff usage but I doubt the
photographers use it considering the amount of space it uses on whatever
storage cards they use on the camera. I have not seen them send any other
format than jpeg and the file size on those always seem to be in the range
of 150k to 400k so they don>t even use high resolution images. Considering
the loss in quality taken by images when they get down newspaper resolution
they don>t need to be the greatest quality in the first place.
[/quote]
The question rather is how they move the data out of the camera into
your network. For example, it if is acceptable for your customers to run
the images thru a compressor program in their PCs, it would be easy to
unpack a jpg file, then recompress it using a different method, and sent
it along. Digital cameras have resolutions from 1 megapixel to 6 megapixel,
giving image dimensions of around 1000x1000 to 2500x2500. This is already
the regime where jpeg2000 gets interesting compared to traditional jpeg,
especially in the high-compression regime.

So long,
Thomas

Sie · Guest

Unfortunately this is already too much like hard work for a photographer. I
understand where you are coming from but our photographers are not very
computer literate and are not really prepared to do more than the most
simplistic of procedures. Through my experience with digital cameras I can
presume that the file size we normally get from there submitted file means
they probably use no more than 1.2m pixels for each shot (1.2mp usually
creates a file size 200-400k). I can guarantee they do not do any processing
on the files. Remember as simple as possible :) ).

Thanks for you advice

Sie

"Thomas Richter" <thor@cleopatra.math.tu-berlin.de> wrote in message
news:bi217r$5ig$2@mamenchi.zrz.TU-Berlin.DE...
[quote]
Hi,

The images probably originate from a digital camera as a jpeg. I know
the
more expresive digital cameras will allow Tiff usage but I doubt the
photographers use it considering the amount of space it uses on whatever
storage cards they use on the camera. I have not seen them send any
other
format than jpeg and the file size on those always seem to be in the
range
of 150k to 400k so they don>t even use high resolution images.
Considering
the loss in quality taken by images when they get down newspaper
resolution
they don>t need to be the greatest quality in the first place.

The question rather is how they move the data out of the camera into
your network. For example, it if is acceptable for your customers to run
the images thru a compressor program in their PCs, it would be easy to
unpack a jpg file, then recompress it using a different method, and sent
it along. Digital cameras have resolutions from 1 megapixel to 6
megapixel,
giving image dimensions of around 1000x1000 to 2500x2500. This is already
the regime where jpeg2000 gets interesting compared to traditional jpeg,
especially in the high-compression regime.

So long,
Thomas[/quote]

Sie · Guest

I agree but maybe when the log shows figures of jpeg compression between 50%
and 80% constant and not below then you begin to question :)

Sie

"Geoff T" <geofft@mail.com> wrote in message
news:d433f9a7.0308201825.da9932e@posting.google.com...
[quote]"Sie" <nospam_s.jones@expressandstar.co.uk> wrote in message
news:<0jG0b.88628$CQ.727964@news.easynews.com>...

(snipped)

compresses them up to 80% compression before transfer!
------------------^^^^^

There is the problem: "up to" also contains the number zero.

Sign up to my pyramid scheme - you may be earning up to $10,000 per
week in as little as 14 days!! :)

- Geoff T[/quote]

Severian · Guest

On Thu, 21 Aug 2003 09:29:36 GMT, "Sie"
<nospam_s.jones@expressandstar.co.uk> wrote:

[quote]I agree but maybe when the log shows figures of jpeg compression between 50%
and 80% constant and not below then you begin to question :)

[/quote]
Could you post for download an original JPEG and a copy after transfer
through their system? Then we can compare and see whether the file is
changing at all.

Also, the percentage in *their* log file may not be related to the
original JPEG file length -- it could be based on the memory
(uncompressed) size.

It could also simply be fiction as far as the number of bytes
transferred. Try transferring the exact same file several times; for
lossless compression, the result should be exactly the same for each
transfer. You may also want to measure the network transfer separately
from their program. For example, compare the amount of data
transferred using FTP to their system.

- Sev

PS. Don>t compare their system to e-mail, as e-mail adds significant
overhead because the transfers are encoded for ASCII transfer. Just
about any binary transfer will out-perform MIME-encoded email, by as
much as 30-40%!

Edward Wildgoose · Guest

[quote]Unfortunately this is already too much like hard work for a photographer.
I
understand where you are coming from but our photographers are not very
computer literate and are not really prepared to do more than the most
simplistic of procedures. Through my experience with digital cameras I can
presume that the file size we normally get from there submitted file means
they probably use no more than 1.2m pixels for each shot (1.2mp usually
creates a file size 200-400k). I can guarantee they do not do any
processing
on the files. Remember as simple as possible :) ).
[/quote]
I appreciate what you are saying, but aside from some amazing compression
algorithm which this supposed program is doing then it sounds like you are
better off using your money to buy some software which works with your
workflow, eg something simple and easy to use that the photographers can
drop their photos on and have them come out in the correct size/format, etc.

I>m not in that industry, but I>m sure that while browsing through some
image library links I saw mention of some software for journalists, kind of
like, takes all their photos, lets them pick the ones to upload, then
resizes, them etc to the size that you specified for your publication and
handles the automatic upload to your site.

For reference email encodes binary files in a certain way that makes them
about 30% larger than the original (and hence slower to download), so on
average you can speedup your journalists transmit speed (over email) by
around 30% just by using some kind of over the wire compression which is
effectively going to reverse out the effect of the funny encoding of
attachments. Easiest way to do this is actually find an ISP which does
compression between you and them automatically (PPP compression is built
into windows and your modem and has been for 20 years), not many ISP>s in
the UK seem to offer this, but you get a significant speedup from those who
do (It>s not super magic research grade compression, but it>s going to get
you 60%+ of what is possible)

Hope that gives you some starting points.

Ed W

Sie · Guest

Sorry I won>t have access for a while as it is not really my project as I am
a web developer and I only got involved because I could create an uploading
facility for nothing but without compression. My alternative would be free
as oppose to the £5000 software that claims to get this compression which I
doubt. If I can prove it my system will win out.

I will see if I can get access to before and after images and the results of
the log reflecting how they were xfered the next time they have it up and
running for testing.

Thanks for all your help everyone.

Sie

"Severian" <severian@chlamydia-is-not-a-flower.com> wrote in message
news:ficakvktf5nemtek783chj03fv26rcm1k1@4ax.com...
[quote]On Thu, 21 Aug 2003 09:29:36 GMT, "Sie"
nospam_s.jones@expressandstar.co.uk> wrote:

I agree but maybe when the log shows figures of jpeg compression between
50%
and 80% constant and not below then you begin to question :)

Could you post for download an original JPEG and a copy after transfer
through their system? Then we can compare and see whether the file is
changing at all.

Also, the percentage in *their* log file may not be related to the
original JPEG file length -- it could be based on the memory
(uncompressed) size.

It could also simply be fiction as far as the number of bytes
transferred. Try transferring the exact same file several times; for
lossless compression, the result should be exactly the same for each
transfer. You may also want to measure the network transfer separately
from their program. For example, compare the amount of data
transferred using FTP to their system.

- Sev

PS. Don>t compare their system to e-mail, as e-mail adds significant
overhead because the transfers are encoded for ASCII transfer. Just
about any binary transfer will out-perform MIME-encoded email, by as
much as 30-40%!
[/quote]


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
Page 1 of 1