project-navigation
Personal tools

Author Topic: New jpeg version (8b)  (Read 5306 times)

Offline mikeg

  • Rookie
  • ***
  • Posts: 24
    • View Profile
New jpeg version (8b)
« on: October 04, 2010, 10:47:28 pm »
Hello forum,

first let me say hello to all. I played UFO in the early days. Now I really like the idea to give this very cool game a new fresh face and want to contribute the work if I am able to do it.

In the meanwhile I keep on translating the missing texts into german which is my native language.

I'm a software developer which is able to code in C(++) and Java with a intermediate knowlegde about the basics.

Now I try to look what is possible regarding new versions of the used libraries. First I want to investigate the libjpeg. I tried to download the 6b but had to search a couple of minutes to find it. On http://www.ijg.org the latest version is 8b. I want to ask if the project owners are willing to update? Lets take a look onto the changelog:

Quote
CHANGE LOG for Independent JPEG Group's JPEG software


Version 8b 16-May-2010
-----------------------

Repair problem in new memory source manager with corrupt JPEG data.
Thank to Ted Campbell and Samuel Chun for the report.

Repair problem in Makefile.am test target.
Thank to anonymous user for the report.

Support MinGW installation with automatic configure.
Thank to Volker Grabsch for the suggestion.


Version 8a 28-Feb-2010
-----------------------

Writing tables-only datastreams via jpeg_write_tables works again.

Support 32-bit BMPs (RGB image with Alpha channel) for read in cjpeg.
Thank to Brett Blackham for the suggestion.

Improve accuracy in floating point IDCT calculation.
Thank to Robert Hooke for the hint.


Version 8 10-Jan-2010
----------------------

jpegtran now supports the same -scale option as djpeg for "lossless" resize.
An implementation of the JPEG SmartScale extension is required for this
feature. A (draft) specification of the JPEG SmartScale extension is
available as a contributed document at ITU and ISO. Revision 2 or later
of the document is required (latest document version is Revision 3).
The SmartScale extension will enable more features beside lossless resize
in future implementations, as described in the document (new compression
options).

Add sanity check in BMP reader module to avoid cjpeg crash for empty input
image (thank to Isaev Ildar of ISP RAS, Moscow, RU for reporting this error).

Add data source and destination managers for read from and write to
memory buffers. New API functions jpeg_mem_src and jpeg_mem_dest.
Thank to Roberto Boni from Italy for the suggestion.


Version 7 27-Jun-2009
----------------------

New scaled DCTs implemented.
djpeg now supports scalings N/8 with all N from 1 to 16.
cjpeg now supports scalings 8/N with all N from 1 to 16.
Scaled DCTs with size larger than 8 are now also used for resolving the
common 2x2 chroma subsampling case without additional spatial resampling.
Separate spatial resampling for those kind of files is now only necessary
for N>8 scaling cases.
Furthermore, separate scaled DCT functions are provided for direct resolving
of the common asymmetric subsampling cases (2x1 and 1x2) without additional
spatial resampling.

cjpeg -quality option has been extended for support of separate quality
settings for luminance and chrominance (or in general, for every provided
quantization table slot).
New API function jpeg_default_qtables() and q_scale_factor array in library.

Added -nosmooth option to cjpeg, complementary to djpeg.
New variable "do_fancy_downsampling" in library, complement to fancy
upsampling. Fancy upsampling now uses direct DCT scaling with sizes
larger than 8. The old method is not reversible and has been removed.

Support arithmetic entropy encoding and decoding.
Added files jaricom.c, jcarith.c, jdarith.c.

Straighten the file structure:
Removed files jidctred.c, jcphuff.c, jchuff.h, jdphuff.c, jdhuff.h.

jpegtran has a new "lossless" cropping feature.

Implement -perfect option in jpegtran, new API function
jtransform_perfect_transform() in transupp. (DP 204_perfect.dpatch)

Better error messages for jpegtran fopen failure.
(DP 203_jpegtran_errmsg.dpatch)

Fix byte order issue with 16bit PPM/PGM files in rdppm.c/wrppm.c:
according to Netpbm, the de facto standard implementation of the PNM formats,
the most significant byte is first. (DP 203_rdppm.dpatch)

Add -raw option to rdjpgcom not to mangle the output.
(DP 205_rdjpgcom_raw.dpatch)

Make rdjpgcom locale aware. (DP 201_rdjpgcom_locale.dpatch)

