libjpeg

[Jason W]

Thanks to jpeters for libjpeg:

Code: [Select]

Title: libjpeg.tcel
Description:    The libjpeg package contains libraries that allow compression
of image files based on the Joint Photographic Experts Group
standard. It is a "lossy" compression algorithm.
Version: 6b
Author: Maintained by the Independent JPEG Group
Original-site: http://www.linuxfromscratch.org/blfs/view/svn/general/libjpeg.html
Copying-Policy: Free
Extension_by: jpeters
Comments:           
Size: 212K
Current:      2009/05/11 Original




Code: [Select]

Title: libjpeg.tczl
Description:    The libjpeg package contains libraries that allow compression
of image files based on the Joint Photographic Experts Group
standard. It is a "lossy" compression algorithm.
Version: 6b
Author: Maintained by the Independent JPEG Group
Original-site: http://www.linuxfromscratch.org/blfs/view/svn/general/libjpeg.html
Copying-Policy: Free
Extension_by: jpeters
Comments:           
Size: 260K
Current:      2009/05/11 Original




[Juanito]

This looks like it contains the same libs as the base tinycore and the same devs as the base-devs extension - but maybe I'm wrong?

Edit: ..and it contains the man files 

[jpeters]

You're right. I  think I searched for libjpg instead of libjpeg, so thought they were missing.
re manual pages: I actually read them with my man script at times, and have gotten away from DSL mentality a bit.
Let's scrap the extension....

[Jason W]

Extension has been pulled upon request.

[Juanito]

Let's scrap the extension....

No need to do that neccessarily - there's the jpeg apps that are not in the base that might be useful?

[Jason W]

You're right.  It certainly can't hurt to have the extension available.  I will reupload it.

[Juanito]

..but maybe (especially for the tcz), it would be better to remove the libs and headers?

[jpeters]

Given the libs are already in base, the only use will be for developers who want the complete blfs package....it's unlikely that a few kb will matter unless you have other reasons for splitting things up.  

[^thehatsrule^]

Do they overwrite base libs?  I think it's good practice to not do so, esp. when not needed.

[mcewanw]

I thought I read in another thread that it was agreed that it was bad practice to duplicate libs.  It is surely important to have tight guidelines about that since it is easier to avoid such bloat than to try and deal with it later when TC repository is much larger and it becomes practically impossible to fix such matters.

This is Tiny Core and it is a miracle high efficiency and lowest bloat; whilst I accept that mistakes can happen, and existing libs not noticed, it is otherwise no great effort surely to take care and avoid lib duplication? The occasional mistake can easily be remedied by simply taking out any duplication and resubmitting but not if duplication becomes standard as generally acceptable practice. I think that contributors should be asked to concentrate on getting the dep file right and let users install extra libs only when necessary.

[EDIT] Of course developers would need to then spend some extra time checking lib dependencies and if using libs not already available in the TC repository it becomes part of the task to submit versions of these libs as packages. If individual lib packages is too cumbersome then a collection of libs would still be better surely than mixing them up with the main package submissions all the time (I'm not saying such mixing and duplication can always be avoided, but often it can).

[tobiaus]

Do they overwrite base libs?  I think it's good practice to not do so, esp. when not needed.

thank you, i wondered the same. i don't think it's good practice to have extensions that (unnecessarily) compromise the base... i didn't even think it was possible to have extensions compromise the base, but there is tce and tcz and last i heard/misheard, one does overwrite and the other doesn't. EDIT: although obviously our concern here is misplaced, that's nice.

[jpeters]

Do they overwrite base libs?  I think it's good practice to not do so, esp. when not needed.

Of course not...it's written to /usr/local/lib   

[jpeters]

I looked into this issue a bit.   

1. this was compiled into /usr/local, so there's no conflict with base anything.
2.  it was compiled with --enable-static and --enable-shared, so base libjpeg.so.62.0.0  is not same (despite the same name)  The compiled is 543 lines vs base 251 lines. 
3. the compiled libjpeg.so.la clearly states where the compiled libs have to be located, in this case /usr/local/lib. 
4. the compiled libs support  jpeg functions not included in base. Briefly they include:
djpeg:
   decompresses image files from JPEG/JFIF format to either PPM (PBMPLUS color format), PGM (PBMPLUS gray-scale format), BMP, or Targa format.
jpegtran:
   is used for lossless transformation of JPEG files.
rdjpgcom:
   displays text comments from within a JPEG file.wrjpgcom
wrjpgcom:
   inserts text comments into a JPEG file.
5. On complaints about including docs,"bloat",etc.  The docs in man1 are --help files, 4K a piece for each of the above commands.
When you type "djpeg --help", for example, it lists all the switches and usage:

Code: [Select]

usage: djpeg [switches] [inputfile]
Switches (names may be abbreviated):
  -colors N      Reduce image to no more than N colors
  -fast          Fast, low-quality processing
  -grayscale     Force grayscale output
  -scale M/N     Scale output image by fraction M/N, eg, 1/8
  -bmp           Select BMP output format (Windows style)
  -gif           Select GIF output format
  -os2           Select BMP output format (OS/2 style)
  -pnm           Select PBMPLUS (PPM/PGM) output format (default)
  -targa         Select Targa output format
Switches for advanced users:
  -dct int       Use integer DCT method (default)
  -dct fast      Use fast integer DCT (less accurate)
  -dct float     Use floating-point DCT method
  -dither fs     Use F-S dithering (default)
  -dither none   Don't use dithering in quantization
  -dither ordered  Use ordered dither (medium speed, quality)
  -map FILE      Map to colors used in named image file
  -nosmooth      Don't use high-quality upsampling
  -onepass       Use 1-pass quantization (fast, low quality)
  -maxmemory N   Maximum memory to use (in kbytes)
  -outfile name  Specify name for output file

This package is from BLFS, and configured according to their recommendations.  The descriptions are copied from the BLFS book.  I have no problem with including/not including/removing the manuals/removing the libs/ etc, etc.  The license is free...people can do whatever they like to suit their own purposes.

note: As noted above, I only submitted this because I was too stupid to grep the correct lib name, so thought it wasn't in base.  I've got a growing directory full of these extensions for my own use....all with manuals, since I need all the help I can get 

[^thehatsrule^]

1-2. Note that .so files are shared/dynamic libraries.  What lines are you talking about?  If you meant size differences, it would probably be due to the compiler/optimizer flags, etc.

Essentially, this would create some redundancy in having 2 of the same libs.  Also, the loader will probably use /usr/lib first.. In this case the base library will always be used by default.

4. Afaik those are userland tools, so they can probably be used with the base library as well.

5. If the docs are large, they can be separated into another extension or always separated to keep things more modularized - but (so far) that decision is left to the maintainer.

[jpeters]

1-2. Note that .so files are shared/dynamic libraries.  What lines are you talking about?  If you meant size differences, it would probably be due to the compiler/optimizer flags, etc.

---looks like more than optimizer flags.  For lines, I compared  "vim /libjpeg.so.62.0.0.       

Essentially, this would create some redundancy in having 2 of the same libs.  Also, the loader will probably use /usr/lib first.. In this case the base library will always be used by default.

That's my understanding also. Without the extension, base is used.  With the extension /usr/local is used. 

4. Afaik those are userland tools, so they can probably be used with the base library as well.

The switches build both static and shared libraries, as recommended by BLFS. I think I compiled once without switches, and it produced the apps without the libs....so that might be a possibility.  I'd like to be convinced the base libs have the same functionality, however.  When things don't work, it's hard to trace it back to the 5k squeezed from wherever in the base.