Decoding api about image HOT 19 CLOSED

Perhaps use u32 instead of u16?

from image.

I chose u16 because png is the only image format (that i know of) that uses more than 16 bits to reperesent dimensions, and in practice most decoders put a limit on image size, about 10 000 pixels

from image.

perhaps if you make a typedef for an image coordinate,you can clarify code that takes pixel addresses
this is why we need associated types and so on .

this reminds me of my desire to make a Vec<T> workalike but with parameterised index .. Vec<T,Index=i32>

the image size type is significant because its' also the type for valid indices; if you were to completely generalise, you'd want that to be a type-parameter, but default it to something sensible (either u16 or u32 sound fair, but u32 is the nicest default for most things , if you think about how it will propagate; i would actually default to using signed values, even for indexing, because you still need a bounds check and most arithmetic intermediates benefit from signed values).

from image.

If that's the only reason we should make it u32 to make it future proof.

u16 gives a limit of images of 8GB, but with u32 it gives 8 billion GB, which should be enough.

from image.

before rust has associated types - maybe the safest thing to do is to just make a type for it.. type ImageIndex=u32 / u16 ... whichever you settle on

from image.

It's ok for me to have a type alias, but put it in a module internal like Rust-Graphics.

from image.

@dobkeratops thats a good idea i will do that.

from image.

.. and I think I'd personally side with u32 as the default aswell - unless a use case appears where you need to make pixel addresses compact. Usually pixels are iterated; and there are use cases for huge images with virtual paging, e.g. megatextures, google-earth; but mostly, u32 is a more useful type to propagate; you'll have less casting. There's even a case for making it i32, on that front, but that goes against rusts' philosophy of making array indices unsigned.
You certainly deal with pixel offsets in image processing, which means negative numbers.

• ah, consider wrap round coordinates
• you might have some abstract image iterator that can access pixels out of range, by wrapping them

from image.

updated issue

from image.

rowlen should perhaps be row_len

from image.

Another issue would it be more convenient for decoders to operate on slices (&[u8]) or Readers (as it currently does).
Operating on a Reader is convenient if all you want is to load a file in one pass.
But operating on slices can be more flexible especially if you want to allow suspending decoding like libpng

from image.

would it make sense for the contained data to be a type parameter?
this is just the battle of abstraction vs over abstraction I guess, I don't know where you feel the line should be drawn.

trait ImageDecoder<PixelType=Rgba8888,Index=i32> { } perhaps .. extract scan lines of &[PixelType] etc.
u8 channels are certainly the most common, but you do get HDR images and 10bit monitors .. so the possible types explode.

and of course it might not be 'colour' - NormalMaps, monochrome intensity, infrared image .. etc.

If you wanted to write an image processing program today.. you'd certainly want give the option for high precision colour data. makes a big difference for proportional buildup and not propagating errors

I think rusts' type inference does make it easy to deal with parameterised types although it does complicate signatures a bit... IMO the ease of making things generic is a strength of the language to be leveraged.

from image.

I am a bit worried about designing for too many use cases. Try the obviously stupid first. We have lot of time to iterate on the design later.

from image.

@bvssvni i know what you mean. I will leave as it is.
@dobkeratops i thought of that. Essentialy have the imagedecoder be parameterized over ColorType.

from image.

@dobkeratops I think

from image.

accidently closed

from image.

@bvssvni @dobkeratops i'll begin implementing this trait with JPEG and see how it goes

from image.

@dobkeratops that was my initial intention. Thats why currently all image decoders return IoResult.
They are all streaming decoders. Except for the webp decoder

from image.

(ok i deleted my question as i read your clear original post 'decoding errors..')

oh ok and 'colortype' is more likely to be dictated by the file, right? so it wouldn't actually make sense to have it parameterised in the decoder trait at all, rather returning some enum of what the supported formats supply..

from image.