Add extern "C" to jpeglib.h.
This avoids the need to put extern "C" { ... } around #include "jpeglib.h"
in your C++ application. Defining the symbol DONT_USE_EXTERN_C in the
configuration prevents this. (DP 202_jpeglib.h_c++.dpatch)

A couple of improvements maybe interesting for the developers, e.g. the ability to use RGB 32bit (with Alpha channel) and the smartscale technique.

What about that?

Regards

Mike

Offline Muton

  • Sergeant
  • *****
  • Posts: 496
    • View Profile
Re: New jpeg version (8b)
« Reply #1 on: October 05, 2010, 09:14:05 am »
> Now I try to look what is possible regarding new versions of the used libraries

You, too ;)

> libjpeg
I've switched to jpeg turbo they provide a libjpeg6 compatibility
libjpeg8 isn't compatible with libjpeg6
you need to change the code to upgrade
If i got it right (I'm not a coder)

Btw. How do you compile libs
Linux ...?

You can "join | lead" ...
http://ufoai.ninex.info/forum/index.php?topic=4689.15
http://ufoai.ninex.info/forum/index.php?topic=5425.0

> german which is my native language
Mine too

Offline bayo

  • Professional loser
  • Project Coder
  • Captain
  • ***
  • Posts: 733
    • View Profile
Re: New jpeg version (8b)
« Reply #2 on: October 05, 2010, 11:48:49 am »
Hello, and welcome.

I dont think the features you see is usefull for ufoai.

Quote
Support 32-bit BMPs (RGB image with Alpha channel) for read in cjpeg.
It only mean the tool <code>cjpeg</code> can read 32bit BMP. JPEG do not support alpha channel anyway. It is the same for smartscale.

We dont need more feature than jpeg decoding. The game do not use internally JPEG compression. Then if you want to work to support libjpeg8, i think there is no problem. You only need to rework 2 files (.c + .h). I think mattn (project leader) will accept this kind of patch.

Offline keybounce

  • Sergeant
  • *****
  • Posts: 330
    • View Profile
Re: New jpeg version (8b)
« Reply #3 on: October 08, 2010, 02:25:34 pm »
Wait a sec ...

Libjpeg 8 and 6 are different?

I know that the current code (well, 2.3 anyways) compiles and links against 8, and the older 2.2.1 does not.

But the libraries actually being different?

What would be the symptoms of a program written for 6 being used with 8?

Offline geever

  • Project Coder
  • PHALANX Commander
  • ***
  • Posts: 2555
    • View Profile
Re: New jpeg version (8b)
« Reply #4 on: October 08, 2010, 05:47:56 pm »
Wait a sec ...

Libjpeg 8 and 6 are different?

I know that the current code (well, 2.3 anyways) compiles and links against 8, and the older 2.2.1 does not.

But the libraries actually being different?

What would be the symptoms of a program written for 6 being used with 8?

Some functions were renamed in jpeg8 which became conflicted with some UFO:AI function names IIRC.

-geever

Offline mikeg

  • Rookie
  • ***
  • Posts: 24
    • View Profile
Re: New jpeg version (8b)
« Reply #5 on: October 09, 2010, 03:06:33 pm »
libjpeg8 isn't compatible with libjpeg6
you need to change the code to upgrade

Quite interesting, will check that.

Btw. How do you compile libs
Linux ...?

No, I choosed MingW/mSYS to compile on Windows 7.

You can "join | lead" ...
http://ufoai.ninex.info/forum/index.php?topic=4689.15
http://ufoai.ninex.info/forum/index.php?topic=5425.0

I'm not that experienced with UFO:AI to lead anything ;-) But joining is ok. I see you talking about to link anything statically - or try to do it so? I recommend not to do this. If there are any big or small problems (bugs) inside of any 3rd party library, you will have to compile anything again to get rid of a security bug and merge the related patch into your code. The opportunity to link shared (dll or so) has that great advantage that anyone can replace the library code without building anything again.

> german which is my native language
Mine too

Does this mean, that you already do the job on translating the PO? Oder anders gesagt, kann ich mir die Arbeit sparen?

Servus and Regards

Mike

Offline Borsti67

  • Squad Leader
  • ****
  • Posts: 164
    • View Profile
Re: New jpeg version (8b)
« Reply #6 on: October 09, 2010, 05:15:03 pm »
Does this mean, that you already do the job on translating the PO? Oder anders gesagt, kann ich mir die Arbeit sparen?

Many people contribute(d) to translation (me too), but there's still a lot of work.
Oder anders gesagt, nein.  ;D