kino
kino copied to clipboard
Automatic image detection
We can look at a binary and if it looks like an image, we can automatically show it as said image.
@josevalim, could you elaborate?
In a nutshell, if you do a File.read!("some.png")
, we should automatically show it as an image! Does that make a bit more sense? :)
In a nutshell, if you do a File.read!("some.png"), we should automatically show it as an image!
I got that, but how do we show it as an image? Do we have some sort of icon hovering near the cell output saying so or what?
We would use Kino.Image behind the scenes. There is already some code in Kino that customizes how data structures are formatted, and we would add special logic for binaries.
@Benjamin-Philip we have the Kino.Render
protocol that determines how a value is transformed to an output, so we need to implement it for BitString
where we check if the binary is one of a few common image encodings. This is kinda similar to what we do for ETS where we detect if a reference is a table.
The only issue I can think is that we would need a way to opt out in case of false positives.
@Benjamin-Philip we have the Kino.Render protocol that determines how a value is transformed to an output, so we need to implement it for BitString where we check if the binary is one of a few common image encodings. This is kinda similar to what we do for ETS where we detect if a reference is a table.
So rather than making the user call Kino.Image
, we would like to render it automatically?
Yes.
Ah, now I undestand...
The only issue I can think is that we would need a way to opt out in case of false positives.
True, someone may want to deal with the binary itself. I think we could a part of Kino configuration, so the user could do Kino.configure(format_built_ins: false)
. I don't think we need a separate option for every conversion, since it's not going to be common anyway?
So rather than making the user call Kino.Image, we would like to render it automatically?
Yeah, the primary purpose of Kino.Image
is so that we can wrap arbitrary binary in it and implement the protocol, so that's not necessary :D
In this case, wouldn't we want to make rendering Binaries it's own protocol on top of Kino.Render?
The reason being is that people might have binaries other that images that might need rendering (videos for example). We then would build rendering Images on top of this new protocol.
That already exists for images. We could add one for video. We need to add the dynamic inference nowz
Now that we have tabbed outputs, we can perform the inference and show a tabbed output between image and raw (probably image by default if it does have a low false negative rate).