How about changing the default output file type for both Windows and 
Unix version to PNG?

Post a reply to this message

On 25/04/2010 19:44, clipka wrote:
> How about changing the default output file type for both Windows and 
> Unix version to PNG?

I'd be for that.

-- Chris

Post a reply to this message

Le 25/04/2010 12:11, Chris Cason nous fit lire :
> On 25/04/2010 19:44, clipka wrote:
>> How about changing the default output file type for both Windows and 
>> Unix version to PNG?
> 
> I'd be for that.

ok,... irc mode: me too!
Does mac have a different 'prefered' file format ?

Post a reply to this message

clipka wrote:

> How about changing the default output file type for both Windows and 
> Unix version to PNG?

yes please

Post a reply to this message

Le 2010-04-25 05:44, clipka a écrit :
> How about changing the default output file type for both Windows and
> Unix version to PNG?

I totaly agree. In fact, it could be the default for all versions.



Alain

Post a reply to this message

Hmm, I vote no. Sorry to be the one nay-sayer here. Given the past problems of
different applications not reading the embedded gamma of .png images correctly,
is this a good idea?  Or am I missing something that I should know about?

Is this idea based purely on image quality (.png vs. .jpeg, for example)?

Ken

Post a reply to this message

Am 25.04.2010 22:08, schrieb Kenneth:
> Hmm, I vote no. Sorry to be the one nay-sayer here. Given the past problems of
> different applications not reading the embedded gamma of .png images correctly,
> is this a good idea?  Or am I missing something that I should know about?
>
> Is this idea based purely on image quality (.png vs. .jpeg, for example)?

The idea is basically to adapt the output file defaults to the changes 
of time. Question is of course, what criteria should the default format 
fulfil?

I think the paramount critera should be that (a) the files can be easily 
exchanged between applications as well as via the internet, and (b) the 
file format does not use lossy compression.

In my opinion that pretty much leaves us with PNG as the only choice.


As for gamma, note that gamma issues also exist with any other image 
format (except for Radiance HDR and OpenEXR, but those are not 
widespread enough to qualify as a default output format); the only 
difference is that the PNG file format /promises/ proper gamma handling 
but /some/ software fails to comply, while most other file formats don't 
even give the promise in the first place.

For a user adhering to best practices, /at worst/ PNG will still be just 
as good as any other formats.

Of course there may be reasons for a user to deviate from best 
practices; in that case, they can choose their own default output file 
format by placing "Output_File_Format=Whatever" in their standard 
povray.ini.

Post a reply to this message

Le 2010-04-25 05:44, clipka a écrit :
> How about changing the default output file type for both Windows and
> Unix version to PNG?

Why not for all versions?


Alain

Post a reply to this message

Am 25.04.2010 23:20, schrieb Alain:
> Le 2010-04-25 05:44, clipka a écrit :
>> How about changing the default output file type for both Windows and
>> Unix version to PNG?
>
> Why not for all versions?

With me having not much of an idea about Macs anyway, I pass that 
question on to any Mac experts listening right now...

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> I think the paramount critera should be that (a) the files can be easily
> exchanged between applications as well as via the internet, and (b) the
> file format does not use lossy compression.

Yes, I do see the need for that. But as a practical matter, I wonder if there is
a discernable visual difference between a .png file and one saved as a
highest-quality .jpeg? (I suppose that's open to debate.) The real point being
that .jpeg *is* a universal standard (lossy, of course); but more importantly,
it has no embedded gamma (AFAIK!!)--which means that how it shows up in
application X is basically the same as in app Y or app Z--regardless of how
those apps deal with embedded gamma in an image. I guess mt main worry is this:
Not all of us have the *latest and greatest* versions of
image-manipulation/viewing software, to view 'correct' .png images in. (My own
version of Photoshop is quite outdated, for example, and AFAIK doesn't read
embedded gamma correctly. And I'm even wondering about the latest version of
Firefox!) I suppose that most/all up-to-date versions of software have addressed
this issue--but that's just a guess. In the final analysis: Can we expect a .png
image to show up correctly even in all 'modern' software? A .jpeg image
eliminates that question (given it's image-quality shortcomings.)

> As for gamma, note that gamma issues also exist with any other image
> format..

True--but that's across-the-board, as you say. I.e., with an image format
lacking an embedded gamma, it's a monitor/system-set-up problem, not an
image-specific one.
>
> For a user adhering to best practices, /at worst/ PNG will still be just
> as good as any other formats.
>

Given *best practices* of course. :-P  If such a .png 'default' is made a part
of POV-Ray, I can only hope that the documentation will make it clear as to what
those best practices are. In the past, this situation has been a can of worms.

Ken

Post a reply to this message

Am 26.04.2010 00:14, schrieb Kenneth:

> Yes, I do see the need for that. But as a practical matter, I wonder if there is
> a discernable visual difference between a .png file and one saved as a
> highest-quality .jpeg? (I suppose that's open to debate.) The real point being
> that .jpeg *is* a universal standard (lossy, of course); but more importantly,
> it has no embedded gamma (AFAIK!!)--which means that how it shows up in
> application X is basically the same as in app Y or app Z--regardless of how
> those apps deal with embedded gamma in an image.

What you forget about is that...

(1) JPEG having no gamma chunk means that it will indeed probably show 
identical in all apps on /your/ computer, but that doesn't mean it will 
look like that on /other/ computers.

(2) If your computer has a display gamma of 2.2, then specifying 
File_Gamma=2.2 will give you /exactly/ that same feature for PNG files: 
Applications that do recognize the gAMA chunks will display it ok 
because they know the gamma, and other applications will display it ok 
because the gamma happens to match your computer's display gamma. Plus, 
/good/ software on /other/ computers will display the image ok even if 
that computer has a nonstandard gamma.

(3) If /your/ computer has a nonstandard display gamma - say, 1.8 - then 
using PNG will give you /some/ chance that it will look the same on both 
your computer and other computers (depending on the quality of the 
software used), while with any other file format (except HDR formats) 
you are /guaranteed/ that it will look /different/.

 > I guess mt main worry is this:
> Not all of us have the *latest and greatest* versions of
> image-manipulation/viewing software, to view 'correct' .png images in. (My own
> version of Photoshop is quite outdated, for example, and AFAIK doesn't read
> embedded gamma correctly. And I'm even wondering about the latest version of
> Firefox!) I suppose that most/all up-to-date versions of software have addressed
> this issue--but that's just a guess. In the final analysis: Can we expect a .png
> image to show up correctly even in all 'modern' software? A .jpeg image
> eliminates that question (given it's image-quality shortcomings.)

Yes - if you have your display system set up to exhibit a total gamma of 
2.2 (or your system is uncalibrated, in which case you're likely to have 
a gamma /somewhere/ around 2.2), and use File_Gamma=2.2, then the 
chances that a PNG will look the same everywhere is /at least/ as big as 
that of a JPEG looking the same everywhere.

> Given *best practices* of course. :-P  If such a .png 'default' is made a part
> of POV-Ray, I can only hope that the documentation will make it clear as to what
> those best practices are. In the past, this situation has been a can of worms.

It was a can of worms indeed - because POV-Ray didn't do input image 
files properly until a few betas ago, making it literally impossible to 
set it up properly. Current default settings should get you a long way 
without you even noticing it (at least for new scenes; legacy scenes are 
a different issue, being necessarily as "broken" as the old versions of 
POV-Ray they were created for).

Post a reply to this message

> Hmm, I vote no. Sorry to be the one nay-sayer here. Given the past 
> problems of
> different applications not reading the embedded gamma of .png images 
> correctly,
> is this a good idea?  Or am I missing something that I should know about?
>
> Is this idea based purely on image quality (.png vs. .jpeg, for example)?

I don't think the default file type should be one that uses lossy 
compression. However, I agree that the gamma confusion makes PNG less than 
ideal. I'm not sure there's a better format though.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

"Slime" <fak### [at] emailaddress> wrote:
> > Hmm, I vote no. Sorry to be the one nay-sayer here. Given the past
> > problems of
> > different applications not reading the embedded gamma of .png images
> > correctly,
> > is this a good idea?  Or am I missing something that I should know about?
> >
> > Is this idea based purely on image quality (.png vs. .jpeg, for example)?
>
> I don't think the default file type should be one that uses lossy
> compression. However, I agree that the gamma confusion makes PNG less than
> ideal. I'm not sure there's a better format though.

Not unless we want to get into the "business" of promoting one HDR format over
another, which...  well, let's just say that standards wars probably aren't the
best usage of anyone's time here, with the possible exclusion of Warp. :-D

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> What you forget about is that...
>
> (1) JPEG having no gamma chunk means that it will indeed probably show
> identical in all apps on /your/ computer, but that doesn't mean it will
> look like that on /other/ computers.

Good point. (Actually, I thought that a .png image would *showcase* these kinds
of discrepancies in an even worse way; but apparently not, which is good to
know.)

Ken

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 25.04.2010 23:20, schrieb Alain:
> > Le 2010-04-25 05:44, clipka a écrit :
> >> How about changing the default output file type for both Windows and
> >> Unix version to PNG?
> >
> > Why not for all versions?
>
> With me having not much of an idea about Macs anyway, I pass that
> question on to any Mac experts listening right now...

Probably not an expert, but everything I've used on the Mac can read/write all
the POV-Ray output filetypes (apart from HDR). I'd say your arguments hold for
the Mac platform as well as Win/Unix.

(oh, and I vote PNG too; not sure about Win7 but XP certainly had no clue what
to do with TGAs, and I object to BMP on moral and aesthetic grounds ;) JPEG is
out of the question for your stated reasons. 2 of my English pence :))

Bill

Post a reply to this message

Am 26.04.2010 10:20, schrieb Bill Pragnell:

> (oh, and I vote PNG too; not sure about Win7 but XP certainly had no clue what
> to do with TGAs, and I object to BMP on moral and aesthetic grounds ;) JPEG is
> out of the question for your stated reasons. 2 of my English pence :))

