attachment
<div dir="ltr"><div>Hi</div><div><br></div><div>Since the only baseline JPEG is mandatory (for JPEG-supporting printers) i made a little schoolbook lossless baselinifier application.</div><div>However, there is also jpeg-{x,y}-dimension-supported and jpeg-k-octets-supported to take into account.</div><div>Because of this, i'm looking in to the built-in downscaling in libjpeg (and sane derivatives).</div><div>Even though it is limited to a max downscale factor of 8 it should cover even quite extreme cases.</div><div>(This of course includes decompressing and recompressing the image and isn't lossless).</div><div><br></div><div>However, with Exif headers adding orientation completely separately, the question of which dimension is which arises.</div><div>From what i understand Exif headers are mandatory to support. (And respect?)</div><div>I'll stick my neck out and say x=width=horizontal and y=height=vertical.</div><div>But with a Exif rotation of +/- 90 degrees, does the constraints apply to before or after transformation?</div><div>I.e. to the data as stored in the JPEG steam or as imaged onto the page.</div><div><br></div><div>Most printers, sensibly, have the same limit in both dimensions, but i have logs for at least one that doesn't (and of course it has the lowest values).</div><div>Is there an official definition, or should one be added?</div><div>(And should it maybe be recommended to not have these constraints differ?)</div><div><br></div><div>Br,</div><div>Anton</div></div>