Experimenting with this a while back I believe it has to do with the way the
underlying DPX read code is setup. It was something like reading the image info
opposite of the way it was laid out on disk which in turn sparked a whole lot
of file seeking.
I can’t quite remember the specifics but implementing the read_image(…)
method(s) on dpxinput and just giving it the whole block was much faster.
dpx::Block block(0, 0, m_dpx.header.Width() - 1, m_dpx.header.Height() - 1);
I’ve made a simplified gist of that change:
https://gist.github.com/mccartnm/eca84c2acd7240c2108e14cf6c718144
This may not fix your issue but it did get us off the ground. It may need
someone to take a harder look at the dpx reading code that DPXInput uses.
Hope this helps.
Cheers,
- McCartney
From: Oiio-dev <[email protected]> On Behalf Of Renaud
Talon
Sent: Tuesday, September 3, 2019 3:28 PM
To: [email protected]
Subject: [Oiio-dev] OIIO 2.x extremely slow DPX load time
[ CAUTION ]
This email originated outside Deluxe.
Hi,
Is anybody else having issues with extremely slow load time of DPX files since
OIIO 2.x.x ? (Windows 10)
Please watch the benchmark video below which illustrates the issue preventing
us from upgrading from OIIO 1.8.x+.
OIIO 2.x.x DPX load time issue
Benchmark<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvimeo.com%2F357644049&data=02%7C01%7Cmmccartney%40stereodllc.com%7Ca2a74222021c49f3a3ee08d730a4d428%7C8688c7c41f2a4115a918361023dde469%7C1%7C1%7C637031356828252187&sdata=Q8X0DKQiVOeyrUVsG0l0L3SK%2FuS6GpqYQK6X9nr4Ax0%3D&reserved=0>
(https://vimeo.com/357644049)
The test code running in the video above loads full res images (DPX, EXR, JPG,
PNG) and creates thumbnails that are displayed within a Qt app.
It’s important to note that each image is loaded in parallel using Qt’s
QThreadPool. I suspect this is a threading (lock) issue.
I can reproduce this behavior in both C++/Qt and Python bindings/PySide2 using
Python 3.6+ or Python 3.7+. I’ve had this issue since I compiled one the first
2.0 release but I didn’t have time to troubleshoot to isolate the problem until
now.
I was hoping this would be a problem other people would have and that it would
be fixed by now.
I also tried to re-compiled using various compilation settings, removing all
non-required third party libraries but the issue remained. It’s interesting
this happens for DPX files only since this is not an “external library” (or at
least it’s distributed with OIIO code as far as I know).
Other formats all seem to load much faster in OIIO 2.x.x+ which is absolutely
awesome unfortunately DPXs are still a big part of our world and we can’t
upgrade because of this ☹.
Anybody else using OIIO 2.x.x is having similar issue on Windows ?
Larry do would you have any idea what’s causing this ?
Thank you
OIIO 2.0.10:
* Visual Studio 2017 (x64)
* Boost 1.70
* FFmpeg 4.0
* libbz2 1.0.6
* zlib 1.2.11.8900
* libjpeg 9b
* libpng 1.6.33.8807
* libRAW 0.19.5
* OCIO 1.1.1
* OpenEXR 2.3.0
* tiff 4.0.10
Renaud
[ CAUTION ]
DO NOT open attachments or click links from unknown senders. Only respond if
you can validate the senders legitimacy.
This e-mail and any attachments are intended only for use by the addressee(s)
named herein and may contain confidential information. If you are not the
intended recipient of this e-mail, you are hereby notified any dissemination,
distribution or copying of this email and any attachments is strictly
prohibited. If you receive this email in error, please immediately notify the
sender by return email and permanently delete the original, any copy and any
printout thereof. The integrity and security of e-mail cannot be guaranteed.
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