I think BMP (which is the current default for POV-Ray for Windows) has 
also become a poor choice for technical reasons, as POV-Ray's 
implementation can only write uncompressed BMPs, making it a major waste 
of space without any gain. (It would of course be possible to implement 
compressed BMP output, but then again, why bother when there are better 
alternatives around nowadays.)

Post a reply to this message

> Yes, I do see the need for that. But as a practical matter, I wonder if 
> there is
> a discernable visual difference between a .png file and one saved as a
> highest-quality .jpeg? (I suppose that's open to debate.)

FWIW I had a model of the golden gate bridge and the red vertical cables 
never worked with JPEG.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> (It would of course be possible to implement
> compressed BMP output, but then again, why bother when there are better
> alternatives around nowadays.)

Um...because it would be free of embedded gamma? ;-) (Sorry, I can't seem to let
this poor old horse die a peaceful death.)  Actually, I didn't know that a
compressed BMP image was even possible.

In re-reading the posts here, I get the impression that one of the reasons for
choosing .png as a default is that it's a smaller file size (compared to BMP,
for example.) In the old days--when hard-drive memory was at more of a
premium--that would have been a legitimate argument. But it's an issue that has
far less importance now. (ALTHOUGH, for uploading onto the 'net, a compressed
image is preferable; no argument there. And .png might well be the right choice,
for the reasons given.)

I guess a basic question (or some further food for thought) would be this:
Should the choice of POV's default file type be 'driven' by the needs of the
'net? I would estimate that the ratio of my own POV images (between JPEG/PNG and
BMP) is less than 1%. In other words, I only compress an image when I have to.
No compelling reason to do otherwise.

