yllan
DPI? Does JXL have scale factor information?
PNG
JPEG-XL Info
JxlBasicInfo(have_container: 0, xsize: 244, ysize: 76, bits_per_sample: 8, exponent_bits_per_sample: 0, intensity_target: 255.0, min_nits: 0.0, relative_to_max_display: 0, linear_below: 0.0, uses_original_profile: 1, have_preview: 0, have_animation: 0, orientation: __C.JxlOrientation(rawValue: 1), num_extra_channels: 1, alpha_bits: 8, alpha_exponent_bits: 0, alpha_premultiplied: 0, preview: __C.JxlPreviewHeader(xsize: 0, ysize: 0), animation: __C.JxlAnimationHeader(tps_numerator: 0, tps_denominator: 0, num_loops: 0, have_timecodes: 0))
I was wondering this too, because when I tried to compare a jxl image using your app to its source jpg image in Preview, I clicked the menu item View -> Actual Size in both apps and I got different zoom levels in both apps, which seemed weird to me.
cjxl and djxl currently didn't preserve the DPI information. I compress a 144 DPI png to jxl and then use djxl to decompress, it becomes a 72 DPI png.
Now I hardcoded the DPI to be 144 (@2x). Will change back to 72 DPI in the next release.
cjxlanddjxlcurrently didn't preserve the DPI information.
Did you already open a ticket for that on the official jxl repo? Or do you think they already have that on their todo list, but that they just haven't gotten to it yet?
Currently cjxl silently strips exif/xmp from a PNG, and only encodes the pixel data and the ICC profile.
I didn't know Preview actually looks at DPI information to do "Actual size". I would expect "Actual size" to just show me pixels in native resolution (1:1). It would make sense to use DPI for that and have actual physical dimensions on the screen that match the intended physical dimensions, if it weren't for the fact that most DPI values are bogus default values that are ignored by most software, and have little to do with intended physical dimensions (which is a weird concept anyway, one that is relevant for print but not really for screen display imo).
