JPEG compressed RGB tiled TIFF with chroma subsampling

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

JPEG compressed RGB tiled TIFF with chroma subsampling

Yakov Galka
Dear all,

Is there a way to create a tiled tiff such that each individual tile is chroma sub-sampled but the responsibility on that YCC conversion and subsampling is on the JPEG encoder/decoder rather than the target application?

Thanks,
--

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Kemp Watson-2
Isn’t that just libtiff built with libjpeg?

W. Kemp Watson


Objective Pathology Services Limited

8250 Lawson Road
Milton, Ontario
Canada  L9T 5C6

www.objectivepathology.com
tel. +1 (416) 970-7284


From: <[hidden email]> on behalf of Yakov Galka <[hidden email]>
Date: Thursday, May 11, 2017 at 1:35 PM
To: TIFF mailing list <[hidden email]>
Subject: [Tiff] JPEG compressed RGB tiled TIFF with chroma subsampling

Dear all,

Is there a way to create a tiled tiff such that each individual tile is chroma sub-sampled but the responsibility on that YCC conversion and subsampling is on the JPEG encoder/decoder rather than the target application?

Thanks,
--
_______________________________________________ Tiff mailing list: [hidden email] http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Yakov Galka
Unfortunately no.

If we set PHOTOMETRIC_RGB and COMPRESSION_JPEG then libtiff retains the libjpeg's default h/v_samp_factors set to 1, which result in full-resolution chroma and much larger files. Neither it supports overriding them for anything other than PHOTOMETRIC_YCBCR. There is a comment in the code that says "TIFF 6.0 forbids subsampling of all other color spaces".

First, I doubt that this comment is correct. I looked at the TIFF 6.0 spec and it does not seem to have any restrictions on the JFIF stream internals, only on the TIFF metadata. So why couldn't the encapsulated JFIF data be chroma subsampled?

Second, even if such TIFF wouldn't be a standard baseline TIFF, it seems that libtiff would be able to read it without any problems, so why can't I explicitly generate such streams? I'll try to compile a modified libtiff version that would lift this restriction and see if it works later.


On Thu, May 11, 2017 at 9:15 PM, Kemp Watson <[hidden email]> wrote:
Isn’t that just libtiff built with libjpeg?

W. Kemp Watson


Objective Pathology Services Limited

8250 Lawson Road
Milton, Ontario
Canada  L9T 5C6

www.objectivepathology.com
tel. +1 (416) 970-7284


From: <[hidden email]> on behalf of Yakov Galka <[hidden email]>
Date: Thursday, May 11, 2017 at 1:35 PM
To: TIFF mailing list <[hidden email]>
Subject: [Tiff] JPEG compressed RGB tiled TIFF with chroma subsampling

Dear all,

Is there a way to create a tiled tiff such that each individual tile is chroma sub-sampled but the responsibility on that YCC conversion and subsampling is on the JPEG encoder/decoder rather than the target application?

Thanks,
--
_______________________________________________ Tiff mailing list: [hidden email] http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/



--

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

jcupitt
Hi, this took me a while to work out too.

Just set TIFFTAG_JPEGCOLORMODE to JPEGCOLORMODE_RGB. This is a
pseudo-tag -- it means you are going to supply RGB data, but that the
encoder is free to convert to YCBCR and subsample in the usual way.

You need to set it on decompress too I think to make libjpg convert
the YCBCR back to RGB for you.

John
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Even Rouault-2

On jeudi 11 mai 2017 19:45:23 CEST [hidden email] wrote:

> Hi, this took me a while to work out too.

>

> Just set TIFFTAG_JPEGCOLORMODE to JPEGCOLORMODE_RGB. This is a

> pseudo-tag -- it means you are going to supply RGB data, but that the

> encoder is free to convert to YCBCR and subsample in the usual way.

 

Yes, for encoding, use both TIFFTAG_JPEGCOLORMODE = JPEGCOLORMODE_RGB and TIFFTAG_PHOTOMETRIC = PHOTOMETRIC_YCBCR. By default this will use h_samp_factor = v_samp_factor = 2.

 

>

> You need to set it on decompress too I think to make libjpg convert

> the YCBCR back to RGB for you.

>

> John

> _______________________________________________

> Tiff mailing list: [hidden email]

> http://lists.maptools.org/mailman/listinfo/tiff

