Advanced JPEG I/O

[koopa]

For JPEG writing, is setting the SubSampling factor or number of progression scans supported? The latter is not nearly as important as the former.

For JPEG reading, is scaled decoding supported? How about determining the SubSampling factor of the file?

If not, are there any future plans or does someone know an alternative library (C or Basic)?

JPEG Background
Progressive - Like interlacing, JPEG supports saving in multiple passes. The number of passes cannot be set in most programs.
SubSampling - Since the eye is more sensitive to brightness (Y) than color (C), JPEG compression usually reduces the resolution of both color components by a factor of two along at least one axis. Cameras commonly do this along one axis while software often does this along both. In some software this is selectable or at least changes implicitly with the quality (compression) setting.
Scaled Decode - Once read into memory, any image can be scaled up or down by resampling. A JPEG can be alternatively be scaled during its decode. This is usually limited to 1/4 or 1/16 scaling, but I believe that JPEG supports N/8 for any N=1..16. Obviously this is of no use for end users, but this is a fabulous SDK feature when creating thumbnails or previews as it saves much time (in decoding and scaling down) and memory (no huge original). Say one wants to make a thumbnail out of a 1600x1200 image. JPEG supports it being opened as a 400x300 image which can be used as a preview or further scaled in the traditional method to create a thumbnail. Did this explanation make any sense? If anyone out there knows more about this in general, please share.

[koopa]

For JPEG writing, is setting the SubSampling factor or number of progression scans supported? The latter is not nearly as important as the former.

For JPEG reading, is scaled decoding supported? How about determining the SubSampling factor of the file?

If not, are there any future plans or does someone know an alternative library (C or Basic)?

JPEG Background
Progressive - Like interlacing, JPEG supports saving in multiple passes. The number of passes cannot be set in most programs.
SubSampling - Since the eye is more sensitive to brightness (Y) than color (C), JPEG compression usually reduces the resolution of both color components by a factor of two along at least one axis. Cameras commonly do this along one axis while software often does this along both. In some software this is selectable or at least changes implicitly with the quality (compression) setting.
Scaled Decode - Once read into memory, any image can be scaled up or down by resampling. A JPEG can be alternatively be scaled during its decode. This is usually limited to 1/4 or 1/16 scaling, but I believe that JPEG supports N/8 for any N=1..16. Obviously this is of no use for end users, but this is a fabulous SDK feature when creating thumbnails or previews as it saves much time (in decoding and scaling down) and memory (no huge original). Say one wants to make a thumbnail out of a 1600x1200 image. JPEG supports it being opened as a 400x300 image which can be used as a preview or further scaled in the traditional method to create a thumbnail. Did this explanation make any sense? If anyone out there knows more about this in general, please share.

OK, maybe a bit esoteric for some. I love XnView itself so here is my second attempt at contributing a little to GFL:

JPEG SubSampling has been in XnView since at least v1.91 (05/2007, more), but I can't find it in NConvert nor GFL. Am I missing something?

Another question along the same lines: Are any operations, especially resizing, performed in the image file's native color space or is there always a conversion to RGB? For example, JPEG files are usually stored in YCbCr. A conversion would make things much slower and probably less accurate.

It's also worth noting that while my interest is in JPEG, many of these issues would apply to other formats as well.

[xnview]

JPEG SubSampling has been in XnView since at least v1.91 (05/2007, more), but I can't find it in NConvert nor GFL. Am I missing something?

Will be added

Another question along the same lines: Are any operations, especially resizing, performed in the image file's native color space or is there always a conversion to RGB? For example, JPEG files are usually stored in YCbCr. A conversion would make things much slower and probably less accurate.

Made in RGB