> it's on you to warn OIIO that this is the kind of legit data you are expecting.
Are you considering to warn the user beforehand though in case he tries to pass such image? Be annoying to have the library starting to silently fail all of sudden. On Sun, 5 Dec 2021 at 7:21 AM, Larry Gritz <l...@larrygritz.com> wrote: > For what I'm thinking about, one can raise the limit with a call to the > library (or have no limit at all). So if you're dealing with a research > renderer with one channel per nm of spectrum, maybe it's on you to warn > OIIO that this is the kind of legit data you are expecting. > > I'm hoping to find a reasonable default where the likelihood is very high > that more than that number of channels indicates bad input, and only > advanced users who know that they are in this situation ever need to know > about and alter the option. > > 10 is too low -- although most people write AOVs to different files or at > least different parts of a multi-image file, I know some users have dozens > of channels crammed into one part/subimage. > > 1000000 is too high, that surely indicates a broken or malicious file. > > Somewhere in the middle is the right limit. > > And similarly, I'm also thinking about a maximum memory size for a single > flat 2D image as a sanity check to avoid being "tricked" into a memory > allocation that will fail (again, a limit you can override if you know such > images are coming). I'm thinking 4GB as the default. Does that sound > reasonable? Too low? What about 32GB (that's 64k x 64k x 4 chan x > sizeof(half))? > > > On Dec 4, 2021, at 9:55 AM, Thomas Mansencal <thomas.mansen...@gmail.com> > wrote: > > Hi Larry, > > With a spectral renderer, assuming storage every nanometers, 400+ > irradiance channels are totally plausible. This is more a research case > though, e.g. Mitsuba 2, but it is possible to see where this goes as soon > as you start combining that with AOVs, e.g. spectral direct vs spectral > indirect, per-light contribution, etc… > > Cheers, > > Thomas > > On Sat, 4 Dec 2021 at 9:47 PM, Larry Gritz <l...@larrygritz.com> wrote: > >> What's the highest number of color channels you've seen in a single legit >> image file? >> >> If we wanted to have a limit of the number of channels, over which we >> would conclude that a file was highly likely to be corrupt or even >> malicious... what is a reasonable limit? Is 1024 too low? >> >> (Assume there is a runtime way to override this limit, in the unlikely >> case that a legit file needs more than this number of channels.) >> >> >> -- >> Larry Gritz >> l...@larrygritz.com >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > -- > Thomas Mansencal - colour-science.org <https://www.colour-science.org/> - > thomasmansencal.com <http://www.thomasmansencal.com/> > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > -- > Larry Gritz > l...@larrygritz.com > > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > -- Thomas Mansencal - colour-science.org <https://www.colour-science.org> - thomasmansencal.com <http://www.thomasmansencal.com>
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org