> http://www.remotesensing.org/libtiff/

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Yakov Galka
In reply to this post by jcupitt
On Thu, May 11, 2017 at 9:45 PM, <[hidden email]> wrote:
Just set TIFFTAG_JPEGCOLORMODE to JPEGCOLORMODE_RGB. This is a
pseudo-tag -- it means you are going to supply RGB data, but that the
encoder is free to convert to YCBCR and subsample in the usual way.

Hmm, thanks.
 
You need to set it on decompress too I think to make libjpg convert
the YCBCR back to RGB for you.

The important requirement here is that 'typical' TIFF readers would be able to read the file. This seems to work, however, in the few viewers I've checked.

It is a misdesign however -- because it's not transparent to the reader. If the author of the reader did not handle this JPEG corner-case specifically, then it's going to fail.

--

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

jcupitt
On 11 May 2017 at 20:37, Yakov Galka <[hidden email]> wrote:
> It is a misdesign however -- because it's not transparent to the reader. If
> the author of the reader did not handle this JPEG corner-case specifically,
> then it's going to fail.

I don't think I've come across a reader which doesn't handle this
case. Almost all jpeg-in-tiff files use this mode, so you really have
to.

It's arguably a basic misdesign with tiff: writers are simple (you can
describe almost any pixel layout with a tiff header), but readers are
hard (you have to be able to read almost any pixel layout),

Anyway, this is the most common way of handling jpeg compression in
tiff, so I think you'll be fine.

John
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Yakov Galka

On Thu, May 11, 2017 at 11:48 PM, <[hidden email]> wrote:
I don't think I've come across a reader which doesn't handle this
case. Almost all jpeg-in-tiff files use this mode, so you really have
to.

I take my words back. The only viewers that worked were mspaint and the windows photo viewer. IIPImage seems to have tried to support it but has a bug and fails. OpenCV imread fails. Pretty much every code that does not expect to handle this case *specifically* fails. Which I expect to be the majority of TIFF reading code in the wild.
 
It's arguably a basic misdesign with tiff: writers are simple (you can
describe almost any pixel layout with a tiff header), but readers are
hard (you have to be able to read almost any pixel layout),

I expect libTIFF to abstract those differences. It is not the only thing that libTIFF chooses to shift the responsibility onto the user of the library even though it could just as cheaply hide those pesky details. Another example would be the tile/strip discrepancy.

--

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

jcupitt
On 22 May 2017 at 12:53, Yakov Galka <[hidden email]> wrote:
> On Thu, May 11, 2017 at 11:48 PM, <[hidden email]> wrote:
>> I don't think I've come across a reader which doesn't handle this
>> case. Almost all jpeg-in-tiff files use this mode, so you really have
>> to.
>
> I take my words back. The only viewers that worked were mspaint and the windows photo viewer. IIPImage seems to have tried to support it but has a bug and fails. OpenCV imread fails. Pretty much every code that does not expect to handle this case *specifically* fails. Which I expect to be the majority of TIFF reading code in the wild.

I made a test image, hopefully this link will work:

https://drive.google.com/file/d/0B4ou5nOL1G-yODhjWDJZTDZFQ1k/view?usp=sharing

It's a tiled jpeg tiff, with YCbCr pixels and chroma subsampling.
opencv 2.4.9 (the one I have here) is fine with it. I did notice an
opencv bug on another image: if the tiff orientation tag is set, it
fails to get the tile positions correct.

libreoffice seems to have trouble with even very simple tiff images.
The imagej I have here does not support jpeg tiff. Everything else I
have to test seems OK, including octave, eog, evince, abiword, pillow,
gnumeric, matlab, windows picture viewer, gallery and paint, and
irfanview.

I remember some problems with YCbCr in iipimage, but I think that was
all resolved back in 2010. If it's broken, please open an issue and
I'm sure Ruven would be very embarrassed and fix it very quickly.

>> It's arguably a basic misdesign with tiff: writers are simple (you can
>> describe almost any pixel layout with a tiff header), but readers are
>> hard (you have to be able to read almost any pixel layout),
>
> I expect libTIFF to abstract those differences. It is not the only thing that libTIFF chooses to shift the responsibility onto the user of the library even though it could just as cheaply hide those pesky details. Another example would be the tile/strip discrepancy.

libtiff does have some higher-level read operations which hide this
detail, TIFFReadRGBAImage() for example, but of course there can be
downsides to having the details concealed.

John
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Bob Friesenhahn
In reply to this post by Yakov Galka
On Mon, 22 May 2017, Yakov Galka wrote:

