ziproxy-users Mailing List for ziproxy (Page 21)
Brought to you by:
dmcabrita
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(10) |
Oct
(6) |
Nov
(26) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(17) |
Feb
|
Mar
(7) |
Apr
(3) |
May
(9) |
Jun
(8) |
Jul
(11) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(9) |
Jul
(9) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
2006 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(1) |
May
(15) |
Jun
(14) |
Jul
(36) |
Aug
(2) |
Sep
(5) |
Oct
(8) |
Nov
(17) |
Dec
(14) |
2007 |
Jan
(15) |
Feb
(12) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(2) |
Sep
(6) |
Oct
(5) |
Nov
(4) |
Dec
(4) |
2008 |
Jan
(14) |
Feb
|
Mar
(8) |
Apr
(2) |
May
(15) |
Jun
(5) |
Jul
|
Aug
|
Sep
(1) |
Oct
(5) |
Nov
(9) |
Dec
(2) |
2009 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(3) |
Jul
|
Aug
(7) |
Sep
(11) |
Oct
(21) |
Nov
(7) |
Dec
(7) |
2010 |
Jan
(3) |
Feb
(7) |
Mar
(31) |
Apr
(1) |
May
(5) |
Jun
(30) |
Jul
(9) |
Aug
(23) |
Sep
(8) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2011 |
Jan
(1) |
Feb
(11) |
Mar
(7) |
Apr
|
May
(12) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2012 |
Jan
(3) |
Feb
(9) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(6) |
Jun
(1) |
Jul
|
Aug
|
Sep
(4) |
Oct
(8) |
Nov
(4) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ldd <ld...@st...> - 2004-01-22 22:39:30
|
I=B4m trying to install ziproxy on freebsd 4,5 but I=B4m having = troubles. I receive a message that it can=B4t find libConfuse : ./configure --with-gif=3D/usr/local --with-confuse=3D/usr/local ... hecking dependency style of gcc... gcc checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for libraries containing socket functions... -lc checking for gzopen in -lz... yes checking for pow in -lm... yes checking for library containing DGifSlurp... -lungif checking for jpeg_start_decompress in -ljpeg... yes checking for cfg_free_value in -lconfuse... no checking for cfg_free_val in -lconfuse... no configure: error: libConfuse not found. I=B4ve installed libConfuse 2.1 without any problem :=20 ./configure make make install=20 n/sh ../support/mkinstalldirs /usr/local/lib /bin/sh ../libtool --mode=3Dinstall /usr/bin/install -c libconfuse.la = /usr/local/lib/libco nfuse.la /usr/bin/install -c .libs/libconfuse.lai /usr/local/lib/libconfuse.la /usr/bin/install -c .libs/libconfuse.a /usr/local/lib/libconfuse.a ranlib /usr/local/lib/libconfuse.a chmod 644 /usr/local/lib/libconfuse.a ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- /bin/sh ../support/mkinstalldirs /usr/local/include /usr/bin/install -c -m 644 confuse.h /usr/local/include/confuse.h May someone know how to do and help me? Thanks. |
From: Cheuk-san E. W. <wa...@ai...> - 2004-01-21 00:54:02
|
On Tue, Jan 20, 2004 at 06:58:57PM -0500, Will wrote: > Just curious, what version of libungif do the developers use as a basis for > testing? > I use this [wang@husband ~]$ rpm -q libungif libungif-4.1.0-15 Cheuksan Wang |
From: Will <ws...@99...> - 2004-01-20 23:59:06
|
Just curious, what version of libungif do the developers use as a basis for testing? Will |
From: Juraj V. <va...@na...> - 2004-01-18 22:13:01
|
On Saturday 17 January 2004 09:06, Michael Opdenacker wrote: > >What about using ImageMagick? It is free, has many packages for various > >distros and supports all kinds of image formats. > > It's true, ImageMagick sounds like the most natural choice for doing > this. Plus, it's got APIs for C, C++, Perl, Java, PHP, Python and Ruby... I whole-heartedly agree. But the point is, that until now I hadn't any access to an server where I would be able to install it. I couldn't demand it from administrators, nor it would fit in my quota. Now I haven't enough free time to. Even adding and testing of one quite simple option (AllowLookChange) took me a month.... This led me to idea to get away from C, to lower the barrier for implementing more such features. Juraj |
From: Michael O. <zu...@fr...> - 2004-01-17 08:06:38
|
>What about using ImageMagick? It is free, has many packages for various >distros and supports all kinds of image formats. > > It's true, ImageMagick sounds like the most natural choice for doing this. Plus, it's got APIs for C, C++, Perl, Java, PHP, Python and Ruby... Cheers, Michael. -- Michael Opdenacker http://opdenacker.org/ |
From: wspigel <ws...@99...> - 2004-01-17 02:54:13
|
What about using ImageMagick? It is free, has many packages for various distros and supports all kinds of image formats. Will ----- Original Message ----- From: "Juraj Variny" <va...@na...> To: <zip...@li...> Sent: Friday, January 16, 2004 3:20 PM Subject: [Ziproxy-users] Re: Shrinking images? > > I've had a look at the HTTP header specifications, and found no standard > > way for a client to tell the server (the proxy in our case) about its > > screen size. I'm just thinking of transferring this through a comment > > in the User-Agent header, which wouldn't be too ugly. > > Yes, most near there is the Accept: header. > But IMHO this is an thing that could be solved with CSS, but hardly one > webmaster bothers it. > > > Of course, this wouldn't be trivial to implement in the proxy, as it > > would have to take into account the HTML width and height settings of > > images, as well as their actual sizes... > > This would require choosing more general-purpose image library, as I'm tired > from coding image transformations in C. Maybe we can return to libgd > (original mwp_proxy used it) if it does support GIFs now. HTML modification > is already there, but it is quite brittle, too. > > I'm thinking about to move some parts of ziproxy away from C, say into Python > (as near as ... summer holidays?). Then it may be much easier to use another > backend(s) for image manipulation. Stay tuned. > > Juraj > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Ziproxy-users mailing list > Zip...@li... > https://lists.sourceforge.net/lists/listinfo/ziproxy-users > > |
From: Juraj V. <va...@na...> - 2004-01-17 02:28:43
|
> I've had a look at the HTTP header specifications, and found no standard > way for a client to tell the server (the proxy in our case) about its > screen size. I'm just thinking of transferring this through a comment > in the User-Agent header, which wouldn't be too ugly. Yes, most near there is the Accept: header. But IMHO this is an thing that could be solved with CSS, but hardly one webmaster bothers it. > Of course, this wouldn't be trivial to implement in the proxy, as it > would have to take into account the HTML width and height settings of > images, as well as their actual sizes... This would require choosing more general-purpose image library, as I'm tired from coding image transformations in C. Maybe we can return to libgd (original mwp_proxy used it) if it does support GIFs now. HTML modification is already there, but it is quite brittle, too. I'm thinking about to move some parts of ziproxy away from C, say into Python (as near as ... summer holidays?). Then it may be much easier to use another backend(s) for image manipulation. Stay tuned. Juraj |
From: James H. <fre...@co...> - 2004-01-16 23:08:04
|
On Friday 16 January 2004 11:45 am, Michael Opdenacker wrote: > I've had a look at the HTTP header specifications, and found no standard > way for a client to tell the server (the proxy in our case) about its > screen size. =A0I'm just thinking of transferring this through a comment > in the User-Agent header, which wouldn't be too ugly. You can use javascript to determine a browsers screen resolution and provid= e=20 content accordingly. Of course this depends on your browser supporting=20 javascript.=20 The only way I see any proxy being able to negotiate this is by the website= =20 user changing the client name that the browser reports. Not all browsers=20 allow for this. =2D-=20 James Hicks Read "The Law", a classic blueprint for a just society,=20 at http://bastiat.org/en/the_law.html . |
From: Juraj V. <va...@na...> - 2004-01-16 19:29:20
|
I don't know of any. But as ziproxy follows GNU standard, it should be easy to make debian package from software using "checkinstall" tool. Juraj On Thursday 15 January 2004 18:36, Leandro Machado wrote: > Helo list, > Where i can find debian package of ziproxy? |
From: Michael O. <zu...@fr...> - 2004-01-16 16:45:48
|
Hello, Another comment related to PDAs and mobile phones... It could be useful if the proxy could also shrink images for these devices with small displays. In addition to compression, this would further reduce image file sizes. For example, on my 240x320 display, when I browse the Google site, the Google logo is as wide as my screen, while I'd like to keep the same proportion as on my notebook, e.g. 1/3 of the display width. I've had a look at the HTTP header specifications, and found no standard way for a client to tell the server (the proxy in our case) about its screen size. I'm just thinking of transferring this through a comment in the User-Agent header, which wouldn't be too ugly. Of course, this wouldn't be trivial to implement in the proxy, as it would have to take into account the HTML width and height settings of images, as well as their actual sizes... Any comments or suggestions? Cheers, Michael. -- Michael Opdenacker http://opdenacker.org/ |
From: Michael O. <zu...@fr...> - 2004-01-16 15:34:33
|
Hello, I'm new to this list and I couldn't check the archives (http://sourceforge.net/mailarchive/forum.php?forum=ziproxy-users seem to be down at the moment) to see if this has already been said before... Ziproxy's home page says that it's intended to free bandwidth on dialup connections. While more and more people get access to high bandwidth Internet access, this may no longer be an issue. However, mobile phones and PDAs that are used to browse the web definitely need such a tool, for bandwidth reasons of course, to reduce the time opening pages, but also mainly to reduce connection costs. With 2.5G or 3G, you know that you don't pay for the time you spend, but for the number of bits you transfer over the air. Using a compressing proxy like ziproxy can make a very significant difference on the bill! For example, I'm soon going to have a GPRS subscription with 5 MB for 6 euros (~5 USD) per month, and I will be charged 15 euros for each additional MB! I'd better stay within the 5MB limit... Perhaps you could mention this usage on ziproxy's home page... At least, that's what I'm going to use ziproxy for! Thanks for developing this tool! Cheers, Michael. -- Michael Opdenacker http://opdenacker.org/ |
From: Leandro M. <le...@te...> - 2004-01-15 17:39:09
|
Helo list, Where i can find debian package of ziproxy? |
From: Will <ws...@99...> - 2004-01-12 21:45:27
|
Seems to work just fine here. I would add the option to the default ziproxy.conf file and to the README since this new option before you release it as a new stable build, it isn't in either one right now. Will ----- Original Message ----- From: "Juraj Variny" <va...@na...> To: <zip...@li...> Sent: Saturday, January 10, 2004 4:47 PM Subject: [Ziproxy-users] Exclude Image file types possible - DONE (Sorry if this is a duplicated message. I've made a typo, but it could been delivered.) > I think best would be to implement more generalized version of CompressGif > option, an > > AvoidLookChange = yes/no > > This option when set to yes, will cause ziproxy: > * not to compress images with transparency (prevent inconsistent > background color), both GIFs and PNGs. > * not to compress animated GIFs > * disable possible other future features that may cause the page look > change too drastically. I imlemented this as AllowLookChange option. It has exactly inverted meaning as AvoidLookChange option proposed above. Package ziproxy-10012004.tar.gz is available for testing and it may become an 1.3c version later. http://prdownloads.sourceforge.net/ziproxy/ziproxy-10012004.tar.gz?download Just in case you wonder about increased package size: I've used latest automake/autoconf to make it working with BSD make. The outcoming configure script is unexpectedly large. Juraj ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Ziproxy-users mailing list Zip...@li... https://lists.sourceforge.net/lists/listinfo/ziproxy-users |
From: Juraj V. <va...@na...> - 2004-01-10 21:48:18
|
(Sorry if this is a duplicated message. I've made a typo, but it could been delivered.) > I think best would be to implement more generalized version of CompressGif > option, an > > AvoidLookChange = yes/no > > This option when set to yes, will cause ziproxy: > * not to compress images with transparency (prevent inconsistent > background color), both GIFs and PNGs. > * not to compress animated GIFs > * disable possible other future features that may cause the page look > change too drastically. I imlemented this as AllowLookChange option. It has exactly inverted meaning as AvoidLookChange option proposed above. Package ziproxy-10012004.tar.gz is available for testing and it may become an 1.3c version later. http://prdownloads.sourceforge.net/ziproxy/ziproxy-10012004.tar.gz?download Just in case you wonder about increased package size: I've used latest automake/autoconf to make it working with BSD make. The outcoming configure script is unexpectedly large. Juraj |
From: Juraj V. <va...@na...> - 2004-01-10 21:34:17
|
On Tuesday 02 December 2003 23:23, Juraj Variny wrote: > Hi, > > I think best would be to implement more generalized version of CompressGif > option, an > > AvoidLookChange = yes/no > > This option when set to yes, will cause ziproxy: > * not to compress images with transparency (prevent inconsistent > background color), both GIFs and PNGs. > * not to compress animated GIFs > * disable possible other future features that may cause the page look > change too drastically. I imlemented this as AllowLookChange option. It has exactly inverted meaning as AvoidLookChange option proposed above. Package ziproxy-10012004.tar.gz is available for testing and it may become an 1.3c version later. http://prdownloads.sourceforge.net/ziproxy/ziproxy-10012004.tar.gz?download Just in case you wonder about increased package size: I've used latest automake/autoconf to make it working with BSD make. The outcoming configure script is unexpectedly large. Juraj |
From: wspigel <ws...@99...> - 2003-12-03 06:58:20
|
Here's a review of a similar ziproxy program. http://www.dansdata.com/propel.htm This one has a client side application to control compression levels. I suspect similar things could be done with multiple server side configs and with a multitude of ports. Example: 8080 = Standard Compression, faster then dial-up alone, fairly hi quality images 8081 = Maximum compression 8082 = Medium Compression 8083 = Low Compression 8084 = Txt/HTML compression, no image compression I'll have to play with this to see if it can be done. |
From: wspigel <ws...@99...> - 2003-12-03 03:41:27
|
That sounds fantastic! I look forward to hearing what you come up with. ----- Original Message ----- From: "Juraj Variny" <va...@na...> To: <zip...@li...> Sent: Tuesday, December 02, 2003 5:23 PM Subject: [Ziproxy-users] Re: Exclude Image file types possible - SUMMARY > Hi, > > I think best would be to implement more generalized version of CompressGif > option, an > > AvoidLookChange = yes/no > > This option when set to yes, will cause ziproxy: > * not to compress images with transparency (prevent inconsistent background > color), both GIFs and PNGs. > * not to compress animated GIFs > * disable possible other future features that may cause the page look change > too drastically. > > I'm inclined to implement CompressionThreshold, too, maybe I'll do some > statistics/research on this. > > However, next two weeks I won't be able to code anything. > > Juraj > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Ziproxy-users mailing list > Zip...@li... > https://lists.sourceforge.net/lists/listinfo/ziproxy-users > |
From: Juraj V. <va...@na...> - 2003-12-02 22:26:07
|
Hi, I think best would be to implement more generalized version of CompressGif option, an AvoidLookChange = yes/no This option when set to yes, will cause ziproxy: * not to compress images with transparency (prevent inconsistent background color), both GIFs and PNGs. * not to compress animated GIFs * disable possible other future features that may cause the page look change too drastically. I'm inclined to implement CompressionThreshold, too, maybe I'll do some statistics/research on this. However, next two weeks I won't be able to code anything. Juraj |
From: Juraj V. <va...@na...> - 2003-11-30 20:02:07
|
Hi, > For example: > ImageQuality = {30, 40, 23, 25}. > CompressionThreshold = {0.50, 0.45, 0.55, 0.52} This makes some sense. I'm already using this (wildly) guessed formula: outlen = insize * 0.85 + 30; and then if image won't fit into outlen, it is kept as is. It wouldn't be hard to change the formula to insize*(Threshold value). And, should there be an option to avoid producing PNGs ? But PNGs are used quite much even without using ziproxy. Can't be png.dll or such thing on the Mac replaced? Can't be ziproxy-1.2b used? Juraj |
From: Will <ws...@99...> - 2003-11-29 23:29:13
|
PNG's crashing Macintosh browsers is not ziproxy's fault, rather it is a bug in Internet Explorer. God only knows why this happens to Macintosh computers because it seems to work fine on everything else. Will ----- Original Message ----- From: "Juraj Variny" <va...@na...> To: <zip...@li...> Sent: Saturday, November 29, 2003 7:28 AM Subject: [Ziproxy-users] Re: Exclude Image file types possible? > Think about a typical .gif file; it's pretty small with the exception of > animated gifs. When you recompress a .gif file you don't generally gain a > whole lot. Now think about how cruddy a page looks when the transparency is > removed. You could argue that the site should use PNG files but PNG files > can actually crash some browsers on Macintosh computers if they are over a > certain size. I found that out the hard way when I used png files for an > logo and ended up converting them back to gifs in order to fix > compatibility problems. > While you can barely tell (quality wise) when a > jpeg is recompressed it is really noticeable when a .gif suddenly becomes > fully solid and ruins the look of a page. Sorry I've overlooked this. Crashing one's browser is a real problem and I will look to your patch. The best solution to second problem would be an JPEG2000 format. This is in most cases not applicable, so only possibilities are: a) GIF->PNG conversion only (may crash browser) b) background color guessing (need to parse a HTML-> overkill) c) nothing to do (but there are some huge GIFs, which may choke your connection...) Seems I will add an option to let people choose between normal, a) and c) behaviors. Any idea what another possible option is there? Juraj ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Ziproxy-users mailing list Zip...@li... https://lists.sourceforge.net/lists/listinfo/ziproxy-users |
From: Knute J. <kn...@fr...> - 2003-11-29 21:02:04
|
>Client Side Programs: > >Any time you put anything on the client machine it has an increased >chance to disturb the delicate operations within. A client side >program is more trouble then it is worth and for each person I have to >help configure a client is a chunk out of my day. In addition, there >isn't one single program out there that you can use on Windows 95, >WindowsXP, Windows 2000, Macintosh 7, 8, 9, X, and Linux which means I >have to maintain setup instructions for each distribution not to >mention different client packages have different features. Excactly >I rather keep everything server side, force everyone to use a >mozilla/Netscape browser (available on all platforms) and maintain one >set of instructions on how to set up ziproxy. See...wasn't that >easier? :) Not so easily done in the wild. Our application of Ziproxy will only have to work with Windows and IE 5 or later fortunately. We are trying to find a way to configure the proxy without any user input. We haven't quite done that yet though. You latest comments (which I deleted) are starting to make it a lot more complicated and I can see where you would end up with some things getting compressed that you don't want and some not that you do. It might make more sense to go back to your original request and just hava switch to turn off compression of gif images. As you said they are usually small. If they aren't then they have more information that you might want to see. I am curious about your comments on the PNG images crashing Macs. Is that a browser problem or a Mac problem? PNG images have significant advantages over GIFs. -- Knute Johnson Molon Labe... |
From: Will <ws...@99...> - 2003-11-29 19:28:52
|
Client Side Programs: Any time you put anything on the client machine it has an increased chance to disturb the delicate operations within. A client side program is more trouble then it is worth and for each person I have to help configure a client is a chunk out of my day. In addition, there isn't one single program out there that you can use on Windows 95, WindowsXP, Windows 2000, Macintosh 7, 8, 9, X, and Linux which means I have to maintain setup instructions for each distribution not to mention different client packages have different features. I rather keep everything server side, force everyone to use a mozilla/Netscape browser (available on all platforms) and maintain one set of instructions on how to set up ziproxy. See...wasn't that easier? :) ImageQuality: The ImageQuality setting alone is non-intuitive. An image which is 233x122 may not need to be compressed at all since it is a single, non-animated image and already optimized. Deciding whether or not to compress an image based on size and ImageQuality is much more intuitive in my humble opinion. For example, you might encounter a 60x60 .gif file which is non-animated and has a nice transparent background which is only 5K. Then you could encounter another image that is the same dimensions and animated which would be 60K. You would get little benefit (and gain side effects) from compressing the already small 5K gif image. However you'd gain a huge advantage by compressing the 60K animated one. Perhaps there should be another array of percentages which correspond to the ImageQuality array. For example: ImageQuality = {30, 40, 23, 25}. CompressionThreshold = {0.50, 0.45, 0.55, 0.52} What this would do is compare the original image size to the compressed image size. If the difference in size isn't at least X percent then send the original image instead of the recompressed one. Example: My image is 233x122 and is 7257 bytes. This falls under the "ImageQuality" section with the "40" in it. The image is then compressed and the resulting size is 5762 bytes. The two sizes are then compared to one another 5762/7257 = 0.79, 1.0 - 0.79 = 0.21 savings. This savings amount is then compared to the corresponding "CompressionThreshold" which is "0.45". Since the savings of the file compression isn't greater then the minimum 45% of the original, it would then send the original image instead of the compressed one. If we do that same function for a theoretical animated gif it would look like this: Example 2: My image is 233x122, animated and is 53,245 bytes. This also falls under the ImageQuality section with the "40" in it. Ziproxy then compresses this image and stops the animation resulting in an image which is 7898 bytes. The two sizes compared to one another 7898 / 53245 = .14, 1.0 - .14 = 0.86 savings. This new savings amount is compared to the corresponding "CompressionThreshold" which is "0.45". Since the savings of the compresses file is 86% of the original it falls above the minimum threshold of 45% it would then send the compressed image instead of the original one. Does this make sense or am I completely off my rocker here. I'm trying to preserve what looks good on the internet while trying to cut out the bloat. Will ----- Original Message ----- From: <va...@na...> To: <zip...@li...> Sent: Saturday, November 29, 2003 7:12 AM Subject: [Ziproxy-users] Re: Exclude Image file types possible? Hi, On Friday 28 November 2003 23:34, Will wrote: > a gif file 233 x122 pixels (a "larger" .gif file) > 7257 bytes Original size with transparency > 5762 bytes after ziproxy, lost transparency now the gif background is > different from web page background > 1495 bytes difference Well, you can configure existing ziproxy-1.3b this way: 233x112 = approx. 26000 pixels. Thus it falls into second category of images ("between 5000 and 50000 pixels or one dimension is smaller than 150 pixels"). You can then set ImageQuality option this way: ImageQuality= {0, 0, 23, 25}. This will cause ziproxy to avoid compressing small images at all. You can then try to increase the latter values to decrease the ugliness of larger images to acceptable level. It's maybe complicated, I know. But once you set this up whatever you like, you can mind it no more. > I'd rather keep the theme and look of the page and take half a second > longer to load. Well this could be done with existing setup, I think. If you set ImageQuality to be large enough, most gifs will be kept unchanged. > You can modify how much compression you get with a jpg and alter whether or > not it should recompress it at all, why not allow the same capability to > choose whether or not to recompress .gif files? I don't see any reason > _not_ to include some kind of exclusion list; it would empty by default and > ultimately it would be up to the user whether to activate the feature or > not. I dont see any reason _not_ to include it. But I don't see the reason to include it, either. If you explain why or where ImageQuality is not sufficient, I will. I'm open to discuss this. > Keep in mind that ziproxy also recompresses jpegs, bmp, html, text, > JavaScript and a whole slew of other web components which will help keep it > snappy and responsive. By allowing the individual to surf they way they > want to surf, it increases both the flexibility and value of the program. As Knute pointed it out, this is better to do on client side. Then you needn't to go through ziproxy (and start new process on server, and create yet another connection, etc...) at all in these cases. Juraj ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Ziproxy-users mailing list Zip...@li... https://lists.sourceforge.net/lists/listinfo/ziproxy-users |
From: Juraj V. <va...@na...> - 2003-11-29 12:27:31
|
> Think about a typical .gif file; it's pretty small with the exception of > animated gifs. When you recompress a .gif file you don't generally gain a > whole lot. Now think about how cruddy a page looks when the transparency is > removed. You could argue that the site should use PNG files but PNG files > can actually crash some browsers on Macintosh computers if they are over a > certain size. I found that out the hard way when I used png files for an > logo and ended up converting them back to gifs in order to fix > compatibility problems. > While you can barely tell (quality wise) when a > jpeg is recompressed it is really noticeable when a .gif suddenly becomes > fully solid and ruins the look of a page. Sorry I've overlooked this. Crashing one's browser is a real problem and I will look to your patch. The best solution to second problem would be an JPEG2000 format. This is in most cases not applicable, so only possibilities are: a) GIF->PNG conversion only (may crash browser) b) background color guessing (need to parse a HTML-> overkill) c) nothing to do (but there are some huge GIFs, which may choke your connection...) Seems I will add an option to let people choose between normal, a) and c) behaviors. Any idea what another possible option is there? Juraj |
From: Juraj V. <va...@na...> - 2003-11-29 12:11:04
|
Hi, On Friday 28 November 2003 23:34, Will wrote: > a gif file 233 x122 pixels (a "larger" .gif file) > 7257 bytes Original size with transparency > 5762 bytes after ziproxy, lost transparency now the gif background is > different from web page background > 1495 bytes difference Well, you can configure existing ziproxy-1.3b this way: 233x112 = approx. 26000 pixels. Thus it falls into second category of images ("between 5000 and 50000 pixels or one dimension is smaller than 150 pixels"). You can then set ImageQuality option this way: ImageQuality= {0, 0, 23, 25}. This will cause ziproxy to avoid compressing small images at all. You can then try to increase the latter values to decrease the ugliness of larger images to acceptable level. It's maybe complicated, I know. But once you set this up whatever you like, you can mind it no more. > I'd rather keep the theme and look of the page and take half a second > longer to load. Well this could be done with existing setup, I think. If you set ImageQuality to be large enough, most gifs will be kept unchanged. > You can modify how much compression you get with a jpg and alter whether or > not it should recompress it at all, why not allow the same capability to > choose whether or not to recompress .gif files? I don't see any reason > _not_ to include some kind of exclusion list; it would empty by default and > ultimately it would be up to the user whether to activate the feature or > not. I dont see any reason _not_ to include it. But I don't see the reason to include it, either. If you explain why or where ImageQuality is not sufficient, I will. I'm open to discuss this. > Keep in mind that ziproxy also recompresses jpegs, bmp, html, text, > JavaScript and a whole slew of other web components which will help keep it > snappy and responsive. By allowing the individual to surf they way they > want to surf, it increases both the flexibility and value of the program. As Knute pointed it out, this is better to do on client side. Then you needn't to go through ziproxy (and start new process on server, and create yet another connection, etc...) at all in these cases. Juraj |
From: wspigel <ws...@99...> - 2003-11-29 00:51:44
|
I added the proper code in order for someone to choose whether or not = they want to compress a gif file. A variable called "CompressGif" is = added to the ziproxy.conf file and controls whether to compress a gif or = have it pass through untouched. CompressGif =3D (true/false) The archive can be found at my website: http://www.vadakill.com/files/ziproxy-1.3b-wspigel.tar.gz All modified lines are commented with "wspigel", feel free to = incorporate it into the main distribution if you like. |