BcStream class implementation about bcnencoder.net HOT 18 CLOSED

Regarding the pixel span coming from ImageSharp, provided you have a similar type in this library with the same exact fields in the same order, then you'd be able to cast a Span of ImageSharp color struct to a Span of BcnEncoder color struct using MemoryMarshal.Cast().

from bcnencoder.net.

... @Nominom Ehm... I think we both know that color channels for BCn do NOT contain audio... right? Am I just not in my right state of mind, or does he somehow feel attacked by you wanting him to elaborate further?

from bcnencoder.net.

Otherwise, back to the Stream. As long as the Stream reads/writes bytes, what would be the benefit of the BcStream? I would think the main benefit of the BcStream would be to read arbitrary amounts of blocks as decoded colors.
If we can get a consens on that one thing I would already have a design ready and implementation ready for BcStream.

from bcnencoder.net.

While I did read the guy's wall of text, I have to admit that I only understood half of it, due to weird phrasing, no offense.
However, I'm inclined to believe that such a stream would actually not do much in terms of enhancement.

I see this library specifically, first and foremost, to decode and encode BCn. The library also provides enough functionality already to decode/encode raw data to/from BCn or from/to 2 widely used standardized graphic file specifications. I'm also not entirely sure if all those raw image formats are actually necessary (I think RGBA would be plenty for conversion)

Also, the dependency on ImageSharp is a plus, since it allows to add mutations and transformations to the image already. The library doesn't need to provide any stream/interface or whatever, since those capabilities are already given.

Closing statement: I think it doesn't add much useful enhancement in the scope this library has.

from bcnencoder.net.

Also, the argument about any further exotic usage of "unused" bytes is unnecessary in my opinion. This libraries scope is BCn. BCn is well specified and leaves nearly no undefined behaviour.
If one considers exotic usage like "hidden data in bits" for whatever purpose, then I think it's way out of scope. So bringing up those arguments as a reason to somehow generalize the code more or add more abstractions is useless.

I would agree to those arguments and the stream class in general, if this libraries scope would be wider, but imo it's just to narrow. It's just BCn encoding and decoding.

from bcnencoder.net.

But if this is a feature to be implemented, you should be aware that the Stream class may not be able to derive from System.IO.Stream. I understand the BcStream as something that reads or writes whole BC blocks. So you can either seek an arbitrary block and decode it or set the block.
This implicates that System.IO.Stream is not usable, since its read and write methods read/write bytes, not an arbitrary data structure.

from bcnencoder.net.

Thanks for your thoughts. I agree that this library should be focused mainly on compressed block-formats of the BCn family. Raw encoders are there just for convenience.

Two people already have asked for a version without ImageSharp, so there seems to be some sort of a demand for a change. I do like ImageSharp myself since it fits nicely into my own use-case for this library, and I'd rather not program a fully-fledged jpeg/png/tga encoder when there is a few good options already. One option is to make the api ImageSharp compatible without actually having it as a dependency.

As for the stream implementation, I feel like it could be a necessary or helpful component to some people's use cases, but there's not much that could not be accomplished with the current api.

I looked at (the only) 3 different public projects that have BCnEncoder.NET as a dependency, and 2 of them (1 2) use only the raw api with mipmaps, and one ( 3) uses the decoder only. I don't see any of them benefiting from a Stream version. That is not to say that there are no people who didn't use this library because of the lack of a stream interface, I wouldn't know.

I would love to hear more people's thoughts on this, if they happen to find their way here.

As for the incompatibility with traditional Stream methods, it would at least have to read 4 rows of pixel data before it could write any blocks. This might require a large internal buffer for the stream. You also wouldn't be able to read single bytes out without the Stream implementing some sort of a output buffer as well. This makes the implementation of the Stream a bit of a challenge. Unless there are better options to solve such problems. Trying to seek would probably need to throw a NotSupportedException.

from bcnencoder.net.

Well, the thought of the BcStream would be to not inherit from System.IO.Stream, but keep its structure as close to System.IO.Stream as possible so it's usable more easily. However, the read and write methods may work on 8 byte block/4x4RgbaBlock basis instead. Position and Length could also represent blocks instead of bytes.

Also, Kuriimu2 (my project) will use your library. One of the reasons I started getting interest in this project and contributing to it like I did. Though, we also wouldn't benefit from the BcStream. (That's also one of the reasons I added ATC to this library, and why I have interest in BC6H more than in anything else currently.)

