Closed Charltsing closed 1 month ago
@Charltsing 很奇怪,这个文件的签名不是jp2
确认了,这个是 jpeg 2000 codestream类型
@Charltsing 能提供更多的jpeg 2000 codestream类型的示例文件吗?
jpeg 2000 codestream实际上一般惯用的扩展名为j2k。imageinfo 暂时不支持j2k。
jpeg 2000的标准乱七八糟的,扩展名都是胡乱用。暂且使用推荐的j2k做为jpeg 2000 codestream格式的扩展名吧。
扩展名jp2表示实现了Part1,jpx表示实现了Part2,jpm表示实现Part6
j2c或者jpc应该表示是仅码流文件,没有其它信息,通常是用于测试。
JPF 是 JPX 文件存储在计算机文件系统中时的正式存储文件格式。
通用的统一扩展名估计是j2k
imageinfo.hpp 中的枚举定义不太对啊 jpeg2000的几个Part的格式可以定义成一个,统一用J2K就可以了(或者改成kFormatJPEG2000)。 不要分成J2K,Jp2和Jpx。
要不,很快你会发现JPEG2000的17个Part会弄出来十几个扩展名,防不胜防。
jpeg2000的几个Part的格式可以定义成一个
我考虑一下怎么做比较合理
或者增加子类型。 主类型用kFormatJPEG2000,子类型JP2、JPX、JPC
或者增加子类型。 主类型用kFormatJPEG2000,子类型JP2、JPX、JPC
@Charltsing
最新的提交修复了j2k并添加了jph支持
经过查阅jpeg2000的文档和测试大量的官方示例图片,现有的功能可以识别jp2, jph, jpx, j2k, j2c, jpc, jhc。
至于扩展名,对于jp2, jph和jpx,根据ftyp
判断,这个没有争议。
j2k, j2c, jpc, jhc目前都会返回j2k
通用扩展名,实际上这些都是 codesteam 类型的,不需要特别区分。
故枚举类型目前不会做调整。
我是这么理解图像格式的:如果属于同一个ISO定义,那它就是同一种图像格式。同一个图像格式可能有多个编码格式或者文件格式。
JPEG2000中,jp2, jph, jpx, j2k, j2c, jpc, jhc都在ISO15444中定义,所以应该是属于同一种图像格式,只需要一个枚举。但是因为Part的不同,可能采用的文件格式、编码格式或者其它什么不同导致扩展名不一样。如果给前述的编码格式或者文件格式都提供一个枚举,可能会造成误解,外行会当作新的图像格式。
所以,采用 图像格式kFormat + 图像类型fType 可能会更加合理一些。或者提供两个图像格式,一个是按照ISO分类(iFormat),一个按照编码或文件格式分类(fFormat)。让使用者各取所需。例如:ImageInfo的图像格式按照ISO分类提供枚举,再提供一个编码格式的枚举。其它那些扩展名和mime之类的可以按编码格式输出。
JPEG2000与传统图像格式不同,它为了更多的占领商业市场,在一个ISO中塞入了大量针对不同场景的编码格式和文件格式。本质上更像是把多个以前我们理解的所谓图像格式弄成了一个大的图像格式。但是我考虑不应该把它的子格式当作独立的图像格式放在枚举里面,这会造成误解。也可能会给以后更多图像格式的加入造成不必要的识别麻烦(大量的图像格式枚举会导致新手懵逼)。例如,JPEG2000其它子格式还包括:MJ2、MJP2、JPSEC、JPIP、JP3D、JPWL、JPXML、HTJ2K等等。具体参考:https://jpeg.org/jpeg2000/index.html
另一个类似的例子是PNM,它的实际格式分别是PPM、PGM、PBM和PFM,再分成ASCII和二进制两种编码,一共8种格式。PNM是它们的统称(PNM并不是真实的图像编码)。
一个反面的例子是JBIG2格式,它包括文本编码、单幅图像编码和多幅图像编码,但却没有起多个扩展名,统一都叫做JB2或者JBig2
ImageMagick就把所有的图像编码格式都独立成了枚举,当初我就被ImageMagick的上百种格式搞懵逼了。其实很多格式都属于同一个图像ISO定义,ImageMagick应该是从图像编码角度来区分不同枚举的。
但我觉得ImageInfo不是一个图像解码工具,不需要把每个编码格式都搞成图像格式。很多时候,用户只需要知道一个大概的图像格式就足够了。
目前来看,因为图像格式并不多,按照你现在的做法把每个不同的编码都提供一个图像格式枚举也可接受,只是未来升级维护就会显得混乱。
当然,具体做法由您自行斟酌,无需太在意我的一家之言。
你的考虑是合理的,但目前阶段而言不在考虑范畴。主要原因是我前面说过的,不保证二进制兼容,但需要保证源码级的兼容。 我思考过这个问题,合理的且一劳永逸的做法都会破坏这一兼容性。 所以过早优化是不必要的。如果将来确实有需要,会将当前分支固定位v2,然后切换到v3分支开发新版本以彻底解决问题。 但目前来看,破坏兼容性带来的收益并不明显。
balloon.zip