 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How about changing the default output file type for both Windows and
> Unix version to PNG?
Yes!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26.04.2010 21:08, clipka wrote:
> 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.
My suggestions for writing ray-traced jpeg files would be anyway:
- use YCbCr
- no chroma sub-sampling (to avoid the disappearance of small red or
blue colored details)
- 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.
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.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.04.2010 23:05, schrieb clipka:
>> - 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?
Forget about that. Found it, seen the difference. Though it does
increase file size as well, so maybe a higher-quality setting /with/
chroma sub-sampling might do just as fine?
Then again, I guess you have a /bit/ more experience with image file
formats than I do ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.04.2010 22:19, schrieb Ive:
> My suggestions for writing ray-traced jpeg files would be anyway:
> - use YCbCr
> - no chroma sub-sampling (to avoid the disappearance of small red or
> blue colored details)
> - compression setting of 85%
Hm... how about enabling/disabling chroma sub-sampling depending on
compression setting? I just happened to see that in some code found on
the 'net.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27.04.10 23:05, clipka wrote:
> 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 ;-)).
No, it isn't a bug. This *really* is intentional behavior! With the correct
settings in other places (not sure if they are), you can get rid of a lot of
color bleeding when using sharply ray-traced objects by using RGB.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.04.2010 19:00, schrieb Thorsten Froehlich:
> On 27.04.10 23:05, clipka wrote:
>> 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 ;-)).
>
> No, it isn't a bug. This *really* is intentional behavior! With the
> correct settings in other places (not sure if they are), you can get rid
> of a lot of color bleeding when using sharply ray-traced objects by
> using RGB.
From experiments, I really don't see any advantage of RGB over YCbCr
without chroma sub-sampling.
To the contrary: At the same output file size, YCbCr without chroma
sub-sampling appears to give slightly superior quality.
So given that the same (or even better) quality/size tradeoff as RGB
seems to be obtainable in a fully JFIF-compatible way, that's the way to
go if I'm asked.
Even if for some reason we would want to do non-JFIF-compatible JPEG
output, I strongly advocate doing so only when the user /explicitly/
chooses it via some option. The image file format commonly known as
"JPEG" /is/ actually JFIF, so by default POV-Ray should follow that
convention for the sake of compatibility.
Note that if quality is paramount, JPEG is a bad choice of output file
format anyway, so I don't see much of a point in sacrificing
compatibility for quality with this format.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <ano### [at] anonymous org> schreef in bericht
news:4bd40f13$1@news.povray.org...
> How about changing the default output file type for both Windows and Unix
> version to PNG?
Oh yes, definitely.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28.04.10 20:10, clipka wrote:
> Am 28.04.2010 19:00, schrieb Thorsten Froehlich:
>> On 27.04.10 23:05, clipka wrote:
>>> 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 ;-)).
>>
>> No, it isn't a bug. This *really* is intentional behavior! With the
>> correct settings in other places (not sure if they are), you can get rid
>> of a lot of color bleeding when using sharply ray-traced objects by
>> using RGB.
>
> From experiments, I really don't see any advantage of RGB over YCbCr
> without chroma sub-sampling.
The way to measure is using statistical tests designed for image comparison
... I still have the code somewhere.
> To the contrary: At the same output file size, YCbCr without chroma
> sub-sampling appears to give slightly superior quality.
Indeed, the file size of the RGB image will be larger because quantization
works differently. In essence RGB works like three grayscale images in JPEG.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