Although I work on a Windows platform, I actually hadn't considered BMP as an
alternative to the PNG 'default' idea. (It's the POV default anyway, on that
platform.) But it does have one compelling virtue: The majority of computer
users work on Windows--and it's an easy step to convert BMP to JPEG (or PNG!) in
any image app--assuming that everyone who works with POV-Ray *has* another image
app to do that with. (Who doesn't??) Yet, I don't know how/if Macs work with BMP
images; I assume they can handle it.

But in the final analysis, I guess there's nothing wrong with PNG as the
default, if it's implemented and documented well.

Ken

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:
> I don't think the default file type should be one that uses lossy 
> compression.

  I didn't know that POV-Ray even supported lossy formats as output...

-- 
                                                          - Warp

Post a reply to this message

On 04/25/2010 06:44 AM, clipka wrote:
> How about changing the default output file type for both Windows and
> Unix version to PNG?

I'm in favor of this as that's the most common format I use ... but that
doesn't make it correct. Everyone has made compelling pro and con
arguments, but I think it's rather like asking a painter what medium
they like to work with ... acrylics or oil. Personal choice right? If
something other than png is ultimately the choice ... no worries for me
as the format I like to use is just a command line option away!

Jim

Post a reply to this message

Am 26.04.2010 15:01, schrieb Warp:
> Slime<fak### [at] emailaddress>  wrote:
>> I don't think the default file type should be one that uses lossy
>> compression.
>
>    I didn't know that POV-Ray even supported lossy formats as output...

Contrary to rumors, POV-Ray can output JPEG.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 26.04.2010 15:01, schrieb Warp:
> > Slime<fak### [at] emailaddress>  wrote:
> >> I don't think the default file type should be one that uses lossy
> >> compression.
> >
> >    I didn't know that POV-Ray even supported lossy formats as output...

> Contrary to rumors, POV-Ray can output JPEG.

  Is that new in POV-Ray 3.7? How do you fine-tune the compression options?

-- 
                                                          - Warp

Post a reply to this message

On 04/26/2010 02:34 PM, Warp wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 26.04.2010 15:01, schrieb Warp:
>>> Slime<fak### [at] emailaddress>  wrote:
>>>> I don't think the default file type should be one that uses lossy
>>>> compression.
>>>
>>>    I didn't know that POV-Ray even supported lossy formats as output...
> 
>> Contrary to rumors, POV-Ray can output JPEG.
> 
>   Is that new in POV-Ray 3.7? How do you fine-tune the compression options?
> 
http://wiki.povray.org/content/Documentation:Reference_Section_1.1#Output_File_Type

Post a reply to this message

On 26.04.10 19:34, Warp wrote:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 26.04.2010 15:01, schrieb Warp:
>>> Slime<fak### [at] emailaddress>   wrote:
>>>> I don't think the default file type should be one that uses lossy
>>>> compression.
>>>
>>>     I didn't know that POV-Ray even supported lossy formats as output...
>
>> Contrary to rumors, POV-Ray can output JPEG.
>
>    Is that new in POV-Ray 3.7? How do you fine-tune the compression options?

It has been there in 3.6 as well, but was simply inaccessible from the 
command line (but would have been accessible i.e. for special rendering of 
insert menus from inside POV-Ray, though this was not done). In 3.7 general 
access was added.

	Thorsten

Post a reply to this message

On 26.04.10 00:16, clipka wrote:
> Am 25.04.2010 23:20, schrieb Alain:
>> Le 2010-04-25 05:44, clipka a écrit :
>>> How about changing the default output file type for both Windows and
>>> Unix version to PNG?
>>
>> Why not for all versions?
>
> With me having not much of an idea about Macs anyway, I pass that
> question on to any Mac experts listening right now...

PNG is the system's preferred file format in Mac OS X.

	Thorsten

Post a reply to this message

Jim Holsenback <jho### [at] povrayorg> wrote:
> >   Is that new in POV-Ray 3.7? How do you fine-tune the compression options?
> > 
> http://wiki.povray.org/content/Documentation:Reference_Section_1.1#Output_File_Type

  Thanks.

-- 
                                                          - Warp

Post a reply to this message

On 4/25/2010 4:44 AM, clipka wrote:
> How about changing the default output file type for both Windows and
> Unix version to PNG?

Another vote for PNG. That's the format I always go to for POV.

-- 
~Mike

Post a reply to this message

Am 26.04.2010 19:34, schrieb Warp:

>> Contrary to rumors, POV-Ray can output JPEG.
>
>    Is that new in POV-Ray 3.7? How do you fine-tune the compression options?

No, it has just been undocumented - for good reason: POV-Ray 3.6 was 
able to generate JPEG output as well, but the quality was terrible and 
couldn't be changed.

With 3.7, compression is set with the "Compression=N" INI-file option, 
where N is an integer value from 2 ("horrible") to 100 ("top quality"). 
A value of either 0 or 1 will select the default (95; 3.6 apparently 
used a value somewhere around 10).

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.

Post a reply to this message

"clipka" <ano### [at] anonymousorg> wrote in message 
news:4bd40f13$1@news.povray.org...
> How about changing the default output file type for both Windows and Unix 
> version to PNG?

Yes please!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 26.04.2010 19:34, schrieb Warp:
>
> >> Contrary to rumors, POV-Ray can output JPEG.

> With 3.7, compression is set with the "Compression=N" INI-file option,
> where N is an integer value from 2 ("horrible") to 100 ("top quality").
> A value of either 0 or 1 will select the default (95; 3.6 apparently
> used a value somewhere around 10).

I always thought that .jpeg compression quality was set within a simpler
1-through-10 scale --just those and no in-between values. (That's how my old
version of Photoshop does it, anyway...which is about the extent of my
knowledge.)

How was 95 arrived at for the 3.7 default (vs. 100)? They're so close. More
importantly, can all image-viewing apps decode .jpegs created with such a
'fine-scale' 1-to-100 compression choice? I base this question on problems I've
encountered (in Photoshop again, v5.0): strangely, even within its own 1-to-10
scale, there are several values that produce an image which isn't viewable in
some other apps I have. Maybe that's strictly a problem with the older
Photoshop--but it makes me wonder about the 1-to-100 variation in 3.7. Could the
'wrong choice' of a particular interim value produce an image-decoding problem?

Ken

Post a reply to this message

Am 26.04.2010 22:29, schrieb Kenneth:

> I always thought that .jpeg compression quality was set within a simpler
> 1-through-10 scale --just those and no in-between values. (That's how my old
> version of Photoshop does it, anyway...which is about the extent of my
> knowledge.)

No, basically the JPEG compression quality is a non-discrete value; from 
what I known, theoretically it should be in the range from 0.0 to 1.0, 
but software may use a pretty arbitrary scale in its UI. POV-Ray uses 
percents, for that matter.

> How was 95 arrived at for the 3.7 default (vs. 100)? They're so close.

Well, someone figured that raytraced images should be stored at pretty 
high quality, and decided that 95% made for a nice trade-off between 
size and quality. (File size does not grow linear with the quality 
value; in a quick test I just did, going from 95% to 100% more than 
doubled the file size.)

 > More
> importantly, can all image-viewing apps decode .jpegs created with such a
> 'fine-scale' 1-to-100 compression choice? I base this question on problems I've
> encountered (in Photoshop again, v5.0): strangely, even within its own 1-to-10
> scale, there are several values that produce an image which isn't viewable in
> some other apps I have. Maybe that's strictly a problem with the older
> Photoshop--but it makes me wonder about the 1-to-100 variation in 3.7. Could the
> 'wrong choice' of a particular interim value produce an image-decoding problem?

I don't think this has anything to do with the compression quality value 
/per se/. Probably it's some bug in Photoshop 5.0's encoder that just 
doesn't show at low compression settings (e.g. an overflow somewhere in 
the math).

