Anton,
> On Sep 25, 2025, at 2:55 PM, Anton Thomasson <antonthomasson at gmail.com> wrote:
>> Hi
>> It is hard to argue that always going to PWG or URF raster is better.
> With potentially fewer and fewer JPEGs qualifying to be sent directly, i guess direct JPEG printing is almost becoming obsolete.
> (And fewer JPEGs in circulation in general).
I wouldn't go that far, and I *do* know from experience that it is fairly easy to get a valid, printable JPEG file from platform APIs since JPEGs are still the most likely common format for exchanging/providing photos.
> Though i suspect that there are at least some printers that have JPEG but not a raster format support.
WRT IPP printers, no. All of the "standard" IPP driverless printing protocols require a streaming raster format (AirPrint uses Apple Raster, IPP Everywhere uses PWG Raster, Wi-Fi Direct and Mopria use PWG Raster or PCLm), largely because while JPEG works well for photos it sucks for text. In fact, most B&W printers lack JPEG support but have raster and/or PDF support...
> And presumably a purpose-built photo printer will do a good job with a straight JPEG.
Indeed.
> 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.You are quite right, x/y might be different than what is imaged if the user says to make it so.
> But the core of the question remains; what does the IPP attributes indicate:
> The jpeg stream contents or the image after rotation according to the Exif header?
Stream contents.
> One would need to know that to ascertain if the JPEG can be sent as-is or not.
>> A real-world example:
> 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.
> If a printer has max jpeg dimensions of 3000x4000, can i send it the image?
Almost certainly not.
> > There might be "valid" reasons why the hardware can't handle (for example) long scanlines but can otherwise handle decoding tall images.
> 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.
> So problem solved?
>> > Official definition of what?
> 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).
OK, so we can file an errata against PWG 5100.13 to make it clear that the jpeg-x/y-dimension-supported values refer to the JFIF stream dimensions and not the logical dimensions in the metadata.
> > 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.
>> To do what do you mean? See how badly i destroy it with my scaling?
I mean that cameras that "natively" store JPEG files (e.g. a Canon EOS DSLR) produce different results than those that convert a newer format like HEIF to JPEG (e.g. an iPhone). What I've found is that JPEGs from smartphones are typically pre-rotated while camera JPEGs typically use the sensor orientation.
________________________
Michael Sweet