 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2020-07-12 à 08:42, Bald Eagle a écrit :
>
> I really haven't looked into graphics file formats in a long time, so I'll just
> ask this and see what happens. ;)
>
> What about BMP or GIF?
> I also never see anyone use RAW file formats - except for professional
> photographers, and it seems a bit --- complex.
>
>
BMP is close to a raw format. No compression and minimal header.
GIF only support up to 256 colours and is the grandfather of PNG.
Meaning that PNG wad developed to address the limitation of GIF and
improve the compression.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 7/10/20 12:19 AM, also sprach Kima:
>
> It takes about 5s to save output.png when almost no CPU resource is used.
> Obviously, I hope to reduce this period.
>
> Since the file is small 5-7MB, disk speed cannot be the bottleneck, but I
> checked the saving with an SSD and no difference.
>
> I use v3.8 on Ubuntu, and my command is
>
> povray +Iinput.pov -GA +Q11 +MB +UL +UV +A -D -V +TH +W3840 +H2160 +UA
> +Ooutout.png
>
I've written 1000s of 3MB .png files (1080p) and never noticed any
bottleneck with writing the file. On SSD, HDD, Ubuntu and Windows.
One speed trick that I do is to disable the pov-state file by putting in
my .ini file
Create_Continue_Trace_Log=Off
--
dik
Rendered 50,081,587,200 of 50,081,587,200 pixels (100%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10.07.2020 20:28, Kima wrote:
> You are right! I was able to reduce this period by changing the output format.
> It is not a matter of compression but data handling since the shortest time was
> to save as a lossy JPEG.
>
> Anyhow, I should find a way to do this single-thread process in the background
> while starting next rendering.
This behavior sounds more like a configuration error of your harddisk
drivers or some other odd configuration on your Linux system. The only
rational reason why JPEG would be "fastest" is that is produces the
smallest file of all file formats, and hence the actual data written to
disk is the least.
So you may want to start checking your local configuration.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dick Balaska <dic### [at] buckosoft com> wrote:
> Am 7/10/20 12:19 AM, also sprach Kima:
>
> >
> > It takes about 5s to save output.png when almost no CPU resource is used.
> > Obviously, I hope to reduce this period.
> >
> > Since the file is small 5-7MB, disk speed cannot be the bottleneck, but I
> > checked the saving with an SSD and no difference.
> >
> > I use v3.8 on Ubuntu, and my command is
> >
> > povray +Iinput.pov -GA +Q11 +MB +UL +UV +A -D -V +TH +W3840 +H2160 +UA
> > +Ooutout.png
> >
>
> I've written 1000s of 3MB .png files (1080p) and never noticed any
> bottleneck with writing the file. On SSD, HDD, Ubuntu and Windows.
>
> One speed trick that I do is to disable the pov-state file by putting in
> my .ini file
> Create_Continue_Trace_Log=Off
>
>
> --
> dik
> Rendered 50,081,587,200 of 50,081,587,200 pixels (100%)
Thanks, Dick.
The Create_Continue_Trace_Log=Off was quote useful. I was able to speed up the
process noticeably.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten <tho### [at] trfde> wrote:
> On 10.07.2020 20:28, Kima wrote:
> > You are right! I was able to reduce this period by changing the output format.
> > It is not a matter of compression but data handling since the shortest time was
> > to save as a lossy JPEG.
> >
> > Anyhow, I should find a way to do this single-thread process in the background
> > while starting next rendering.
>
> This behavior sounds more like a configuration error of your harddisk
> drivers or some other odd configuration on your Linux system. The only
> rational reason why JPEG would be "fastest" is that is produces the
> smallest file of all file formats, and hence the actual data written to
> disk is the least.
>
> So you may want to start checking your local configuration.
>
> Thorsten
Thorsten, it has nothing to do with writing the data on disk. It is about the
time required to produce JPEG or PNG file.
Save the output to a bitmap file (e.g., BMP) or even use any large image (not
produced by POV-Ray). It takes much longer to convert it to PNG as compared with
JPEG. Not just because the produce JPEG is smaller.
One reason is that PNG is zip-compressed (normally zlib).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13.07.2020 13:29, Kima wrote:
> Thorsten, it has nothing to do with writing the data on disk. It is about the
> time required to produce JPEG or PNG file.
No, it is not.
> Save the output to a bitmap file (e.g., BMP) or even use any large image (not
> produced by POV-Ray). It takes much longer to convert it to PNG as compared with
> JPEG. Not just because the produce JPEG is smaller.
>
> One reason is that PNG is zip-compressed (normally zlib).
No, believe me I know because I actually implemented the JPEG code in
POV-Ray. The ZIP compression does not take any longer than the JPEg
compression.
Your system very clearly has some sort of problem, and you really want
to find out what that problem is because it most likely also leads to
poor performance of other programs.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13.07.2020 13:22, Kima wrote:
> Thanks, Dick.
>
> The Create_Continue_Trace_Log=Off was quote useful. I was able to speed up the
> process noticeably.
Again, this file produces 20 bytes per pixel plus a bit of overhead
(believe me, I also wrote that code), which is next to nothing for a
modern disk, even for a modern harddisk. So if you can get a speed-up,
it is another major indication that you have a problem with your system
configuration.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
