feat: 添加数据流为多张图片的兼容逻辑

[INTMIN]

在测试中使用多个数据流图片的dataset时候发现总是显示Too big to display，排查到目前仓库项目只支持单个图片数据流，然后我加了一个兼容逻辑，以及拆分图片自动轮播

[axelboc]

Hi @INTMIN, thanks for the pull request.

If I understand correctly, you have a stack of binary PNG or JPEG images stored in an opaque dataset, and you'd like to play those image like a video at 2 frames per second. Is that right?

In #1554, we considered adding support for multi-dimensional opaque datasets containing binary images:

Ideally, we should also support displaying stacks of pictures stored as multi-dimensional opaque datasets (i.e. one image at a time, with sliders on the left).

The idea is to use the dimension mapper component to allow browsing through the stack of images, like we do on the heatmap visualisation for instance (but with a single mappable dimension more like the line visualization):

I'd be happy to work on this as soon as I can, if this feature is useful to you.

Animating the frames like a video, however, is currently out of scope of the H5Web viewer, sorry. This has non-trivial implications in terms of asynchronicity when dealing with large amounts of data or with server-based data providers.

[INTMIN]

 Okay, in fact, I made a video viewing player for this kind of multi-dimensional image data, and users can choose whether to play and pause and skip the current picture and drag the progress bar to quickly view, but I thought that it may not be in line with the current project's idea, so I didn't upload that part of the code, the way you said to support multi-dimensional data, I'm glad that you already have the idea of this part of the implementation, then wait for your side to develop, if you need my help, I'm happy

[INTMIN]

@axelboc The .h5 format file on my side records some two-dimensional or even three-dimensional spatial quadrant points, as well as the images generated by each group at that time, so each point actually has a corresponding image display here, because it is a more complex large map, the kind of HeadMap you draw here may not be able to fully carry this amount of data, because a second may be 60 frames or 50 frames, and the data in ten minutes has the data size of g, and the browser will be stuck and flashback due to too much memory when rendered in an instant, so I use the logical processing of the video and the processing scheme of the uploaded temporary auto-play sheetI hope you understand my temporary handling and if we need other solutions, we can discuss them together.

[axelboc]

Hi @INTMIN, I've opened an issue to track this feature request and describe the requirements in more details: #1771. Thanks for sharing your use case!