attachment

<div dir="ltr"><div dir="ltr"><div>Hi</div><div><br></div>It is hard to argue that always going to PWG or URF raster is better.</div><div>With potentially fewer and fewer JPEGs qualifying to be sent directly, i guess direct JPEG printing is almost becoming obsolete.</div><div>(And fewer JPEGs in circulation in general).</div><div>Though i suspect that there are at least some printers that have JPEG but not a raster format support.</div><div>And presumably a purpose-built photo printer will do a good job with a straight JPEG.</div><div><br></div><div>So i do stand by that my lossless baselinifier has a point, but i should probably have left my latest silly experiment out of the backstory.</div><div></div><div>You are quite right, x/y might be different than what is imaged if the user says to make it so.</div><div>But the core of the question remains; what does the IPP attributes indicate:</div><div>The jpeg stream contents or the image after rotation according to the Exif header?</div><div>One would need to know that to ascertain if the JPEG can be sent as-is or not.</div><div><br></div><div>A real-world example:</div><div>Pictures from my phone are "3000x4000" if i ask basically any normal application, but libjpeg and "file" see the JPEG data dimensions, which are actually 4000x3000.</div><div>If a printer has max jpeg dimensions of 3000x4000, can i send it the image?</div><div><div><br></div><div>> 
There might be "valid" reasons why the hardware can't handle (for 
example) long scanlines but can otherwise handle decoding tall images.</div><div>Alright,
 reasonable point; but for that to hold true it would imply that the x and y 
dimensions meant are those of the JPEG data, not those after 
Exif-ordered/suggested transformation.</div><div>So problem solved?</div><div><br></div><div>> Official definition of what?</div><div>If the x/y dimensions in the spec are those of the JPEG data or those that a user would normally consider the dimensions of the image when viewed (i.e. after Exif transformation).</div></div><div><br></div><div>> I encourage you to grab images from a digital camera and not necessarily
 from a smartphone, since smartphones often do a lot of post-processing 
and use something other than JPEG as a primary storage format.  If you 
don't have access to such files I am happy to send you some examples.</div><div><br></div><div>To do what do you mean? See how badly i destroy it with my scaling?</div><div>So Android has something different now too?</div><div>I wouldn't know; i've been on Sailfish OS for 12 years and Meego before that. :)</div><div>That would be appreciated, i don't think i have anything reasonably modern in that department.</div><div><br></div><div>Br,</div><div>Anton</div><div><br></div><div><br></div></div>