> Is there a way to verify if it is using this optimization? $ gdal_translate byte.jpg byte.tif -co compress=jpeg --debug GTiff -q GTiff: Using special copy mode from a JPEG dataset GTiff: Setting JPEGCOLORMODE_RGB
> I'm not actually > feeding it a JPEG in the command line at any point, but the WMS driver is > downloading JPEGs as I am using a WMS source with > <ImageFormat>image/png</ImageFormat>, which might be similar to a VRT. I > don't know how this is treated internally. It won't likely trigger the optimization. As I said, it is currently only implemented in the specific case of JPEG --> JPEG-in-TIFF CreateCopy(). Well, it actually also works in VRT_made_of_a_single_JPEG_without_any_fancy_transform_other_than_metadata_or_gereferencing_additions --> JPEG-in-TIFF. > > My recollection is that it is theoretically possible to merge multiple jpeg > images without decompressing and recompressing, provided the images all lie > on the same block boundaries, where I believe a block is 8x8 pixels. I used > to have some image editing software that would crop JPEGs without > recompression if the cropping lied on the right lines. Yes, this is indeed theoretically possible. > > If you run nearblack to go from one JPEG in TIFF to another JPEG in TIFF, > does it use this optimization for the RGB bands? I don't see the interest of doing nearblack from JPEG-in-TIFF to JPEG-in-TIFF. Nearblack can be interesting from JPEG-in-TIFF to lossless-TIFF to eliminate near zero values at the edge of the imagery due to JPEG compression. But once you get again to JPEG-in-TIFF, the artifacts will come again. And no, the above mentionned optimization could not work since nearblack changes imagery, and doesn't use the CreateCopy() API. _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
