issues with sixel not from libsixel

[jerch]

I just tested your lib with various inputs - works pretty nice with images coming from img2sixel.

Still I think you make some assumptions about the sixel layout, that are not strictly given by the format:

• Colors get scrambled, when running with --high-color switch of img2sixel. Background here - color registers may change at any time again. The question where to apply which color is typically bound to indexed (terminal mode) vs. immediately coloring (printer mode). Most terminals as of today do the printer mode here, only older ones (vt340, xterm) do the real shared palette indexed thing.
• Most of older sixels here dont work out of the box. It seems that I can get most working by setting an explicit height argument. Some still fail due to rigged right side of sixel bands though. In general sixel is a canvas print protocol, thus you cannot expect width/height to be set upfront and all bands to fullfill the correct width, instead you'd have to trace the cursor movements with its pixel coloring for the area of interest. (The size assumptions you made here are more a result of how the libsixel encoder typically shapes things, but that not required by the format spec.)

[joouha]

Hi - thanks for testing this!

Those examples are a really useful resource. I think I can get sixelcrop working properly with all of them.

Some of the examples are not pure sixel commands, but include extra escape codes at the beginning. Removing these fixes a number of issues.

Requiring an explicit height argument is not technically necessary, and that requirement can be easily removed.

The color scrambling occurs when colors are defined in the cropped regions. To speed things up, lines which are not displayed are just skipped over unparsed. I'm considering putting this behaviour behind a --fast flag, to make sixelcrop more compatible by default (but slower).

I don't think I'm making any assumptions about line lengths, so possibly something else is going on with the ragged line issue you've seen.

Thanks again!

[jerch]

Some of the examples are not pure sixel commands, but include extra escape codes at the beginning. Removing these fixes a number of issues.

Yeah, thats the reason why there are those _clean variants only containing the sixel data part. Originally I collected these files from various usenet and rather old webpages. Some are even in 8bit encoding, which is quite nasty in utf8 envs these days.

I don't think I'm making any assumptions about line lengths, so possibly something else is going on with the ragged line issue you've seen.

Oh sorry, prolly jumped to conclusions here w'o looking at the code. I figured issues with the cat2.six file - for some reason I was not able to crop into the upper right corner, and it looked to me like early ending of sixel bands causes it.

[joouha]

I figured issues with the cat2.six file - for some reason I was not able to crop into the upper right corner, and it looked to me like early ending of sixel bands causes it.

Ah - I can see that this might be an issue if there's no sixels at all in the cropped region

[joouha]

I've made various fixes so sixelcrop now works tollerably well with most of those test files, so I'm going to close this for now.

I think most of the remaining weirdness with these test images is due to incorrect or incomplete implementation of the sixel spec across various terminals: there appears to be considerable variation!

[jerch]

I think most of the remaining weirdness with these test images is due to incorrect or incomplete implementation of the sixel spec across various terminals: there appears to be considerable variation!

Yes that def. the case, TEs simply dont know, which particular source to follow for their impl. Some strive for strict VT340 compat, as thats the only original VT device with reasonable support back then. Some only implement it partially (like xterm.js). The most common denominator these days among TE impls is prolly what libsixel tends to encode to. But thats also full of bugs :see_no_evil:.