Fixed
Status Update
Comments
ep...@google.com <ep...@google.com> #2
[Empty comment from Monorail migration]
va...@chromium.org <va...@chromium.org> #3
SkPDFDocument should have a flag to use DCT compression for images over a certain size.
Chrome now considers this a bug:http://crbug.com/133519
Chrome now considers this a bug:
re...@google.com <re...@google.com> #4
1. This is (was/should-be) a mechanism to query a bitmap to see if it has an associated compressed form (e.g. it was decoded from). We plan to beef that up for Picture serialization, so if its not there now, it will be.
2. Also for Picture serialization, we are considering a flag/default to compress large bitmaps on the fly. We had envisioned using PNG since its lossless, but the exact codec isn't too critical.
3. If we considering doing compression for PDF, we should create a more formal way to query (at runtime) if the jpeg encoder is available. The SkImageEncoder API is not required for a build of Skia, but I'm sure we can come up with some runtime query to get at it as needed.
2. Also for Picture serialization, we are considering a flag/default to compress large bitmaps on the fly. We had envisioned using PNG since its lossless, but the exact codec isn't too critical.
3. If we considering doing compression for PDF, we should create a more formal way to query (at runtime) if the jpeg encoder is available. The SkImageEncoder API is not required for a build of Skia, but I'm sure we can come up with some runtime query to get at it as needed.
[Deleted User] <[Deleted User]> #5
We'd like to move http://crbug.com/133519 forward soon - what's the status of this issue?
re...@google.com <re...@google.com> #6
edison and leon, lets chat about this.
va...@google.com <va...@google.com> #7
I looked into what "DCTDecode" means exactly, it seems that it simply wants a JPG file as the content of the stream - no transform of the data is necessary.
However, I didn't see (in src/images/SkImageDecoder_libjpeg.cpp ?) any place where a backing compressed file is associated with an SkBitmap.
However, I didn't see (in src/images/SkImageDecoder_libjpeg.cpp ?) any place where a backing compressed file is associated with an SkBitmap.
re...@google.com <re...@google.com> #8
We recently added SkPixelRef::refEncodedData(), which returns NULL or the pixels already compressed.
Note that this doesn't let the caller specify what sort of compressed form is desired (i.e. restrict it to jpeg for the PDF caller), so we will need to either add a filter/flag/enum to the call to only get back certain type(s), or the caller could sniff the data, and reject it if it isn't supported...
Somewhat related, I would like us to consider adding a runtime flag/hook to allow the PDF backend to only-the-fly compress images into JPEG if that is what the caller wants. Picture serialization already supports this I believe... Leon can chime in on if the existing mechanism is what we want to propagate going forward.
Note that this doesn't let the caller specify what sort of compressed form is desired (i.e. restrict it to jpeg for the PDF caller), so we will need to either add a filter/flag/enum to the call to only get back certain type(s), or the caller could sniff the data, and reject it if it isn't supported...
Somewhat related, I would like us to consider adding a runtime flag/hook to allow the PDF backend to only-the-fly compress images into JPEG if that is what the caller wants. Picture serialization already supports this I believe... Leon can chime in on if the existing mechanism is what we want to propagate going forward.
[Deleted User] <[Deleted User]> #9
Pdf can include the encoded bitmap as JPEG (and other types also), but pdf can also include the URL of the image instead.
IMHO this should be extremely useful for cloud PDF printing, which, if I am correct, is the problem we really try to solve.
If we have jpeg images in a web page, we can get the url of the jpeg for print, instead of including the stream, compressed or not.
The issues to be looken into, are: what if the image to be printed requires login, and what other types of images (png?) are common and can be used as URL in PDF
e.g. seehttp://partners.adobe.com/public/developer/en/pdf/PDFReference.pdf , example 4.25
16 0 obj % Alternate image
<< /Type /XObject
/Subtype /Image
/Width 1000
/Height 2000
/ColorSpace /DeviceRGB
/BitsPerComponent 8
/Length 0 % This is an external stream
/F << /FS /URL
/F (http://www.myserver.mycorp.com/images/exttest.jpg )
>>
/FFilter /DCTDecode
>>
stream
endstream
endobj
IMHO this should be extremely useful for cloud PDF printing, which, if I am correct, is the problem we really try to solve.
If we have jpeg images in a web page, we can get the url of the jpeg for print, instead of including the stream, compressed or not.
The issues to be looken into, are: what if the image to be printed requires login, and what other types of images (png?) are common and can be used as URL in PDF
e.g. see
16 0 obj % Alternate image
<< /Type /XObject
/Subtype /Image
/Width 1000
/Height 2000
/ColorSpace /DeviceRGB
/BitsPerComponent 8
/Length 0 % This is an external stream
/F << /FS /URL
/F (
>>
/FFilter /DCTDecode
>>
stream
endstream
endobj
va...@chromium.org <va...@chromium.org> #10
I don't think we want to make the PDFs require network access. Even worse than a URL requiring some credentials would be URLs on internal networks.
re...@google.com <re...@google.com> #11
Sure, lets look at API control for:
1. force compression (into jpeg)
2. allow URL references instead of pixels
Seems like we can always allow (i.e. don't need api control) for embedded jpeg if the data is already available from the pixelref.
1. force compression (into jpeg)
2. allow URL references instead of pixels
Seems like we can always allow (i.e. don't need api control) for embedded jpeg if the data is already available from the pixelref.
sc...@google.com <sc...@google.com> #12
Re: compress into JPEG if that's what the caller wants:
SkPicture::serialize allows passing in a function for compressing however the caller chooses. At the moment, we give priority to using the refEncodedData, regardless of whether it is in the desired format, but we can modify it to only take the desired format. We'll need to add a way to specify/test the desired format.
SkPicture::serialize allows passing in a function for compressing however the caller chooses. At the moment, we give priority to using the refEncodedData, regardless of whether it is in the desired format, but we can modify it to only take the desired format. We'll need to add a way to specify/test the desired format.
va...@google.com <va...@google.com> #13
It looks like SkPixelRef::refEncodedData() only has an empty implementation?
re...@google.com <re...@google.com> #14
In the base-class yes. On the chrome/webkit side, they will override that when they land their lazy-decoding-pixelrefs, which will contain a ref to the encoded data.
[Deleted User] <[Deleted User]> #15
skps converted to pdf stats:
1) uncompressed images: 105MB
2) compressed images, 100 quality: 75MB
3) compressed images, 85 quality: 75MB
4) no images, use urls: 5MB
Of course, not having images included just shifts the cost of downloading on the printer, and it introduces further complications as talked above
As far as I understand from the code (SkPDFStream::populate), we already do loose-less compression, that is why the saving is only of 25% by including jpeg, we basically switch from /Filter /FlateDecode to /Filter /DCTDecode
1) uncompressed images: 105MB
2) compressed images, 100 quality: 75MB
3) compressed images, 85 quality: 75MB
4) no images, use urls: 5MB
Of course, not having images included just shifts the cost of downloading on the printer, and it introduces further complications as talked above
As far as I understand from the code (SkPDFStream::populate), we already do loose-less compression, that is why the saving is only of 25% by including jpeg, we basically switch from /Filter /FlateDecode to /Filter /DCTDecode
[Deleted User] <[Deleted User]> #16
correction
skps converted to pdf stats:
1) CURRENT: FlateDecode compressed images: 105MB
2) JPEG (DCTDecode) compressed images, 100 quality: 75MB
3) JPEG (DCTDecode) compressed images, 85 quality: 75MB
4) no images, use urls: 5MB
skps converted to pdf stats:
1) CURRENT: FlateDecode compressed images: 105MB
2) JPEG (DCTDecode) compressed images, 100 quality: 75MB
3) JPEG (DCTDecode) compressed images, 85 quality: 75MB
4) no images, use urls: 5MB
[Deleted User] <[Deleted User]> #17
I was comparing jpeg size with uncompressed image, but if we use best of JPEG (DCTDecode) or ZIP (FlateDecode) then we get an additional saving of 20%
%) JPEG or ZIP (best of DCTDecode, FlateDecode and Nothing ) compressed images, 50MB
%) JPEG or ZIP (best of DCTDecode, FlateDecode and Nothing ) compressed images, 50MB
re...@google.com <re...@google.com> #18
[Empty comment from Monorail migration]
ed...@google.com <ed...@google.com> #19
[Empty comment from Monorail migration]
ed...@google.com <ed...@google.com> #20
we need to enable it in chrome now.
[Deleted User] <[Deleted User]> #21
I'm looking into this, and it seems there is no way for a SkPixelRef to tell what format the encoded data is in (is there?). If this is the case, how do we know that we actually have a JPEG? Is relying on the JPEG magic numbers a good enough guess? Are there additional possible checks?
sc...@google.com <sc...@google.com> #22
Generally we use a decoder to figure out which format the data is in (and yes, we use the magic numbers at the beginning). We try to keep the rest of our code from depending on our decoders, so we use a function pointer in SkPicture serialize/CreateFromStream.
Description