William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/11/20 12:17 AM, Kima wrote:
> ...
> > As an update, if it might be beneficial to others.
> >
> > In my experience, the slowest format to save is PNG. Of course, PNG is the best
> > and common format in terms of quality and size.
> >
> > Saving in JPEG is the fastest though it is highly compressed. Unfortunately, a
> > heavily lossy format like JPEG is not suitable for the purpose of ray tracing.
> >
> > JPEG with 100% quality is close to PNG (POV-Ray see 85% by default). The
> > official document emphasises that even with 100% quality, there might be some
> > artefacts. I am inspecting this failure but haven't found any yet. JPEG with
> > 100% quality is about 40% of PNG size.
> >
> > As a side note, I believe the default value of compression in POV-Ray (85%) is
> > too low. The default value in ImageMagick for conversion to JPEG is 92%. It does
> > not make sense to use many resources to ray trace a scene and save it as a
> > heavily lossy format.
> >
>
> Thanks for the information. I found myself thinking about your post...
> Where did exr output come out size and performance wise?
>
> There are formats other than exr which don't compress on output - ppm is
> another I think, and you can set the depth there to 16 bits per color
> channel too. If the uncompressed output is much faster, perhaps use one
> of those formats and compress/convert with external scripts?
>
> I'm no image format expert (Christoph was the guy there) - and I haven't
> spent much time in the image file handling code. Still, I'll risk adding
> a few POV-Ray code related comments. :-)
>
> - The jpeg output doesn't dither which may be part of the speed
> difference relative to png.
>
> - The jpeg library itself looks to support a no-compression jpeg output
> by setting the quality to 0, but the current POV-Ray wrap maps <=1
> values (the default compression value is -1) to 85%.
>
> - I'd say 85% jpeg compression is sometimes suitable. :-) Just depends
> on what one is doing with POV-Ray. Aside: IIRC 85% was chosen to line up
> with the effective compression relative to some previous jpeg output,
> not because it was considered the best quality choice.
>
> - POV-Ray mostly uses standard external libraries when reading and
> writing images so the compression de-compression isn't POV-Ray per sa.
> The compression approaches are not all the same - with higher quality
> and lossless compression tending to be the most expensive. Which you
> probably knew...
>
> Aside:
>
> The jpeg library efforts are somewhat fractured. Most support no
> compression option I believe, some lossless too, etc. There is though
> one library better optimized for modern CPUs (turbo something?) and it's
> not currently the library used by POV-Ray. I think google did much of
> the work IIRC. A bit of a tangle in any case.
>
> Somewhere (github?) I ran across a highly optimized for simd
> architectures png library with benchmarks that looked great compared to
> the common png library. But, during my glance, it wasn't clear how much
> real world use of it there was.
>
> Anyway... I guess, it's somewhat meaningless practically, but there are
> image libraries out there which - perhaps - could enable better image
> input/output performance in POV-Ray.
>
> Bill P.

Thanks for the detailed description.

As the number of available cores/threads, it is vital to reduce this
single-thread process when creating many scenes (e.g., for animation). I am
experimenting with different cases to better understand possible outlets.

Compression is not the key factor. In the case of tga, it is only 40% faster to
use the uncompressed output as compared with the compressed one.

ppm and exr both are faster than png but not close to JPEG.

I reckon a key factor (if not the main) is the absence of alpha channel in JPEG.

Quality 0 will lead to the default 85%. Non-compression is the quality of 100%.
Technically, it is not compressed by the JPEG standard, but it is still
compressed because of the JPEG architecture algorithm (leading to the
possibility of artefacts).

I am trying to find out the chance of artefacts when using JPEG. If it is
negligible, then I believe JPEG 100% is a better choice than PNG when
transparency is not required.

Post a reply to this message