> On Thu, May 11, 2017 at 11:48 PM, <[hidden email]> wrote:
>
>> I don't think I've come across a reader which doesn't handle this
>> case. Almost all jpeg-in-tiff files use this mode, so you really have
>> to.
>>
>
> I take my words back. The only viewers that worked were mspaint and the
> windows photo viewer. IIPImage seems to have tried to support it but has a
> bug and fails. OpenCV imread fails. Pretty much every code that does not
> expect to handle this case *specifically* fails. Which I expect to be the
> majority of TIFF reading code in the wild.

There are many broken/incomplete TIFF readers "in the wild",
particularly when one goes beyond "baseline" TIFF.  JPEG compression
is particularly an issue since its original specification was broken
and Adobe's DRAFT TIFF Technical Note #2
(http://www.simplesystems.org/libtiff/TIFFTechNote2.html) should be
followed instead.

> I expect libTIFF to abstract those differences. It is not the only thing
> that libTIFF chooses to shift the responsibility onto the user of the
> library even though it could just as cheaply hide those pesky details.
> Another example would be the tile/strip discrepancy.

Libtiff does provide dummy/abstraction interfaces, but they do result
in increased resource consumption, loss of performance, and sometimes
loss of original image quality, compared with use of lower-level
interfaces which deliver more directly into the using application's
preferred internal storage format.

Bob
--
Bob Friesenhahn
[hidden email], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Kemp Watson-2
In reply to this post by Yakov Galka
JPEG-in-TIFF is not a TIFF 6.0 compliant file. Many readers/writers out there understand TIFF 6.0, but not TechNote #2. TIFF is a container format, there is no way any reader or writer can know the entire spectrum of items that could potentially be put in a TIFF file.

Similarly, the newer BigTIFF is also not TIFF 6.0 compliant, and many applications have no clue about it.

Tiles/strips is a critical difference to many applications. If it was abstracted away, entire businesses would cease to exist - not a pesky detail in the least for geospatial, astronomy, or microscopy applications.

W. Kemp Watson


Objective Pathology Services Limited

8250 Lawson Road
Milton, Ontario
Canada  L9T 5C6

www.objectivepathology.com
tel. +1 (416) 970-7284


From: <[hidden email]> on behalf of Yakov Galka <[hidden email]>
Date: Monday, May 22, 2017 at 7:53 AM
To: John Cupitt <[hidden email]>
Cc: TIFF mailing list <[hidden email]>
Subject: Re: [Tiff] JPEG compressed RGB tiled TIFF with chroma subsampling


On Thu, May 11, 2017 at 11:48 PM, <[hidden email]> wrote:
I don't think I've come across a reader which doesn't handle this
case. Almost all jpeg-in-tiff files use this mode, so you really have
to.

I take my words back. The only viewers that worked were mspaint and the windows photo viewer. IIPImage seems to have tried to support it but has a bug and fails. OpenCV imread fails. Pretty much every code that does not expect to handle this case *specifically* fails. Which I expect to be the majority of TIFF reading code in the wild.
 
It's arguably a basic misdesign with tiff: writers are simple (you can
describe almost any pixel layout with a tiff header), but readers are
hard (you have to be able to read almost any pixel layout),

I expect libTIFF to abstract those differences. It is not the only thing that libTIFF chooses to shift the responsibility onto the user of the library even though it could just as cheaply hide those pesky details. Another example would be the tile/strip discrepancy.

--
_______________________________________________ Tiff mailing list: [hidden email] http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Yakov Galka
In reply to this post by Bob Friesenhahn
On Mon, May 22, 2017 at 4:39 PM, Bob Friesenhahn <[hidden email]> wrote:
Libtiff does provide dummy/abstraction interfaces, but they do result in increased resource consumption, loss of performance, and sometimes loss of original image quality, compared with use of lower-level interfaces which deliver more directly into the using application's preferred internal storage format.

The JPEG issue is a bit different from the rest (like number of samples, bitness or sample format) -- because the conversion to YCC is usually seen as a detail internal to the JPEG encoder. Thus it's problematic that it leaks to to the TIFF container level.

I would avoid those 8-bit RGBA interfaces because I do care for the higher bitness and non-RGB data in my applications. But, I expect my TIFF to be declared Photometric RGB and still have every tile compressed with YCC subsampled JPEG.

Yes, I did read the TIFF specification and that technical note before opening this thread, and I don't see such arrangement contradicting the spec.

