libjpeg-devel-6x — Discussion around maintenance of libjpeg6.x

[Libjpeg-devel-6x] Submitting patches

[Loganaden V. <log...@gm...>]

Hi libjpeg developers,

I've been working on a diff to harden libjpeg memory handling.

I'd like to submit it for review as it as a low performance impact.

What is the best way to achieve this ?

Kind regards,
//Logan
C-x-C-c


-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

Re: [Libjpeg-devel-6x] read image from memory

[Bob F. <bfr...@si...>]

On Mon, 16 Feb 2015, Scott Weber wrote:

> See this posting:
> http://stackoverflow.com/questions/4559648/write-to-memory-buffer-instead-of-file-with-libjpeg
> 
> The functions you should look into are:
> jpeg_mem_dest(...)
> jpeg_mem_src(...)

It is also possible to provide I/O access functions which can be 
directed at memory.  With this approach, data can be streamed (file, 
pipe, memory) and there is potential for not needing to buffer the 
whole image in memory.  That is what ImageMagick and GraphicsMagick 
do.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [Libjpeg-devel-6x] read image from memory

[Scott W. <sco...@sb...>]

See this posting:
http://stackoverflow.com/questions/4559648/write-to-memory-buffer-instead-of-file-with-libjpeg

The functions you should look into are:

jpeg_mem_dest(...)
jpeg_mem_src(...)

I have been using them for years.




________________________________
 From: Radim <we...@se...>
To: lib...@li... 
Sent: Monday, February 16, 2015 5:13 PM
Subject: [Libjpeg-devel-6x] read image from memory
 


I would like to save and read images from database. Is there any 
way how to decompress image without reading it from file stream or compress it without writing to the file stream? I mean I would like to work with it only 
in memory. The images should be in database and I don't see the sense of 
writing the images into separate files on disk because these would be huge 
numbers of files. There is one more reason for it. There is 250 bytes in the 
begin of file which are same for every image so I would like to remove these 
250 bytes and write them to db. So when reading data from db, I would complete the file in memory and then would like to be opened by 
libjpeg.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Libjpeg-devel-6x mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libjpeg-devel-6x

[Libjpeg-devel-6x] read image from memory

[Radim <we...@se...>]

I would like to save and read images from database. Is there any way how to 
decompress image without reading it from file stream or compress it without 
writing to the file stream? I mean I would like to work with it only in 
memory. The images should be in database and I don't see the sense of 
writing the images into separate files on disk because these would be huge 
numbers of files. There is one more reason for it. There is 250 bytes in the
begin of file which are same for every image so I would like to remove these
250 bytes and write them to db. So when reading data from db, I would 
complete the file in memory and then would like to be opened by libjpeg.

[Libjpeg-devel-6x] Modifying/encrypt files

[Haavard H. <haa...@nt...>]

Hello,

I am currently writing an application which uses some jpeg's. I do not 
want others to read the jpeg's directly. Therefore I want to modify the 
format a little bit.

Do you have any suggestions how to to this ? Can I change the header in 
some way so that the file will not be readable from a standard 
image-viewer ? How can I do that using libjeg/which files to modify ?

Best regards

Håvard

Re: [Libjpeg-devel-6x] RGB/YUV 12-bit compression to JPEG

[Bob F. <bfr...@si...>]

On Tue, 29 Apr 2014, Mingyue GAO wrote:
>
> I linked the right 12-bit version of libjpeg I just generated (either 
> libjpeg-6b or libjpeg-9a), included the right header file in source codes, 
> but the result I get here is very strange. I cannot even open the new jpeg 
> file.

You did not describe to us what you mean by "open".  No normal 
application will be able to "open" a 12-bit JPEG file.  The special 
build of libjpeg should be able to open and read it though.  Perhaps 
you can use 'djpeg' from it to convert to a non-JPEG format.  The 
available formats output by 'djpeg' do not seem to support 12-bits 
though.

Given that libjpeg can only be compiled to support 8 or 12 bits, it is 
not easy to create an application which can support both depths at 
once.

In the past I have created special builds of GraphicsMagick to make 
sure that 12-bit JPEG can work with it, but there was no provision for 
8/12 bits at the same time, so the result is not very convenient.

This is a shame since 12-bit JPEG is valuable.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[Libjpeg-devel-6x] RGB/YUV 12-bit compression to JPEG

[Mingyue G. <min...@vi...>]

Hello everyone,

I'm doing an urgent job, mainly concerned on:

- compress RGB888/YUV420 to 12-bit JPEG

My input is RGB888, 8 bits for each channel, and I add four zeros at the 
end, which means if red channel is 0xFF, then new one is 0xFF0.
I'm sure my input (RGB888 8 bit for each channel) is right,  and I 
followed install.txt to compile a 12-bit libjpeg by steps below:

- in jmoreconfig.h, change BITS_IN_JSAMPLE to 12
- in jconfig.h, undefine support for BMP, GIF and TARGA
- no make test (since testcases not support 12-bit libjpeg)

I linked the right 12-bit version of libjpeg I just generated (either 
libjpeg-6b or libjpeg-9a), included the right header file in source 
codes, but the result I get here is very strange. I cannot even open the 
new jpeg file.
By the way, the code I'm using is from the officially example.c, barely 
modified.

I extend the raw RGB to short data in order to support the 12 bit.

I know my input may be wrong, but at least I should be able to load the 
jpeg in the viewer even it shows a crap picture.

I figured the problem is jpeg header the libjpeg created, because there 
should be SOI in the jpeg file (starting with 0xff c0), but there isn't.

Please find the crap jpeg in the attachment.

Really hope someone could help me out here! I've been struggled for a 
week! Thank you no matter if you can help.

Sincerely,
Myue

[Libjpeg-devel-6x] Using jpeg_mem_dest

[Scott W. <sco...@sb...>]

How do I use this function?  I would rather take advantage of jpeg_mem_dest, then directing through the file system with the 'stdio' versions.

unsigned long size;        /*  Not set?  */

unsigned char *dest;        

jpeg_mem_dest(&cinfo,&dest,&size);          /*  dest points to memory that who is responsible for freeing? */

Specifically, who owns the memory, and does it go out of scope on "destroy" or "finish"?

Do I need to copy the buffer to my own memory before calling the 
destroy_compress function?  Or is the memory persistent, and I need to 
free it on my own?

Does the size argument have to be initialized to anything?

And is the size pointer "remembered" so that it contains the correct value at 

"finish_compress"?  No other call is needed to get the final size?


The header file has is value in answering this question.
(In a windows DLL, if the DLL owns memory, my program would not be able to free it... This isn't a windows project yet, but may be ported over)

And more generally, is there a good reference doc for these functions available?  As an example, the LibTiff doc gives in depth descriptions of the functions.  I'd really find something equivalent very useful for LibJpeg.

Thanks.


-Scott Weber

Re: [Libjpeg-devel-6x] [patch] wrjpgcom possible buffer overflow in strcpy and strcat

[<sj...@sl...>]

Sounds good to me. :)

Quoting Tom Lane <tg...@ss...>:

> sj...@sl... writes:
>> Please review the following patch for wrjpgcom:
>
> FWIW, the solution that Red Hat had been using for some time was just to
> dike out the "MS-DOG" code here altogether, as it's not only not needed
> on systems with sane command parsing, but really wrong even without the
> buffer overrun issue: who says a comment can't start with a double quote?
> See
>
> http://pkgs.fedoraproject.org/cgit/libjpeg.git/tree/libjpeg-buf-oflo.patch
>
> I don't remember the exact genesis of that code fragment anymore, but it
> was obviously an under-thought-out reaction to somebody's complaint.  At
> this point I'd just remove it.
>
> 			regards, tom lane
>

Re: [Libjpeg-devel-6x] [patch] wrjpgcom possible buffer overflow in strcpy and strcat

[Tom L. <tg...@ss...>]

sj...@sl... writes:
> Please review the following patch for wrjpgcom:

FWIW, the solution that Red Hat had been using for some time was just to
dike out the "MS-DOG" code here altogether, as it's not only not needed
on systems with sane command parsing, but really wrong even without the
buffer overrun issue: who says a comment can't start with a double quote?
See

http://pkgs.fedoraproject.org/cgit/libjpeg.git/tree/libjpeg-buf-oflo.patch

I don't remember the exact genesis of that code fragment anymore, but it
was obviously an under-thought-out reaction to somebody's complaint.  At
this point I'd just remove it.

			regards, tom lane

[Libjpeg-devel-6x] [patch] wrjpgcom possible buffer overflow in strcpy and strcat

[<sj...@sl...>]

Hi there,

Please review the following patch for wrjpgcom:
sj@slinafirinne ~/jpeg-6b $ more wrjpgcom.patch
456c456
<       strcpy(comment_arg, argv[argn]+1);
---
>       snprintf(comment_arg, sizeof comment_arg, "%s", argv[argn]+1);
466c466
<         strcat(comment_arg, argv[argn]);
---
>           snprintf(comment_arg, sizeof comment_arg, "%s", argv[argn]);

This patch replaces possible vulnerable function calls strcpy and  
strcat which do not perform bounds checking.

Regards,
Peter.

Re: [Libjpeg-devel-6x] Question about IDCT in decoding

[Guido V. <gu...@jp...>]

Dear Zhang Peixuan

1. These are the general NxN-point DCT functions.
They are used in jcdctmgr.c and jddctmgr.c,
and are used by the cjpeg/djpeg -scale and cjpeg -block
switches, and also for the "fancy" color subsampling mode.
See the accompanying documentation for more info.

2. jpeg6b uses an irreversible algorithm for the "fancy" color
subsampling mode.  That's why the result is different compared
to newer versions, which use a reversible algorithm.
The 8x8 DCT function itself, although optimized in newer IJG
versions, delivers the same results.
You can get the same results in all versions by using the
"-nosmooth" switch in djpeg invocation, or using/creating
image files with disabled color subsampling (option "-sample 1x1"
in cjpeg invocation; otherwise, the default is 2x2).

jpeg9a, which is expected to be released in January 2014
(see http://www.infai.org/jpeg/), introduces another mismatch:
This is due to the YCbCr <=> RGB conversion, which will use a
more accurate code than prior versions.

VS2010 seems to have some subtle optimization bugs in the compiler.
We had to disable optimization for the file jquant2.c in the library
project file for the self-test to pass properly (see install.txt).

Kind regards
Guido Vollbeding
Organizer Independent JPEG Group

[Libjpeg-devel-6x] Question about IDCT in decoding

[Zhang P. <zha...@gm...>]

Hi All,

When I was implementing the OpenCL version of JPEG decoding, there are some
question I want to know:
1. Now we completed the OpenCL version of IDCT-is-slow, IDCT-fast(use
short) and IDCT-float. However, I found the following function in
jdictint.c and jindred.c:
    jpeg_idct_1x1
    jpeg_idct_2x2
    jpeg_idct_3x3
    jpeg_idct_4x4
    jpeg_idct_5x5
    jpeg_idct_6x6
    jpeg_idct_7x7
    jpeg_idct_9x9
    jpeg_idct_10x10
    jpeg_idct_11x11
    jpeg_idct_12x12
    jpeg_idct_13x13
    jpeg_idct_14x14
    jpeg_idct_15x15
    jpeg_idct_16x16
I don't know when these function will be used, and I also try to debug
these function, but it isn't been used when my debug.
I didn't implement OpebCL version for them.
Could you give me more info?
2. When I use:
    djpeg -bmp -dct float -outfile out.bmp in.jpg
to decode a image, I found that the results are differnet between jpeg6b
and jpeg8d/jpeg9. The SIMD version is also different from C code. And now
the OCL version is bit-match with 8d/9.
However, if we complile with VS2010, it won't be bit-match, if we use GCC
or VS2012, it's bit-match.
    Is it a bugs?

[Libjpeg-devel-6x] progressive jpeg without optimization

[Péter K. <pet...@gm...>]

Hi guys,

I would like to create many same sized progressive jpeg files with the same
huffman tables. Because I'd like to store the huffman table part of the
files separately and when I have to show the progressive jpeg just
concatenate the huffman table and the image part together.

I read in the doc that:

We should also note that the compressor currently forces Huffman
optimization
mode when creating a progressive JPEG file, because the default Huffman
tables are unsuitable for progressive files.

I've found this in the code:
      if (cinfo->progressive_mode) /*  TEMPORARY HACK ??? */
        cinfo->optimize_coding = TRUE; /* assume default tables no good for
progressive mode */

But unfortunately if I remove this from the jpeg lib I won't get the same
huffman tables

Could you help me to create this kind of progressive jpeg?

Br,
Peter

Re: [Libjpeg-devel-6x] libjpeg decoder structure mismatch

[swaps jp <sw...@gm...>]

Hello Tom,
Thank you for your reply.
Yes, parameters set in one module are needed to accessed by other modules.
Since most of the API's of libjpeg have  jpeg_compress_struct as an
argument, new members are required to be added in this structure.

Regards,
Swapnil



On Tue, Jun 25, 2013 at 6:37 PM, Tom Lane <tg...@ss...> wrote:

> swaps jp <sw...@gm...> writes:
> > When I am trying to add vendor specific members to the structure
> > "jpeg_compress_struct" and try to run with standard applications or with
> > gstreamer an error is occurs indicating structure size mismatch for the
> > above mentioned structure.
>
> Do you really need your own fields inside jpeg_compress_struct itself?
> The design intention was that most churn of that sort would happen
> within the various module-specific sub-structures and thus not affect
> the ABI for clients.
>
>                         regards, tom lane
>

[Libjpeg-devel-6x] Check for SOI Symbol function

[Klin I. <ga...@ya...>]

Hello,

i'm new to libjpeg, and want to know how the error  JMESSAGE(JERR_NO_SOI, "Not a JPEG file: starts with 0x%02x 0x%02x") is generated. 
I found the JFIF marker. So, isn't there a SOI marker too?

Thank You
Axel

Re: [Libjpeg-devel-6x] libjpeg decoder structure mismatch

[Tom L. <tg...@ss...>]

swaps jp <sw...@gm...> writes:
> When I am trying to add vendor specific members to the structure
> "jpeg_compress_struct" and try to run with standard applications or with
> gstreamer an error is occurs indicating structure size mismatch for the
> above mentioned structure.

Do you really need your own fields inside jpeg_compress_struct itself?
The design intention was that most churn of that sort would happen
within the various module-specific sub-structures and thus not affect
the ABI for clients.

			regards, tom lane

[Libjpeg-devel-6x] libjpeg decoder structure mismatch

[swaps jp <sw...@gm...>]

Hello,
When I am trying to add vendor specific members to the structure
"jpeg_compress_struct" and try to run with standard applications or with
gstreamer an error is occurs indicating structure size mismatch for the
above mentioned structure.
Application sends structure size as 488 bytes whereas inside library
structure size after adding vendor specific code becomes more than 488
resulting in structure size mismatch error.
In order to overcome this problem I see possibility of following solution.
-- Compile the client to libjpeg with the header files modified for vendor
specific code.

But this does not sound to be a better solution as every application which
is using libjpeg will need to be compiled with modified header files.

There is a void pointer "client_data" inside the mentioned structure. But
this might not be useful as name suggests that it might be in use by
applications.
We need to have additional void pointer inside the "jpeg_compress_struct"
structure  to accommodate additional vendor specific members.

What could be the right solution to overcome this kind of problem?

Thanks.

Re: [Libjpeg-devel-6x] YUYV422 to JPEG without additional conversation to RGB using LIBJPEG library?

[陳立格 <b89...@nt...>]

郵件討論區留一個備份

於 2013/5/11 下午 10:58, 陳立格 提到:
> 你好:
>
>   是的 真的可以這樣搞.
>
>   不過需要一些修改.
>
> 增加以下代碼
>
>
> turbojpeg.h :
>
> /**
>  *
>  *
>  * Compress an YUV image into a JPEG image.
>  * the input data is assumed as aligned as 4.
>  *  NOTE : the function will not allocate output buffer(pJpegBuf).
>  */
>
> DLLEXPORT int DLLCALL tjCompressYUV420(tjhandle handle, unsigned char 
> *pY,
>     unsigned char *pU, unsigned char *pV, int width, int height, 
> unsigned char *pJpegBuf,
>     unsigned long *pJpegSize, int jpegQual);
>
>
>
> turbojpeg.c:
>
> #define MAX_LINES            (2*DCTSIZE)
> #define DIV2(VAL)            ((VAL)>>1)
>
> DLLEXPORT int DLLCALL tjCompressYUV420(tjhandle handle, unsigned char 
> *pY,
>     unsigned char *pU, unsigned char *pV, int width, int height, 
> unsigned char *pJpegBuf,
>     unsigned long *pJpegSize, int jpegQual)
> {
>     int retval;
>
>     getinstance(handle)
>     if((this->init&COMPRESS)==0)
>         _throw("tjCompress2(): Instance has not been initialized for 
> compression");
>
>     retval = 0;
>     if(setjmp(this->jerr.setjmp_buffer))
>     {
>         /* If we get here, the JPEG code has signaled an error. */
>         retval=-1;
>         goto bailout;
>     }/*if setjmp(this->jerr.setjmp_buffer)*/
>
>
>     cinfo->image_width = width;
>     cinfo->image_height = height;
>     cinfo->input_components = 3;
>     cinfo->jpeg_color_space = JCS_YCbCr;
>     cinfo->data_precision   = 8;
>
>     jpeg_set_defaults(cinfo);
>
>     cinfo->in_color_space = JCS_YCbCr;
>     cinfo->raw_data_in = TRUE;
>
>     jpeg_set_quality (cinfo, jpegQual, TRUE);
>
>     cinfo->comp_info[0].h_samp_factor = 2;
>     cinfo->comp_info[0].v_samp_factor = 2;
>     cinfo->comp_info[1].h_samp_factor = 1;
>     cinfo->comp_info[1].v_samp_factor = 1;
>     cinfo->comp_info[2].h_samp_factor = 1;
>     cinfo->comp_info[2].v_samp_factor = 1;
>
>     *pJpegSize = tjBufSize(width, height, TJSAMP_420);
>
>     jpeg_mem_dest_tj(cinfo, &pJpegBuf, pJpegSize, 0);
>
>     jpeg_start_compress(cinfo, TRUE);
>
>
>     {/*variables block */
>
>         unsigned int i, j;
>         unsigned int widthStepY;
>
>         unsigned int endHeight;
>
>         JSAMPROW  YArrow[MAX_LINES], UArrow[DCTSIZE], VArrow[DCTSIZE];
>         JSAMPARRAY encodeYUV[3];
>         unsigned char *pMovY, *pMovU, *pMovV;
>
>         widthStepY = TJPAD(width);
>         endHeight = (height + (MAX_LINES - 1)/ MAX_LINES)*(MAX_LINES);
>
>         pMovY = pY; pMovU = pU; pMovV = pV;
>
>         for(j = 0; j< endHeight; j+= MAX_LINES){
>
>             for(i = 0;i < MAX_LINES; i++)
>                 YArrow[i]  = pMovY + i*widthStepY;
>
>             for(i = 0;i < DCTSIZE; i++){
>                 UArrow[i] = pMovU + i*DIV2(widthStepY);
>                 VArrow[i] = pMovV + i*DIV2(widthStepY);
>             }/*for i*/
>
>             encodeYUV[0] = YArrow;
>             encodeYUV[1] = UArrow;
>             encodeYUV[2] = VArrow;
>
>             jpeg_write_raw_data(cinfo, encodeYUV, MAX_LINES);
>
>             pMovY += MAX_LINES*widthStepY;
>             pMovU += DCTSIZE*DIV2(widthStepY);
>             pMovV += DCTSIZE*DIV2(widthStepY);
>         }/*for j*/
>
>     }/*variables block */
>
>
>     jpeg_finish_compress(cinfo);
>     bailout:
>
>     return retval;
> }/*tjCompressYUV420*/
>
>
> 這樣就可以了
>
>
>
> English:
>
> You should add turbojpeg.h and turbojpeg.c as above, that is what you 
> wish. but the proformance is not good as inputing RGB directly, the 
> RGB one is better.  you should benchmark it.
>
>
>
> 於 2013/5/7 下午 11:53, netmonitoring 提到:
>> Is it possible to save YUYV422 buffer as JPEG using LIBJPEG library 
>> without additional conversation to the RGB24/RGB32 color format?
>>
>> Are there examples?
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and
>> their applications. This 200-page book is written by three acclaimed
>> leaders in the field. The early access version is available now.
>> Download your free book today!http://p.sf.net/sfu/neotech_d2d_may
>>
>>
>> _______________________________________________
>> Libjpeg-devel-6x mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libjpeg-devel-6x
>

[Libjpeg-devel-6x] YUYV422 to JPEG without additional conversation to RGB using LIBJPEG library?

[netmonitoring <net...@ma...>]

 Is it possible to save YUYV422 buffer as JPEG using LIBJPEG library without additional conversation to the RGB24/RGB32 color format?

Are there examples?

[Libjpeg-devel-6x] YUYV422 to JPEG without additional conversation to RGB using LIBJPEG library?

[Vadim G. <vgo...@gm...>]

Is it possible to save YUYV422 buffer using LIBJPEG without additional
conversation to the RGB24/RGB32 color format? Are there examples?

--
Vadim Golopupov

[Libjpeg-devel-6x] May I ask about the roadmap of libjpeg-turbo ?

[<b89...@nt...>]

Dear All:

the libjpeg-turbo is very sharp implement of jpeg code,
well done in using SIMD instruction by Linaro.

But, by my benchmark, that seems not implemented encode from raw
data (that is, using function jpeg_write_raw_data) in SIMD on neon:

tjCompressYUV420 is my packaging funcion, using jpeg_write_raw_data to
encode yuv420 data as jpeg.

ROUND = 100
tjCompressYUV420 cost time = 1613 ms
tjCompress2 cost time = 833 ms

my test platform is tiny210 @ 1GHz
(http://www.friendlyarm.net/products/tiny210)

May I ask, do anyone know if Linaro have any plan to implement those  
subrountine as SIMD in recent time?

Maybe is it coming soon ? If the answer is negation, may I ask is that
more tedious to implelement than jpeg_write_scanlines so there is no
this plan in recent time?



thank your attention.

     Liger Chen

[Libjpeg-devel-6x] I want to contribute code for LibJPEG

[Zhang P. <zha...@gm...>]

Hello,
     I'm a programmer, and I has been involved in the GIMP project for a
long time.
     Now, my team and I are likely to get funding from a large company to
do some JPEG
codec optimization work, and I want to contribute code for LibJPEG when the
project
finished.
     I don't know whether the IJG will accept source code other than C,
such as assembly
code, or OpenCL parallel code.
     I want to contact the IJG team, but I didn't find any contact
infomation, if you could
contract for further communication, I would be very grateful!


                                                           Peixuan Zhang

Re: [Libjpeg-devel-6x] request to join libjpeg

[Bob F. <bfr...@si...>]

On Sat, 5 May 2012, Johnathan wrote:

> I would like to join the libjpeg discussion list to recommend adding a color conversion which is missing
> from the current implementation.

This is the discussion list for libjpeg 6x which is stable and no 
longer really developed.

> We are seeing increasing use of 32 bit RGBA images on the internet, and JPEG is the *only* popular file
> format which does not support RGBA, even though the specification easily allows this.
> 
> Why is this? There is really no reason why JPEG should not support RGBA, because it already has a compatible
> format, namely YCCK.

JPEG does not work well for alpha channels because it is lossy.  This 
produces poor visual results for normal usages.

There is a JPEG-based format known as JNG which uses JPEG for the RGB 
parts and lossless PNG type coding for the alpha part.  The file 
format is structured like PNG.

> With this simple addition, JPEG will finally support full 32 bit RGBA images, making it more useful in
> applications requiring transparency such as web browsers, games, mobile apps, and so on.

Consider using and promoting JNG.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[Libjpeg-devel-6x] request to join libjpeg

[Johnathan <rol...@gm...>]

I would like to join the libjpeg discussion list to recommend adding a
color conversion which is missing from the current implementation.

We are seeing increasing use of 32 bit RGBA images on the internet, and
JPEG is the *only* popular file format which does not support RGBA, even
though the specification easily allows this.

Why is this? There is really no reason why JPEG should not support RGBA,
because it already has a compatible format, namely YCCK.

In the current libjpeg implementation, when a 4 channel RGBA image is
supplied to the encoder, it throws away the 4th channel (A) and only saves
the RGB channels as YCC, which loses data. Instead, it should save as YCCK,
where K is the data from the 4th channel. In addition, the color profile
would be saved as RGB so the decoder does not mistake this file as CMYK
(which is the only current use for YCCK).

A simple RGBA to YCCK color space conversion is all that's needed. This is
identical to RGB to YCC, except it also copies the A channel to K.

In the decoder, when a YCCK image is loaded with a RGB profile, if a 4
channel destination buffer is supplied, the K channel would be preserved by
copying it to the destination.

With this simple addition, JPEG will finally support full 32 bit RGBA
images, making it more useful in applications requiring transparency such
as web browsers, games, mobile apps, and so on.

Thanks,
Johnathan