joouha
commented
1 year ago Hi again!
Partial image rendering is something I'm planning to implement. I think cropping the images in sixel-land is a good idea.
I had originally planned to just crop the images in PNG-land and re-convert them each time (but you're right, this would be slow), and I have tried slicing images and converting the parts separately (but you're right that it doesn't work well).
Images in euporie are always aligned to the top edge terminal cells, which makes things a bit simpler, although a sixel-cropping library would need to be able to edit the last row of sixels to blank out some pixel-rows. A more complex use-case would be aligning cropped sixel images to the bottom edge of a cell, as this would require shifting pixels between sixel boundaries.
I also support the kitty and iTerm2 graphics protocols in euporie, which would need to support partial image rendering too:
- Kitty's protocol allows you to specify the region of the image to display, so should be straight forward to implement;
- iTerm2's protocol basically consists of dumping base64 encoded images, so images would need to be cropped in PNG-land.
I'll need to refactor euporie's format conversion system to allow images to be cropped at arbitrary points in the conversion chain, then a sixel-cropping library would slot right in.
Is a sixel-cropping library something you're interested in writing?
jerch
While playing with your euporie browser example I saw that you do a low quality prerendering of graphics while they are not fully in viewport, and once they are fully in the viewport, switch to better quality with sixel.
This currently raises 3 issues:
Thus I wonder if it would be feasible to do partial sixel rendering.
Now the main issue with sixels is - it is very expensive to convert the original image into sixel in the first place, as it needs quantization and dithering. So ideally one want to do that only once and cache the result. On the other hand the advanced image algos needed for sixel conversion kinda make pre-slicing the original image into line parts and separately convert to sixel a no-go, as the created color palettes and dithering pattern are not stable (would lead to ugly stitching artefacts).
A possible solution to all those downsides would be a sixel-cropping library, eg.:
A more involved solution would be to write own sixel converter capable to freeze the color palette, and do the substitution on slices of the original image. This would need one initial quantization step creating a color substitution map with dithering marks. With that slices can be created pretty fast and memory efficient. (I suggested something similar here for the julia peeps, as they are keen to code such a thingy on their own).
So I wonder if you are interested in such an enhancement for sixel output. In general I'd lean more towards to the sixel-crop library idea, which should be straight forward to implement.