Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image capture color modes #3

Open
jensjeflensje opened this issue Sep 19, 2023 · 1 comment
Open

Image capture color modes #3

jensjeflensje opened this issue Sep 19, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@jensjeflensje
Copy link
Owner

jensjeflensje commented Sep 19, 2023

Image capture could feature multiple color modes (like smartphone cameras have). Mode should be an ImageCaptureOption Examples could be:

  • Grayscale
  • Normal color (like it is now)
  • HDR (more vibrant)

Still needs some thinking. It could also be left up to the implementation outside the library

@jensjeflensje jensjeflensje added the enhancement New feature or request label Sep 19, 2023
@ConnorBP
Copy link
Contributor

ConnorBP commented Nov 7, 2024

I have an additional suggestion for color mode:

You could have, more broadly, output modes.

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:

  1. 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.
  2. 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 this
public enum ImageProcessMode {
    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants