Dynamicimage

[woelper]

No description provided.

[B-LechCode]

@woelper I started looking in that and tried to render grayscale textures - which didn't work. I created them as R8, but I can't tell notan to add a swizzle mask or something else to render it grayscale.

Doing "imageops::crop_imm" on a "DynamicImage" will always result in an rgba image, even if the underlying data is grayscale.

I didn't find any flaws in your implementation so far.

[woelper]

Thanks so much for looking at it! Regarding grey textures, that is of course bad news. Maybe we can use a shader to convert red to grey? Would it make sense to open an issue in notan for this?

[B-LechCode]

I thought about asking in notan's issue section, too.
I will do this rn :)

Yes, we maybe could define a default shader, doing conditional conversion?

[woelper]

Great!

Yeah, a shader could make sense anyways for HDR and other things!

[B-LechCode]

@woelper do you know where to inject a pixel shader to do that? That's beyond my knowledge. Maybe you got some hints.

Then I would try to commit a dynamic rendering for R8 at least.
Edit: Could this work: "https://github.com/Nazariglez/notan/blob/develop/examples/draw_image_shader.rs"?

[woelper]

I was going to post the same URL :)

I am quite happy with the progress, your idea to have a convert operator was amazing. The pixel operators and image operators already support some additional data types and you can convert on the fly between them.

[B-LechCode]

I got it for image rendering, but not for egui::image.
Maybe you have an idea where to add a shader for egui.
The alternative is maybe to use notan here, too. (Need to look at it today!)

Edit: I committed my changes, I hope it's okay for you! Due to the special behavior of imageops::crop_imm on dynamic image, I needed to match the types. Maybe you can have a look at it, if this is a bug or intention.

[B-LechCode]

@woelper is the branach dynamicimage_zoom supposed to combine the new zoom image and dynamic image?
I'd merge them then together and delete both old branches?

[woelper]

Hi! I tried to combine them by merging zoom into it and made it build, but I think I am missing something. If you have time maybe you can try integrating the changes from your zoom window branch directly into this one? I can delete the dynamicimage_zoom in that case.

[B-LechCode]

Hi! I tried to combine them by merging zoom into it and made it build, but I think I am missing something. If you have time maybe you can try integrating the changes from your zoom window branch directly into this one? I can delete the dynamicimage_zoom in that case.

Done :)

[woelper]

Amazing!!

[B-LechCode]

Amazing!!

Working on adapting zoom image to Notan rendering.
That might take some time. Will come back when done.
Adding the shader here, too works. So I think we can go on :)

Opening really big grayscale images got extremely faster!

[B-LechCode]

@woelper
There are some types in Dynamicimage which don't have corresponding types in notan. All La-Types for example.

I thought about using a texture n times wider (double the width for La images) and writing a shader which always "consumes" n adjacent pixels for rendering.

Do you have a better idea in mind? This feels a little bit hacky.

[woelper]

I would probably just convert them to rgb8 or rgba8 from the DynamicImage I think.

[B-LechCode]

I would probably just convert them to rgb8 or rgba8 from the DynamicImage I think.

Okay, maybe we should then limit the type conversion stuff to RGBA and Grey (for 8, 16 and 32 float bit depths) only? But maybe this degree of freedom is a good thing just to convert images?
Or should we make the image loader to directly convert to one of those 6 types automatically? - That's a thing we just need to specify, then I'll write the code for the texture-wrapper.

Please just think about it and tell me which option fits best :)

[Stoppedpuma]

@B-LechCode @woelper I've merged my branch with some additional tests you can use for this PR. There's a shell script located in the tests folder which creates a bunch more for some possible edge cases like odd resolutions, yuvs, bit depths, formats, etc.

[Stoppedpuma]

Not sure if anyone is aware of this one yet, but the zoom preview seems to be able to draw above overlays.

[B-LechCode]

Not sure if anyone is aware of this one yet, but the zoom preview seems to be able to draw above overlays.

Cool! Thanks for sharing that info :)

[woelper]

I think this is because it draws last and does not sort with egui. How about we hide the info if file browser is open?

[B-LechCode]

I think this is because it draws last and does not sort with egui. How about we hide the info if file browser is open?

What about a second egui context which renders after? Could both be a possible solution.

[woelper]

That could be an option if it works with notan. We'd need to deal with multiple contexts and UI and determine when to use what, which might not be obvious. An advantage would be that we could use it to draw elements auch as gizmos last.

[Stoppedpuma]

I think this is because it draws last and does not sort with egui. How about we hide the info if file browser is open?

The problem I think here is it removes the overlay / window feel which makes the "file manager" feel more like a "file overlay". I think making it an overlay doesn't make much sense to do without making other windows separate from the main instance or also overlays as they have the same kind of feeling at the moment. I would prefer avoiding these directions as it's already a bit of a headache on tiling window managers dealing with some applications which create additional windows for something which could easily integrate into the main window UX and UI wise.