On Mon, Aug 01, 2011 at 03:59:37PM +0200, Hans de Goede wrote: > Hi, > > On 08/01/2011 03:22 PM, Alon Levy wrote: > >On Mon, Aug 01, 2011 at 03:14:12PM +0200, Hans de Goede wrote: > >>Hi, > >> > >>On 08/01/2011 10:51 AM, Christophe Fergeau wrote: > >>>On Sat, Jul 30, 2011 at 08:26:04AM +0200, Hans de Goede wrote: > >> > >><snip snip> > >> > >>>>The second is to define a new jpeg-rgb format where we use jpeg > >>>>compression straight on rgb, rather then first converting it > >>>>to yuv colorspace (this happens inside libjpeg, but can be > >>>>overridden) this will lead to a slight increase in bandwidth > >>>>usage, but also a great drop in cpu usage. > >>> > >>>Would this still be standard jpeg, or would this mean we invented our own > >>>spice-jpeg? In other words, if we change the server to do this, will the > >>>client be able to handle this using standard libjpeg calls, or will it need > >>>to be modified to be able to handle this jpeg-rgb format? > >> > >>The client will need changes too. The client might need changes for the > >>abbreviated image stuff too, but it might work out of the box too. I'm not > >>sure if currently one libjpeg decompression object gets re-used or a new > >>one gets created each time. If there is a new one each time then the > >>client will need changes for the abbreviated stuff too. > >> > >>>Moreover, are you > >>>sure it will only result in a slight increase in bandwith use at comparable > >>>quality? > >> > >>A good question, thinking more about this, I'm likely wrong wrt the > >>bandwidth > >>usage. The uncompressed data is 6 bytes / 4 pixels in YUV420 mode (YUV color > >>space U and V sampled once every 2x2 pixels) and 12 bytes / 4 pixels in > >>RGB24 mode, so switching our RGB24 data directly to libjpeg rather then > >>first converting it to YUV420 likely will lead to approx double bandwidth > >>usage :( > >> > > > >Isn't the image sent compressed? i.e. size(jpeg_compress(as_rgb(image))) / > >size(jpeg_compress(as_yuv(image))) != (12/4) / (6/4) > > > > Right, but since the raw components fed to the jpeg compression (which always > happens per coefficient) are twice as big, chances are the output will also > be approx twice as big. >
Ok, thanks for the correction. > >I'm not really familiar with jpeg compression, I know it's something with > >truncated > >cosine coefficient series, so the point is that the type of the saved data > >is not > >YUV420 nor RGB24. > > > > Right, but the compression happens per component, you can even add an alpha > channel > if you want, or compress 6 components or whatever ... > > Basically what happens more or less currenly is: > -The image gets divided into 16x16 macro blocks > -The last row / column of macro blocks get padded out to 16x16 > by duplicating the last row / column of the block. > -16x16 R + G + B data -> 16x16 Y data + 8x8 U + V data > -per component the pixels: > -get quantized (non significant bits get thrown away) > -get transformed into the frequency domain > -high frequencies get thrown away > -the left over frequency info gets huffman compressed > -this results in a bitstream, note the next macro block > component will start with the next bit, not necessarily > on a byte boundary. > > According to the JPEG standard one is free to use different subsampling > factors for > components, number of components, etc. > > >Not even sure if the compression will be better or worse - I imagine an all > >red > >image will be much better compressed starting from RGB24. > > No, in both RGB and YUV colorspaces an all red image will have constant > component values from one pixels to the next, so both will compress very well. I was talking about F(x,y)=(R(x,y),0,0), not about F(x,y)=(C, 0, 0) > > Regards, > > Hans > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
