You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This can include Normal, Grayscale, HDR, Rec709, LINEAR, LUT (the simple obs kind), etc...
But I propose that in additon to normal color mode output that there be a raw blocktype output. This would output an array of block material hits as the pixels attached to some metadata for capture resolution.
Reasoning:
This would allow a user to perform any color processing they want on the output after, with the ability to quickly change block color pallets.
With this intermediary output before color processing as output, a plugin developer could set up a system which renders these blocks onto a canvas in the world made up of the exact blocks they are trying to depict. This would have much nicer and cooler results than translating from block to color and back again I imagine.
Implementing this would be a matter of storing blocktype upon hit, and putting off color processing to a later stage at which it will run a different color processing step based on which enum is selected. Or maybe instead of an enum it's a matter of which overloaded image.process() function you call after capture to get the final desired output. In that case, you would first render the image, at which point you can access the raw block types array from the raytrace. Then you can call one of the process functions to get the desired image output type.
// an enum for it would look like thispublicenumImageProcessMode {
NORMAL,
GRAYSCALE,
HDR,
RAW// block type output
}
as for file output, raw type could be serialzed to json with GSON. But thats for other plugin devs to worry about unless you want this plugin to output files also.
Image capture could feature multiple color modes (like smartphone cameras have). Mode should be an
ImageCaptureOption
Examples could be:Still needs some thinking. It could also be left up to the implementation outside the library
The text was updated successfully, but these errors were encountered: