Am 27.04.2010 22:19, schrieb Ive:
>> There are still issues though: While IC displays the JPEG output images
>> as expected, Windows Explorer preview and Photoshop 6.0 get the RGB
>> values wrong way round (i.e. blue displays as red and vice versa). So
>> given that IC normally does a pretty good job at JPEGs, POV-Ray must be
>> doing something pretty unconventional there.
>
> In fact IC swabs the red and blue channels (and therefor shows POV-Ray
> jpeg images correctly) BECAUSE POV-Ray is doing it wrong by storing BGR
> instead of RGB.
> POV-Ray is the one and only application that I am aware off that does
> not perform the RGB to YCbCr color space transformation but uses the DCT
> directly on RGB, err in this case BGR data. This is perfectly legal for
> jpeg (when done in the right order of channels) but does not make much
> sense because it results in either more pronounced block artifacts or
> larger file size.

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.

BTW, as a matter of fact, the wrong channel ordering is a 3.7 issue; 
POV-Ray 3.6 at least did it the right way round.

I consider the use of RGB instead of YCbCr a bug (already filed as 
FS#103 ;-)).

> My suggestions for writing ray-traced jpeg files would be anyway:
> - use YCbCr

Submitted to the codebase as change #4956 already ;-)

> - 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?

> - compression setting of 85%
>
> in my experience (and I did a lot of tests on that matter) this gives
> the best trade-off between quality and file size.

I'm not sure yet what to make of this. Normally I'd say file output 
should default to high quality; then again, for high quality we'd have 
PNG (or plenty other 24-or-more-bit lossless file formats), so it might 
make sense to go for a default JPEG quality that one might possibly put 
directly on the internets. After all, if you decide to output to JPEG, 
you probably don't want to do any more processing on the image. So in 
the end I'd probably agree with you.

> On a different matter: adding the render statistics as a metadata tag to
> PNG would be very nice. And doing the same with OpenEXR even more nice
> as OpenEXR is the format I do use as default file format for all my
> POV-Ray work.

See FS#64.

Post a reply to this message