I also don't see any downside to having Imagesharp as a dependency? What was the reason for the people asking to get this dep removed?

from bcnencoder.net.

To have it work with any other stream types (which usually take in a stream as an argument) it would have to implement the normal stream abstract methods. I don't see it being useful otherwise.

Bc6 will take a bit more time. I'm a bit busy doing work stuff atm. Should have more free time soon though. 🙂

The first person was asking for a net45 build target, which proved to be a bit trickier since ImageSharp does not support net45. Otherwise this project wouldn't have a problem with it. The second one is the brain-interface person. I would also see that maybe not everyone wants or needs anything out of ImageSharp, so then that dependency would just be an extra step between whatever they are trying to accomplish. I feel like it's integral to have a way to get traditional formats converted to rgba for this library, but all the important bits would work without ImageSharp.

Using ImageSharp would just become like so:

using var img = Image.Load(file);
img.TryGetSinglePixelSpan(out var pixels);
encoder.Encode(pixels, img.Width,img.Height);

Instead of:

using var img = Image.Load(file);
encoder.Encode(img);

from bcnencoder.net.

It wouldn't resolve the dependency though. The pixel span you get back still depends on the structure of a pixel provided by ImageSharp. So the encoding code got one line longer, without a benefit.

And yes, normally I would agree to inheriting the normal stream abstract class. But I explained above why that might not be a practical way to do it. What exactly are you getting back from the Read method, if you read bytes? If you return the decoded RGBA8 colors as bytes, then the Stream has no real benefit, because you still have to decode RGBA8 to a usable color struct, or wrap it to an image yourself. I would see more usefulness if you get any kind of wrapped color/image back for a full block.

from bcnencoder.net.

See also dotnet/runtime#39601

from bcnencoder.net.

Yea that's what a Span2d would also provide @ptasev rite! The bigger issue I see it anyway is how your gonna deal with bits 12|12|12 or 10|10|10(1|2) or a bayesian with arbitrary lengths. Or to determine how to take a biased sample e.g. from a pixel juxtaposition depending on Quality etc.

Image sharp is probably quite good for Color conversions but you will sometimes find in certain implementations a color profile is defined in a way in which it does not fit directly in the color space of another; thus mapping such colors is really the only option available.

There's an interesting discussion in the https://github.com/dotnet/runtime/issues?q=is%3Aclosed if your curious.

Then if you need to do anything type... OOB or out of the ordinary e.g. keeping some audio type data in reluctant alpha channel, there is no conversion it will provide for your and if you want to work with Pure Audio Data and do something simple e.g. get data only from a certain channel you need an ENTIRE other library. (For the same stride based operation)

from bcnencoder.net.

It wouldn't resolve the dependency though. The pixel span you get back still depends on the structure of a pixel provided by ImageSharp. So the encoding code got one line longer, without a benefit.

The Encode method would be defined like this:

public byte[] Encode<T>(ReadOnlySpan<T> pixelsRgba, int width, int height);

MemoryMarshal.Cast would cast it to a byte or internal Rgba32 array.

Maybe we could offer the ImageSharp api as an addon package, like BcnEncoder.NET.ImageSharp. It could offer the Image methods as extension methods, since I do like the convenience of just feeding the Image without having to do any extra work.

And yes, normally I would agree to inheriting the normal stream abstract class. But I explained above why that might not be a practical way to do it. What exactly are you getting back from the Read method, if you read bytes? If you return the decoded RGBA8 colors as bytes, then the Stream has no real benefit, because you still have to decode RGBA8 to a usable color struct, or wrap it to an image yourself. I would see more usefulness if you get any kind of wrapped color/image back for a full block.

Typical use-case would probably include chaining different streams together eg. MemoryStream -> BcStream -> DeflateStream -> FileStream which would require the BcStream to extend System.IO.Stream. I think it wouldn't be worth implementing if it cannot be done as a normal Stream.

from bcnencoder.net.

Yea that's what a Span2d would also provide @ptasev rite! The bigger issue I see it anyway is how your gonna deal with bits 12|12|12 or 10|10|10(1|2) or a bayesian with arbitrary lengths. Or to determine how to take a biased sample e.g. from a pixel juxtaposition depending on Quality etc.