(My versions of Photoshop (6.0) happens to use a 0..100% range as well.)

Post a reply to this message

Am 26.04.2010 21:08, schrieb clipka:

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

I guess I found the culprit. Someone apparently misunderstood either the 
libjpeg interface or the vanilla JPEG file format standard.

Post a reply to this message

clipka wrote:
> No, basically the JPEG compression quality is a non-discrete value;

JPEG compression quality isn't even defined as a number. Each 8x8 block on 
the image can pick how much of the quality to throw away. (For example, I 
wrote one compressor way back in the dark ages that would compress a block 
less if the average color was close to skin-tone.)

It's not a number. It's an entire 8x8 matrix for each 8x8 block of the 
image. That said, most programs take the number you give it and translate it 
into an appropriate 8x8 block. The open source library (originally used in 
cjpeg and djpeg) used a 0..100 scale. On this scale, 95..100 give you a 
range of pixels that are usually spot-on, or off by one out of 255 each, but 
a huge change in the size (3x? 10x?) for stepping from 95 to 100.

There's also the possibility of having multiple huffman tables, or an 
optimized huffman table, or a simple huffman table. Nobody does the simple 
huffman table any more, but back when a jpeg compression took ten seconds or 
so, not going thru it twice to recalculate the huffmans was sometimes 
worthwhile.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

> 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] anonymousorg> 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