No surprise, I just try to use JPEG compression this week in order to make file size smaller. :-)
In write_scanline function: "// Should we checkpoint? Only if we have enough tiles and enough time has passed" When I inserted breakpoint, and wait a bit, enough time will be passed and the checkpoint function will be called. I also think it is a libtiff bug. It is strange that the file I sent to you causing crash, I can use OpenImageIO and IrfanView open it without any problem. I already tested on both windows and mac. Thanks again for your time. Yang 2015-08-28 15:25 GMT-05:00 Larry Gritz <l...@larrygritz.com>: > I was testing against libtiff 4.0.4 installed with Homebrew on my laptop, > and also whatever 4.x version happened to be installed on a Linux machine I > tried at work. In neither case did I do the build of libtiff myself, but I > am confident that the JPEG support is enabled, because (with my patch) I > can read other JPEG-in-TIFF files (specifically, all the ones here: > http://www.remotesensing.org/libtiff/images.html). Your Lena image is > currently the only one I've come across that causes a crash or behaves > incorrectly when using my patch. > > The checkpointing is interesting. I'm not sure why that would help, but I > don't mind using it as a workaround. I wonder if that is merely > compensating for some kind of bug within libtiff. I'll try it out. But in > any case, I don't see why a debugger breakpoint would change anything at > all. That should at most just alter the timing, not take a different route > through any of the code. > > Given how rarely people seem to use JPEG-in-TIFF (you are the first one to > request it from OIIO in 8 years, if that's any indication), it would not > surprise me if libtiff had a variety of subtle bugs when it comes to that > case. I'll bust my butt to fix the OIIO side, but for such a rare case and > with so little free time, I don't feel like I'm in a position to debug the > internals of libtiff, if that's where the trail leads. > > I wil try the directory checkpointing when I get a chance and report back. > > -- lg > > > On Aug 28, 2015, at 12:23 PM, Yang Yang <comety...@gmail.com> wrote: > > Hi Larry, > > I didn't see the pull. I will check it. > > For the file I send to you, you need to enable JPEG support in libtiff to > read it. Otherwise, it will not work. > I can alway read JPEG-in-TIFF file. > > For writing JPEG-in-TIFF, I find out I have to add the following code: > > #ifdef JPEG_SUPPORT > TIFFCheckpointDirectory(m_tif); > #endif > > to the function: bool TIFFOutput::write_scanline (int y, int z, TypeDesc > format, > const void *data, stride_t xstride) > > in order to make the file correct. > > I guess when breakpoint is not add, the checkpoint is skipped, so I force > to add checkpoint and it works. > Thanks for your help. > > > Yang > > > > 2015-08-28 13:10 GMT-05:00 Larry Gritz <l...@larrygritz.com>: > >> In case you didn't see the results of my tinkering so far: >> https://github.com/OpenImageIO/oiio/pull/1207 >> >> This patch lets you read JPEG-compressed TIFF files. Well, most of them. >> The ones in the libtiff testsuite seem to work fine, but the Lena picture >> you attached a couple days ago is the one image I can't make it read, it >> crashes inside libtiff. (I don't have the writing completely working yet, >> it's hard to work on and test writing if you aren't confident that you're >> reading properly.) >> >> Is the Lena image by any chance the "corrupted JPEG-in-TIFF" you talk >> about? If the only image that doesn't read with my patch is known to be >> corrupted, I'm ready to declare that working and just concentrating on >> making sure we can write JPEG-in-TIFF. >> >> I don't think it's a threading issue. A simple "iconvert" or "iv" >> involving a JPEG-compressed TIFF should not spawn multiple threads. (Most >> ImageBufAlgo image processing functions use threads to speed up, but those >> don't come into play for a simple image copy or format conversion.) >> >> -- lg >> >> >> On Aug 27, 2015, at 12:39 PM, Yang Yang <comety...@gmail.com> wrote: >> >> I found out the difference between corrupted file and good file in >> metadata is StripOffsets. >> Maybe this can shed some lights on this issue. >> >> Corrupted JPEG-in-TIFF: >> >> ImageWidth (1 Short): 512 >> ImageLength (1 Short): 512 >> BitsPerSample (3 Short): 8, 8, 8 >> Compression (1 Short): JPEG Technote #2 >> Photometric (1 Short): RGB >> StripOffsets (16 Long): 1281, 5665, 10846, 16765, 23175, 29579,... >> Orientation (1 Short): TopLeft >> SamplesPerPixel (1 Short): 3 >> RowsPerStrip (1 Short): 32 >> StripByteCounts (16 Long): 4384, 5181, 5919, 6410, 6404, 7070, 6982,... >> PlanarConfig (1 Short): Contig >> XPosition (1 Rational): 0 >> YPosition (1 Rational): 0 >> DateTime (20 ASCII): 2015:08:27 14:31:22 >> SampleFormat (3 Short): 1, 1, 1 >> JpegTables (289 Undefined): >> 700 (899 Byte): 60, 63, 120, 112, 97, 99, 107, 101, 116, 32,... >> 34665 (1 IFD): 172230 >> >> GOOD JPEG-in-TIFF: >> >> ImageWidth (1 Short): 512 >> ImageLength (1 Short): 512 >> BitsPerSample (3 Short): 8, 8, 8 >> Compression (1 Short): JPEG Technote #2 >> Photometric (1 Short): RGB >> StripOffsets (16 Long): 1583, 5967, 11148, 17067, 23477, 29881,... >> Orientation (1 Short): TopLeft >> SamplesPerPixel (1 Short): 3 >> RowsPerStrip (1 Short): 32 >> StripByteCounts (16 Long): 4384, 5181, 5919, 6410, 6404, 7070, 6982,... >> PlanarConfig (1 Short): Contig >> XPosition (1 Rational): 0 >> YPosition (1 Rational): 0 >> DateTime (20 ASCII): 2015:08:27 11:28:45 >> SampleFormat (3 Short): 1, 1, 1 >> JpegTables (289 Undefined): >> 700 (899 Byte): 60, 63, 120, 112, 97, 99, 107, 101, 116, 32,... >> 34665 (1 IFD): 173740 >> >> 2015-08-26 15:29 GMT-05:00 Yang Yang <comety...@gmail.com>: >> >>> I tried, but no luck :( >>> >>> >>> >>> 2015-08-26 11:22 GMT-05:00 Thiago Ize <thi...@solidangle.com>: >>> >>>> Shot in the dark: If it's a race condition that's causing it to crash, >>>> would: >>>> OIIO::attribute ("threads", 1); >>>> perhaps help? >>>> >>>> On Wed, Aug 26, 2015 at 10:17 AM, Yang Yang <comety...@gmail.com> >>>> wrote: >>>> >>>>> Hi Larray, >>>>> >>>>> I attached a file that generated during debug process. The file can be >>>>> load correctly in IrfanView. >>>>> OpenImageIO indeed calls jpeg encoder to generate it. But I cannot >>>>> generate it without setting break point in Visual studio. >>>>> >>>>> I found the following link information about Jpeg in TIFF: >>>>> http://www.remotesensing.org/libtiff/TIFFTechNote2.html >>>>> >>>>> This link give a use case for JPEG in TIFF: >>>>> http://iipimage.sourceforge.net/documentation/images/ >>>>> >>>>> Regards, >>>>> >>>>> Yang >>>>> >>>>> 2015-08-26 1:04 GMT-05:00 Larry Gritz <l...@larrygritz.com>: >>>>> >>>>>> Ha, this has proven to be much more complicated than I thought! >>>>>> >>>>>> By any chance, do you have a JPEG-in-TIFF file that you are confident >>>>>> is correct (can be correctly read by some application you trust) that you >>>>>> can send me to use as a test case? >>>>>> >>>>>> >>>>>> >>>>>> > On Aug 25, 2015, at 11:36 AM, Larry Gritz <l...@larrygritz.com> >>>>>> wrote: >>>>>> > >>>>>> > Yeah, the TIFF output doesn't have a "compression" value it >>>>>> recognizes that will turn on JPEG compression. (I think this is the first >>>>>> time anybody has requested it, I didn't know anybody cared about lossy >>>>>> compression with TIFF files.) >>>>>> > >>>>>> > Should be really simple, I'll propose a patch shortly. >>>>>> > >>>>>> > >>>>>> >> On Aug 25, 2015, at 7:37 AM, Yang Yang <comety...@gmail.com> >>>>>> wrote: >>>>>> >> >>>>>> >> Hi All, >>>>>> >> >>>>>> >> When I try to use JPEG as compression option for TIFF, I found out >>>>>> there is no JPEG support. >>>>>> >> However, when I try to add "JPEG_COMPRESS" option in to >>>>>> OpenImageIO, I found the output file is always corrupted. I already build >>>>>> libtiff with "new jpeg" enabled. >>>>>> >> >>>>>> >> I wonder that does anyone encounter this problem or not? How >>>>>> should I solve this issue. >>>>>> >> >>>>>> >> >>>>>> >> Thank in advance for your attention. >>>>>> >> >>>>>> >> Yang >>>>>> > >>>>>> > >>>>>> >>>>>> -- >>>>>> Larry Gritz >>>>>> l...@larrygritz.com >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Oiio-dev mailing list >>>>>> Oiio-dev@lists.openimageio.org >>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Oiio-dev mailing list >>>>> Oiio-dev@lists.openimageio.org >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> Oiio-dev@lists.openimageio.org >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>>> >>> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> >> -- >> Larry Gritz >> l...@larrygritz.com >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > -- > Larry Gritz > l...@larrygritz.com > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > >
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