Image sharp is probably quite good for Color conversions but you will sometimes find in certain implementations a color profile is defined in a way in which it does not fit directly in the color space of another; thus mapping such colors is really the only option available.

There's an interesting discussion in the https://github.com/dotnet/runtime/issues?q=is%3Aclosed if your curious.

Then if you need to do anything type... OOB or out of the ordinary e.g. keeping some audio type data in reluctant alpha channel, there is no conversion it will provide for your and if you want to work with Pure Audio Data and do something simple e.g. get data only from a certain channel you need an ENTIRE other library. (For the same stride based operation)

I'm not sure what you mean by dealing with 12|12|12 or 10|10|10|(1|2). Could you elaborate? If you mean pixel formats like that, I don't think this library is ever going to add support for them. The 8-bit per color basic formats is what we have.

As for encoding audio into the alpha channel, if it can be implemented externally with the Stream api, It's all good. I'm not planning on adding any internal support for audio though.

from bcnencoder.net.

Yea that's what a Span2d would also provide @ptasev rite! The bigger issue I see it anyway is how your gonna deal with bits 12|12|12 or 10|10|10(1|2) or a bayesian with arbitrary lengths. Or to determine how to take a biased sample e.g. from a pixel juxtaposition depending on Quality etc.
Image sharp is probably quite good for Color conversions but you will sometimes find in certain implementations a color profile is defined in a way in which it does not fit directly in the color space of another; thus mapping such colors is really the only option available.
There's an interesting discussion in the https://github.com/dotnet/runtime/issues?q=is%3Aclosed if your curious.
Then if you need to do anything type... OOB or out of the ordinary e.g. keeping some audio type data in reluctant alpha channel, there is no conversion it will provide for your and if you want to work with Pure Audio Data and do something simple e.g. get data only from a certain channel you need an ENTIRE other library. (For the same stride based operation)

I'm not sure what you mean by dealing with 12|12|12 or 10|10|10|(1|2). Could you elaborate? If you mean pixel formats like that, I don't think this library is ever going to add support for them. The 8-bit per color basic formats is what we have.

I tend to tangencize the smallest details, there is nothing to elaborate here based on your understanding and demeanor.

As for encoding audio into the alpha channel, if it can be implemented externally with the Stream api, It's all good. I'm not planning on adding any internal support for audio though.

Umm there is already audio in many a different of your channels...

Yes it can.

Encoder / Decoder does not care about the underlying.. your words give me pause and with that I take my leave.

You know where to find [sic].

Thank you for your time and efforts!

from bcnencoder.net.

... @Nominom Ehm... I think we both know that color channels for BCn do NOT contain audio... right? Am I just not in my right state of mind, or does he somehow feel attacked by you wanting him to elaborate further?

I think there was some sort of a misunderstanding. I wasn't trying to be mean or attack in any way. I was just geniunely not sure what he meant.

They are at least not meant to contain any audio data by default. But maybe he is using the alpha channel for audio. I don't know now. I don't see how it works though, since the rest of the image is a static point in time and audio is a waveform over time. Or maybe all the pixel channels are being used for non-image data. Well anyways, this is exactly why I wanted more information about the use-case and wasn't sure if modifications were needed to accomodate it.

In any case, there was clearly some sort of a communication barrier. Or maybe I'm dumb.

from bcnencoder.net.

Otherwise, back to the Stream. As long as the Stream reads/writes bytes, what would be the benefit of the BcStream? I would think the main benefit of the BcStream would be to read arbitrary amounts of blocks as decoded colors.
If we can get a consens on that one thing I would already have a design ready and implementation ready for BcStream.

I think the main use case would be something like encoding or decoding a live-feed to or from a compressed format. Maybe a NetworkStream coming in is encoded with Bc1, and the Bcstream would sit in between as a translator. Or someone encoding/decoding to/from a fileformat that is not supported by this library. I'm not sure about the benefit. Would it be easier with a stream than using the normal raw apis?

I don't see how the design should look though. And since the original person asking for this is gone, I think it is not a good idea to go forward without a solid use-case where it would be a real benefit.

Unless you want to implement your idea, @onepiecefreak3. We can move forward if you have something solid.

from bcnencoder.net.

I'm closing this issue for now due to lack of need for a stream. Single-block encoding has already been implemented and in my opinion, satisfies the use-case that a stream class would have.

from bcnencoder.net.