--

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Yakov Galka
In reply to this post by Kemp Watson-2
Dear Kemp,

On Mon, May 22, 2017 at 6:31 PM, Kemp Watson <[hidden email]> wrote:
JPEG-in-TIFF is not a TIFF 6.0 compliant file. Many readers/writers out there understand TIFF 6.0, but not TechNote #2. TIFF is a container format, there is no way any reader or writer can know the entire spectrum of items that could potentially be put in a TIFF file.

Sure. No need to explain that. But it's entirely possible that *one library* would support a wide spectrum of those features and hide at least the non-essential differences.

 
Tiles/strips is a critical difference to many applications. If it was abstracted away, entire businesses would cease to exist - not a pesky detail in the least for geospatial, astronomy, or microscopy applications.

It seems that you misunderstood me. I surely don't advocate abstracting tiles and strips away, like TIFFReadRGBAImage does.

Instead, I was talking about providing uniform interface for both of them, so that the interface for the tiles would read striped TIFFs too. Every libTIFF software I see has two separate code paths for tiles and strips. But strips are logically image-width sized tiles, and it would simplify everybody's life if libTIFF reflected that in the API.

--

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Roger Leigh
On 22/05/2017 16:42, Yakov Galka wrote:

> Dear Kemp,
>
> On Mon, May 22, 2017 at 6:31 PM, Kemp Watson
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Tiles/strips is a critical difference to many applications. If it
>     was abstracted away, entire businesses would cease to exist - not a
>     pesky detail in the least for geospatial, astronomy, or microscopy
>     applications.
>
>
> It seems that you misunderstood me. I surely don't advocate abstracting
> tiles and strips away, like TIFFReadRGBAImage does.
>
> Instead, I was talking about providing uniform interface for both of
> them, so that the interface for the tiles would read striped TIFFs too.
> Every libTIFF software I see has two separate code paths for tiles and
> strips. But strips are logically image-width sized tiles, and it would
> simplify everybody's life if libTIFF reflected that in the API.

Being able to use tiles in the API would be very nice.  I certainly have
to use two codepaths to cater for both possibilities as you say:

https://github.com/ome/ome-files-cpp/blob/master/lib/ome/files/tiff/IFD.cpp#L368
https://github.com/ome/ome-files-cpp/blob/master/lib/ome/files/tiff/IFD.cpp#L290

IIRC the main problem is the buffer packing arrangement for strips vs
tiles when using an image size which isn't a multiple of 16.  Tiles
would overlap the image bounds on the x axis by sizex%16 unused pixels
per row, but strips are contiguous runs.  And then there's the special
casing for bitspersample when it's not a multiple of 8.  I recall this
being incompletely specified in the 6.0 spec; I ended up packing the
buffer according to what libtiff handled, and what other software seemed
to expect as well.

That's not to say that libtiff couldn't handle the differences
internally; it would have a cost for sure.  But we're likely already
paying the cost of the correct packing for strips/tiles *anyway*.


Regards,
Roger
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|

Re: JPEG compressed RGB tiled TIFF with chroma subsampling

Yakov Galka

On Mon, May 22, 2017 at 10:18 PM, Roger Leigh <[hidden email]> wrote:
IIRC the main problem is the buffer packing arrangement for strips vs
tiles when using an image size which isn't a multiple of 16.  Tiles
would overlap the image bounds on the x axis by sizex%16 unused pixels
per row, but strips are contiguous runs.  And then there's the special
casing for bitspersample when it's not a multiple of 8.  I recall this
being incompletely specified in the 6.0 spec; I ended up packing the
buffer according to what libtiff handled, and what other software seemed
to expect as well.

I'm not aware of the bitspersample issue you mention, but as for images of size not divisible by 16 there's no problem:

The restriction of TileWidth % 16 == 0 is still on the responsibility of the party creating the TIFF. When you create it you obviously have to specify whether you want a tiled one or a striped one, and if it's the former then you have to choose a tile size that satisfies the constraints. As for the readers, they don't care for when that "TileWidth" happens to be not a multiple of 16.

I used to implement wrappers TIFFRead/WriteBlock(...), TIFFComputeBlock(...) etc which call into the *Strip() or *Tlie() interface as appropriate. It worked well, and the only catch was that the last strip in a striped TIFF can be smaller than the declared size, whereas tiles are always encoded in their entirety. But this case can also easily be handled.

--

_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/