On 27.04.2010 23:05, clipka wrote:
> I found out by now about the RGB instead of YCbCr; but isn't RGB invalid
> anyway for JFIF (the JPEG-compressed image file format commonly
> associated with the .jpg extension)? And the files written by POV-Ray
> also don't have a proper JFIF tag at all.
>
As you say, for a simple jpeg code-stream almost everything is allowed 
and valid, even multi-color-separations with up to 12 channels and 
things like this are even supported by jpeglib 6b. Surely such files are 
not very portable but this is why the JFIF and EXIF extensions have been 
invented for.


>> - no chroma sub-sampling (to avoid the disappearance of small red or
>> blue colored details)
>
> I'm not sure what exactly you mean; do you happen to have a sample
> scene? And can you give me pointers off the top of your head how to set
> this up with jpeglib?
>

Out of my head - done these things much too often ;)

   struct  jpeg_compress_struct cinfo;

   // do a few things... 	

   jpeg_set_defaults(&cinfo);

   // do more things like setting the compression rate...

   if (NO_SUBSAMPLE)
   {
     cinfo.comp_info[0].h_samp_factor = 1;
     cinfo.comp_info[0].v_samp_factor = 1;
   }


someone mentioned the problem already within this thread (and the Golden 
Gate Bridge IIRC) and it has been mentioned multiple times within p.b.i. 
Increasing the compression rate to even 100 does not help at all in this 
cases.
In the early days of jpeg it was quite common to store the 2 chroma 
samples only per each 4x4 pixel block and I think the default setting of 
jpeglib 6b is per each 2x2 pixel block.
Every contemporary and not totally brain dead application should have no 
problems in reading jpeg when subsampling is turned off as shown above.
Note that I'm talking especially about computer generated and/or 
raytraced images and not those made by a digital camera or digitized by 
a flatbed scanner where chroma sub-sampling works as a kind of 
color-noise-reduction filter and this is (beside of making smaller 
files) a nice side effect.


> See FS#64.

I see. But I for one would advocate for adding the whole render 
statistic as a comment tag to PNG and do the same for jpeg, OpenEXR and 
even P(N)M files (where just a simple ascii text before the image 
dimension would do the job).

-Ive

Post a reply to this message